Matt, Perhaps you can suggest a better wording. To me it says what I think it is supposed to say. What I was shooting for. If you receive an S/MIME message and that message contains PKCS#6 certificate. You cannot fail processing the message because of the presence of the PKCS#6 certificate, but you can ignore the content of that certificate. Jim > -----Original Message----- > From: Matthew Miller <linuxwolf+ietf@xxxxxxxxxxxxxxxx> > Sent: Saturday, April 21, 2018 8:30 AM > To: secdir@xxxxxxxx > Cc: spasm@xxxxxxxx; draft-ietf-lamps-rfc5750-bis.all@xxxxxxxx; ietf@xxxxxxxx > Subject: Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 > > Reviewer: Matthew Miller > Review result: Has Nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. > > Document: draft-ietf-lamps-rfc5750-bis-05 > Reviewer: Matthew A. Miller > Review Date: 2018-04-21 > IETF LC End Date: 2018-04-27 > IESG Telechat date: N/A > > Summary: > > This document is ready, but there is one nit around PKCS #6 handling that > might benefit from explanation. > > This document describes the certificate handling expectations for senders > and receivers of S/MIME 4.0. It obsoletes RFC 5750, adding requirements to > support internationalized email addresses, increase RSA minimum key sizes, > and support ECDSA using P-256 and Ed25519; older algorithms such as DSA, > MD5, and SHA-1 are relegated to historical. > > Major Issues: N/A > > Minor Issues: N/A > > Nits: > > Section 2.2.1. "Historical Note about CMS Certificates" is almost entired > unchanged, but added a requirement that receivers MUST be able to process > PCKS #6 extended certificates. This almost seems at odds with the rest of > the paragraph that precedes this MUST, noting PKCS #6 has little use and > PKIX is functionally equivalent. > A short explanation of why this additional handling requirement would seem > helpful.
