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

From: Adam Roach <[email-masked]>
Date: Mon, 16 Apr 2018 15:50:48 -0700

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.

---------------------------------------------------------------------------

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

===========================================================================
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..."

---------------------------------------------------------------------------
§1:

>  o  There are still on going discussions among the cryptographic

Nit: "ongoing"

---------------------------------------------------------------------------

§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..."

---------------------------------------------------------------------------

§2:

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 16 Apr 2018 16:23:18 -0700

> -----Original Message-----
> From: Adam Roach <[email-masked]>
> Sent: Monday, April 16, 2018 3:51 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Daniel Migault
> <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Adam Roach's No Objection on draft-ietf-curdle-pkix-07: (with
> COMMENT)
> 
> 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.)
> 
> 
> 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.

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

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.

Already fixed

Done

Already fixed

Already done.

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Apr 2018 18:26:59 -0500

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

If the text about older implementations doesn't have any bearing on 
what's described in this document, I would suggest removing it -- 
otherwise, you probably run the risk of seeing people doing it in the 
wild despite the later prohibitions.

/a