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

[Jim Schaad <[e-mail]>]

See in-line.

 

Jim

 

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

 

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.
 
[JLS] Doing this makes sense to me.  I will do so.  I just copied this section from an existing RFC which used 1988 syntax.
 
 
   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.
[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.
 
   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 <[e-mail] <mailto:[e-mail]> > a écrit :

 

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: [e-mail] <mailto:[e-mail]>  [mailto:[e-mail]]
Sent: Wednesday, November 23, 2016 1:16 PM
To: Simon Josefsson <[e-mail] <mailto:[e-mail]> >; Jim Schaad
<[e-mail] <mailto:[e-mail]> >
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 <http://tools.ietf.org> .

The IETF Secretariat



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