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

[Benjamin Kaduk <[e-mail]>]

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.

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?

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?

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?

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?

   [...] Other extensions may be included, but those extensions
   SHOULD NOT be marked as critical.

Is this a candidate for a 2119 MAY?

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.