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

[Jim Schaad <[e-mail]>]

Ben,

See comments inline.

EKR, Russ

There is a question below for you

> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Sent: Monday, June 18, 2018 9:07 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Russ Housley
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with
> COMMENT)
> 
> Ben Campbell 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:
> ----------------------------------------------------------------------
> 
> Thanks for this work. I'm balloting "yes", but have a few comments. I realize
> some of these may be leftovers from previous versions. None are blocking,
> so I leave it to the authors, WG, and AD to choose.
> 
> Substantive:
> 
> §1.3, last paragraph: Is the "SHOULD NOT" really constrained to mail? It
> seems like it should apply to other messaging systems, although I can see the
> need to decrypt old messages as more important for mail than for more real-
> time messaging.

That makes sense.  It now reads

    Support of these algorithms may be needed to support historic S/MIME artifacts such as messages or files, but SHOULD NOT be used for new artifacts.

> 
> §2.2.1, 2nd paragraph: "...although ignoring those
>    certificates is expected behavior..."
> I'm surprised not to seem a MUST or SHOULD here--is it ever reasonable to
> _not_ ignore these certificates?

Are you reading the same version I am.  I see the following text:

Thus, sending and receiving agents MUST NOT use PKCS #6 extended certificates.

I can understand that you might think that the last sentence softens this restriction, but it is targeted at the fact that the parser has to not fail.

> 
> §2.3:
> 
> - The requirement to be able to handle an arbitrary number of certificates
> seems like a potential DOS vector. Aspects of that are mentioned in the
> security considerations. Shouldn't a receiving agent put some limits on the
> number/size it will accept? Or is "fail gracefully" an acceptable strategy to
> "handle" too many certs?

Yes I can see that this might be a potential DOS vector.  I think however that you are going to run into thing like the message file is just too large to be able to process first.  There are lots of potential DOS vectors around having large things and this is just one of those possibilities.  It is also not really a good idea to put cat videos in certificates because the certificate size is going to be too large as well.  

Failing gracefully (message cannot be displayed) is an acceptable strategy in my mind to any of the - you have a problem with certificates or CRLs that are too big or too hard to process.

> 
> - 4th paragraph: "Note that
>    receiving agents SHOULD NOT simply trust any self-signed certificates
>    as valid CAs, but SHOULD use some other mechanism to determine if
>    this is a CA that should be trusted."
> 
> Why are those SHOULDs not MUSTs? (Or SHOULD+'s)?

Mostly because I do not want to completely rule out any TOFU applications. 

This is the text in the previous version of the document as well as there has been no discussion I don't think that I would want to change it.

> 
> §4.4, 2nd paragraph: "Some mechanism SHOULD
>    exist to gracefully handle other certificate extensions when they
>    appear in end-entity or CA certificates."
> 
> Can you elaborate on that? Does it imply more than discussion of the
> "critical"
> bit in the next paragraph?

I believe that this is more than just a discussion of the 'critical' bit.  Examples of this might be:

* Allow for installation of extension handlers or implement additional extensions that are not listed as MUST handles.
* Potentially provide a display mechanism for extensions which are not evaluated so that the user has the option of doing a visual inspection
* Enforce the 'critical' bit when it is set.

> 
> Appendix B: It seems odd to find this in an appendix.  Does this draft actually
> purport to _request_ the move to historic, or just sort of wish we would do
> so?

I have never made up my mind about what to do this these appendixes so I just carry them forward.  The move to historical was done a couple of iterations of this document ago.

> 
> Editorial:
> 
> Abstract: Should the RFC Editor remove the "Contributing to this
> document..."
> paragraph?

Yes and it is tagged that way in the XML source as a comment.

> 
> §1.1:
> 
> - The definition for AC does not contain an actual definition.

It might read better if sentence 3 came first, but I think that it does contain the definition.
(This is original text)

> - CRL definition: " prematurely" seems an odd choice of words; one assumes
> the issuer does not revoke before it needs to. I assume the intent was to
> describe revoking certs prior to their expiration?

I agree that 'prematurely' is a weird word to use here.  I am going to remove that word and add the following sentence:

Certificates which are expired might not appear on a CRL even if it was revoked.

I think that is probably what was trying to be said.

> 
> §1.4 (and subsequent change version): I infer from the section titles that the
> normative keywords in these sections are intended to describe
> requirements added to those versions, not new requirements in _this_
> version. It would be better to make that explicit; the body text should stand
> alone without the titles.

Yes that is what is intended to be said.  I agree and thus did not use keywords in section 1.6.

This is historic text copied from a previous version and as such I am slightly reluctant to change.
EKR and Russ - what do you think?

> 
> §2.2.1, 2nd paragraph: s/parser/parse

Fixed

> 
> §3: Paragraph 5: " Some localities may perform other
>    transformations on the local name component before doing the
>    comparison, however an S/MIME client cannot know what specific
>    localities do."
> 
> That's an odd statement, since software localization rules can certainly
> include comparison policies. It's not material to the document, though, so I
> will leave this as an editorial comment.

There was some discussion about this both here and in DANE about this problem.  The fact that google, for example, strips periods is just one of the painful things that this is meant to iignore.

> 
> §4.1, first paragraph: "get information stored away from incoming
> messages."
> I don't understand what that means. Should "away from" simply be "in"?

s/stored away from/stored in an/

> 
> §4.2, first paragraph: The first sentence seems more like a statement of
> principle than a normative requirement.
> 

I would not have any idea how to test that statement.  Yes I agree that this is not a normative requirement.

Jim