Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility
draft-ietf-smime-escertid-06

[Ballot comment]
Shouldn't section 6 mention that the hash algorithm in the certHash field of ESSCertID (v1) is SHA-1?  Perhaps this could be fixed with a simple RFC Editor note?

Given one of the purposes of this change is to introduce hash function agility, should there be a discussion of that in section 7?  Perhaps an informative reference to RFC 4270 and a caution that implementations plan ahead for algorithm changes?

[Ballot discuss]
This is a non-blocking discussion DISCUSS that I intend to clear immediately after the IESG call unless the authors feel additional work is needed based on this issue.  I want to make sure I understand how the new hash agility feature will work for emails with multiple recipients during a future hash-function transition.

Suppose client A supports at best SHA-256 and client B supports the shiny new super-SHA algorithm.  If I'm composing a message to both recipient A and B, can both algorithms be used in the ESSCertIDv2?  It seems to me either the same certificate is listed twice with different algorithms in the "certs" list, or the "MUST NOT" in the last paragraph of section 3 needs to be changed to allow multiple SigningCertificateV2 blocks during a hash algorithm transition period.

I observe there's a special case for the current transition from ESSCertID to ESSCertIDv2 where both can be present as separate SigningCertificateV2 and SigningCertificate blocks.  I'm just wondering if the next hash transition can work in the same way as this one.

[Ballot comment]
APPENDIX A

When IMPORTing FROM CryptographicMessageSyntax2004 (in RFC3852) and FROM PKIX1Explicit88 (in RFC 3280) I believe that it's better to avoid duplication and not copy the OIDs from the RFCs.

Several Last Call comments were received that deserve a response.  The author has not answered them yet.  It is clear that a revised I-D will be needed.