Re: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT)

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Wednesday, June 20, 2018 12:11 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Russ Housley
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with
> COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lamps-rfc5750-bis-06: Yes
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Lots of good comments from Ben et al; I tried to trim duplicates from my
> own.
> 
> Section 1.2
> 
>    The term RSA in this document almost always refers to the PKCS#1 v1.5
>    RSA signature algorithm even when not qualified as such.  There are a
>    couple of places where it refers to the general RSA cryptographic
>    operation, these can be determined from the context where it is used.
> 
> nit: this is a comma splice; I suggest using a semicolon instead.

Hence why we have hired copy editors. (done)  If they change it back I am going to come and haunt you.

> 
> Section 2
> 
>    [...] Most of
>    the CMS format for S/MIME messages is defined in [RFC5751].
> 
> We cite 5751bis elsewhere; is the non-bis reference intentional?

No this was a miss on my part.

> 
> Section 2.3
> 
>    [...] Receiving S/MIME agents SHOULD be able to
>    handle messages without certificates using a database or directory
>    lookup scheme.
> 
> Maybe clarify that this lookup is to obtain the certificates (and chain) in
> question?

Nit - but ok

> 
> Section 3
> 
>    Note that this attribute MUST be encoded as IA5String and has an
>    upper bound of 255 characters.  The right side of the email address
>    SHOULD be treated as ASCII-case-insensitive.
> 
> What does "treated as" mean here?  Is it limited to "for comparison
> purposes"?  Am I expected to normalize for display?  (I guess enforcing the
> ASCII range is inherent in IA5String, so checking that is out of scope.) The
> next paragraph has a MUST-level case-insensitive comparison, so maybe this
> whole sentence is redundant?
> 
>    [...] A receiving agent SHOULD provide some explicit
>    alternate processing of the message if this comparison fails, this
>    might be done by displaying or logging a message that shows the
>    recipient the mail addresses in the certificate or other certificate
>    details.
> 
> nit: This is another comma splice.
> 
> Section 4.3
> 
> Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for RSASSA-
> PSS with SHA-256?

Big long discussion on this, but mostly because EdDSA has overtaken RSASSA-PSS in the mind share of the world.

> 
> Section 4.4
> 
>    The PKIX Working Group has ongoing efforts to identify and create
>    extensions that have value in particular certification environments.
> 
> Isn't the PKIX WG closed?

You mean that you haven't been invited to the secret PKIX WG meetings at the IETF meetings? 

Swapped to LAMPS.

> 
>    [...] Other extensions may be included, but those extensions
>    SHOULD NOT be marked as critical.
> 
> Is this a candidate for a 2119 MAY?

No not really, marking things a critical is a hinderance to interoperability rather than promoting it.  The selection of SHOULD NOT rather than MAY indicates this by saying that if you want to do this you should probably reconsider that decision unless you have a really good case to do so.


> 
> Section 6
> 
>    In addition to the Security Considerations identified in [RFC5280],
>    caution should be taken when processing certificates that have not
>    first been validated to a trust anchor.  Certificates could be
>    manufactured by untrusted sources for the purpose of mounting denial
>    of service or other attacks.  For example, keys selected to require
>    excessive cryptographic processing, or extensive lists of CRL
>    Distribution Point (CDP) and/or Authority Information Access (AIA)
>    addresses in the certificate, could be used to mount denial-of-
>    service attacks.  Similarly, attacker-specified CDP and/or AIA
>    addresses could be included in fake certificates to allow the
>    originator to detect receipt of the message even if signature
>    verification fails.
> 
> Should malformed/misencoded/strangely-encoded certificates be included
> in the list of examples here?  Historically, ASN.1 parsers have been
> unfortunately fragile, after all.

No I don't think so.  That would really be a general warning that would apply to every thing included in an S/MIME message.  After all it cold be the CRLs or the signature info structure that could have the same problem.  I expect that people really ought to know to deal with this problem already.


>