Re: [Curdle] Adam Roach's No Objection on draft-ietf-curdle-pkix-07: (with COMMENT)

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Adam Roach <[e-mail]>
> Sent: Monday, April 16, 2018 3:51 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Daniel Migault
> <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Adam Roach's No Objection on draft-ietf-curdle-pkix-07: (with
> COMMENT)
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-curdle-pkix-07: No Objection
> 
> 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-curdle-pkix/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to everyone who contributed to this document.
> 
> This is not as much a document comment as a flag for IANA -- the OIDs
> 1.3.101.114 and 1.3.101.115 show as reserved by this document at
> https://www.ietf.org/assignments/smi-numbers/smi-numbers.xml#smi-
> numbers-1.3.101
> but those codepoints no longer appear in this document. We should make
> sure they get released by IANA rather than finalized to point to the RFC this
> will become.

This has already been done in IANA review for the registration document.

> 
> ---------------------------------------------------------------------------
> 
> §3:
> 
> >     For this reason, a small
> >     number of implementations may still require the field to be
> >     present.
> 
> I'm surprised that there's no implementation guidance here. Presumably
> (based on the text about curve25519 and curve448), the parameter is
> present but NULL?
> Is it recommended to set this for maximum compatiblity? Or is this simply
> something that users should be allowed to configure when generating
> these?

No, looking at the next paragraph it says don't set this to NULL even if you are still using this old syntax.  I am not sure that this sentence adds any value because of that sentence.

> 
> ==========================================================
> =================
> Nits
> ==========================================================
> =================
> 
> §1:
> 
> >  o  The EdDSA algorithms are the only IETF algorithms that currently
> >     support the use of contexts, however there is a possibility that
> >     there will be confusion between which algorithms need have
> >     separate keys and which do not.  This may result in a decrease of
> 
> Nit: "...need to have..."

Already fixed

> 
> ---------------------------------------------------------------------------
> §1:
> 
> >  o  There are still on going discussions among the cryptographic
> 
> Nit: "ongoing"

Done

> 
> ---------------------------------------------------------------------------
> 
> §1:
> 
> >  o  There needs to be discussions about the correct way to identify
> >     when context strings are to be used.  It is not clear if different
> >     OIDs should be used for different contexts, or the OID should
> >     merely not that a context string needs to be provided.
> 
> Nit: "...merely note..."

Already fixed

> 
> ---------------------------------------------------------------------------
> 
> §2:
> 
> Consider use of RFC 8174 boiler plate - the document uses non-normative,
> lowercase "should" in some locations.

Already done.