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

Adam Roach <adam@nostrum.com> Mon, 16 April 2018 22:50 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-curdle-pkix@ietf.org, Daniel Migault <daniel.migault@ericsson.com>, curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152391904883.26223.17685462548890273993.idtracker@ietfa.amsl.com>
Date: Mon, 16 Apr 2018 15:50:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/1M8pSiJ67E_ogLX07eSapPB-_aI>
Subject: [Curdle] 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.

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

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

[Curdle] Adam Roach's No Objection on draft-ietf-… Adam Roach
Re: [Curdle] Adam Roach's No Objection on draft-i… Jim Schaad
Re: [Curdle] Adam Roach's No Objection on draft-i… Adam Roach