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

[Eric Rescorla <[e-mail]>]

On Tue, Jun 19, 2018 at 8:06 PM, Jim Schaad <[e-mail]> wrote:

> 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?
>

I don't think it's a big deal, but maybe a note?

-Ekr


> >
> > §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
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>