Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5750-bis-05

[Eric Rescorla <[e-mail]>]

probably "parse" not "parser"


On Wed, May 2, 2018 at 5:01 PM, Jim Schaad <[e-mail]> wrote:

>
>
> > -----Original Message-----
> > From: Matthew Miller <[e-mail]>
> > Sent: Saturday, April 21, 2018 8:30 AM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail];
> [e-mail]
> > 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.
>
> How about the following which is just a description of what we are looking
> for in terms of behavior.
>
>    Receiving agents MUST be able to parser and process a message
> containing PKCS #6 extended certificates although ignoring those
> certificates is expected behavior.
>
>
>
>