Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-03.txt

From: Jim Schaad <[email-masked]>
Date: Wed, 23 Nov 2016 13:26:13 -0800

I believe that this draft addresses all of the last call comments that we have received todate.

* The fact that we are not using contexts has been moved to the introduction - along with some reasoning.

* Use of NULL parameters is not a MUST NOT rather than a SHOULD NOT

* Additional text on the use of Pure EdDSA for long CRLs and the use of CRL distribution points to deal with it.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 23, 2016 1:16 PM
> To: Simon Josefsson <[email-masked]>; Jim Schaad
> <[email-masked]>
> Subject: New Version Notification for draft-ietf-curdle-pkix-03.txt
> 
> 
> A new version of I-D, draft-ietf-curdle-pkix-03.txt has been successfully
> submitted by Jim Schaad and posted to the IETF repository.
> 
> Name:		draft-ietf-curdle-pkix
> Revision:	03
> Title:		Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph,
> X25519 and X448 for use in the Internet X.509 Public Key Infrastructure
> Document date:	2016-11-23
> Group:		curdle
> Pages:		16
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-curdle-pkix-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-03
> 
> Abstract:
>    This document specifies algorithm identifiers and ASN.1 encoding
>    formats for Elliptic Curve constructs using the Curve25519 and
>    Curve448 curves.  The signature algorithms covered are Ed25519,
>    Ed25519ph, Ed448 and Ed448ph.  The key agreement algorithm covered
>    are X25519 and X448.  The encoding for Public Key, Private Key and
>    EdDSA digital signature structures is provided.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Erwann Abalea <[email-masked]>
Date: Thu, 24 Nov 2016 15:38:28 +0000

Bonjour,

Some comments on section 3:

   The AlgorithmIdentifier type, which is included for convenience, is
   defined as follows:

   AlgorithmIdentifier  ::=  SEQUENCE  {
       algorithm   OBJECT IDENTIFIER,
       parameters  ANY DEFINED BY algorithm OPTIONAL
   }

This is an ASN.1:1988 notation, and the rest of the draft uses an ASN.1:1994 notation, the 2 are incompatible (ANY does not exist anymore). You can repeat the definition from RFC5911 if you want.

   The fields in AlgorithmIdentifier have the following meanings:

   o  algorithm identifies the cryptographic algorithm with an object
      identifier.  This is one of the OIDs defined below.

   o  parameters, which are optional, are the associated parameters for
      the algorithm identifier in the algorithm field.  When the 1997
      syntax for AlgorithmIdentifier was initially defined, it omitted
      the OPTIONAL key word.  The optionality of the parameters field
      was later recovered via a defect report, but by then many people
      thought that the field was mandatory.  For this reason, a small
      number of implementations may still require the field to be
      present.

This is confused and wrong. What is this « 1997 » supposed to mean? There is an ASN.1:1997 syntax (it introduces UTF8String for example), an X.509 edition 08/97 (first edition of X.509v3), and they are not concerned by this omission of OPTIONAL here; X.509:1988 (X.509v1) already had the parameters OPTIONAL, and X.509:1993 (X.509v2) switched to the ASN.1:1994 syntax. RFC2459 to 5280 still use the obsolete ASN.1:1988 syntax but all have the OPTIONAL keyword. If some people thought the field was mandatory, it’s for another reason that the one claimed here.

   In this document we defined six new OIDs for identifying the
   different curve/algorithm pairs.  The curves being Curve25519 and
   Curve448.  The algorithms being ECDH, EdDSA in pure mode and EdDSA in
   pre-hash mode.  For all of the OIDs, the parameters MUST be absent.
   Regardless of the defect in the original 1997 syntax, implementations
   MUST NOT accept a parameters value of NULL.

Again, there’s no defect in some 1997 syntax. The absence of the parameters field is enforced by using a real ASN.1 compiler and the proper use of constraints.
With the definitions provided in section 9 for sa-EdDSA* objects, applied to the definition of SignatureAlgorithmIdentifier taken from RFC5911, having any present parameter (even a NULL) would be invalid if the algorithmIdentifier takes one of the id-EdDSA* values (because of the constraints).

Cordialement,
Erwann Abalea

Le 23 nov. 2016 à 22:26, Jim Schaad <[email-masked]<mailto:[email-masked]>> a écrit :

Jim

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, November 23, 2016 1:16 PM
To: Simon Josefsson <[email-masked]<mailto:[email-masked]>>; Jim Schaad
<[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-ietf-curdle-pkix-03.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Curdle mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/curdle

---

From: Jim Schaad <[email-masked]>
Date: Mon, 28 Nov 2016 21:15:08 -0800

See in-line.

Jim

From: Erwann Abalea [mailto:[email-masked]] 
Sent: Thursday, November 24, 2016 7:38 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [Curdle] New Version Notification for draft-ietf-curdle-pkix-03.txt

Bonjour, 

 

[JLS] Doing this makes sense to me.  I will do so.  I just copied this section from an existing RFC which used 1988 syntax.

 
 
This is confused and wrong. What is this « 1997 » supposed to mean? There is an ASN.1:1997 syntax (it introduces UTF8String for example), an X.509 edition 08/97 (first edition of X.509v3), and they are not concerned by this omission of OPTIONAL here; X.509:1988 (X.509v1) already had the parameters OPTIONAL, and X.509:1993 (X.509v2) switched to the ASN.1:1994 syntax. RFC2459 to 5280 still use the obsolete ASN.1:1988 syntax but all have the OPTIONAL keyword. If some people thought the field was mandatory, it’s for another reason that the one claimed here.
[JLS] This concerns the 1997 version of X.509.  That is where AlgorithmIdentifier is defined.
 
I think that you are being misled by the fact that the IETF does not ever modify a document that has been published.  This is not a true statement for the ITU.  When I go out to the ITU site and download the version that is dated 08/97, the date at the bottom of the claims to be “1997 E”.  I read this as being the E-th revision of the document.  This means that the defect report referred to in the text was rolled into the official ITU version of the document.  The fact that you can no longer see that the defect once existed does not mean that it was never in the document.

Cordialement,

Erwann Abalea

Le 23 nov. 2016 à 22:26, Jim Schaad <[email-masked] <mailto:[email-masked]> > a écrit :

Jim

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked]]
Sent: Wednesday, November 23, 2016 1:16 PM
To: Simon Josefsson <[email-masked] <mailto:[email-masked]> >; Jim Schaad
<[email-masked] <mailto:[email-masked]> >
Subject: New Version Notification for draft-ietf-curdle-pkix-03.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> .

The IETF Secretariat

_______________________________________________
Curdle mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/curdle

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 29 Nov 2016 17:41:09 +0000

Bonjour,

« 1997 E » does not mean « E-th revision », it means it’s the English version. Download the Spanish and French versions, and you’ll see « 1997 S » and « 1997 F », respectively.

You can find other formats of previous X.509 standard, such as http://www.gateway.nameflow.net/np/ds/osi/. This is X.509v2 (X.509:1993), the Postscript file was created in 1994, and the web server kindly returns a « Last-Modified: Mon, 04 Sep 1995 11:51:03 GMT » HTTP header.

Cordialement,
Erwann Abalea

Le 29 nov. 2016 à 06:15, Jim Schaad <[email-masked]<mailto:[email-masked]>> a écrit :

See in-line.

Jim

From: Erwann Abalea [mailto:[email-masked]]
Sent: Thursday, November 24, 2016 7:38 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Curdle] New Version Notification for draft-ietf-curdle-pkix-03.txt

Bonjour,

   defined as follows:

   }

      present.

Cordialement,
Erwann Abalea

Jim

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, November 23, 2016 1:16 PM
To: Simon Josefsson <[email-masked]<mailto:[email-masked]>>; Jim Schaad

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat