Subject: [Curdle] comments on draft-ietf-curdle-pkix-00

From: "Jim Schaad" <[email-masked]>
Date: Wed, 27 Apr 2016 16:55:12 -0700

1. It is not completely clear which of the three PKIX related documents are
the current documents.   I am operating under the assumption that this is
the current document and that it replaces the other two documents.  If this
is true, then getting the relationships in the tracker would be nice.

2. I pass this comment on that I got from Ilari on a document that I am
doing for the COSE working group.

It seems like this document mixes up Curve25519
(X25519) and Ed25519 keys. Problem is that Curve25519 public key for some
private key does not equal Ed25519 public key for the same private key...
The same also applies to Curve448 vs. Ed448.

I found this reasoning to be compelling and changed my document so that I
had different curves for the ECDH and EdDSA algorithms.  

3.  I would request that the OIDs for id-Curve25519ph and id-Curve448ph be
removed from section 3.  Having these values in this location makes thing
confusing as they should never appear in a PKIX certificate.  This is
because they are only for the EdDSA algorithms and those algorithms do not
use these values to identify a curve.

4.  Section 3 should reference RFC 5480 which added to the set of algorithm
identifier that use for algorithm identification.

5.  Section 4 - the description of subjectPublicKey should be updated as
this is not restricted to being an EdDSA public key.  Unless you are
planning to duplicate this to deal with ECDH keys separately.

6.  Section 5 - I would like to adamantly argue for the definition of two
different EdDSA signature algorithms.  I would really prefer to have the
pre-hash and the pure versions of EcDSA to be separate algorithms.  They
have different procedures for doing signing.  Additionally, I believe that
it will be quite reasonable for some protocols to define that they will only
support the pure version and not support the pre-hash version. This is a
much easier thing to define if one can separate the signature algorithms and
not have to make the support statement based on the enumeration

7.  Section 6 - need to talk about Key Usage bits for ECDH or tag that this
is only dealing with EdDSA.

8.  Section 5 and 7 - I do not see any reason to have distinct OIDs for the
signature and public key algorithms unless you believe that this is going to
be useful in the future.  Using the same OID makes life easier since it
automatically allows for an easy way to say that this key is only to be used
with this algorithm.

9.  Section 8 -  Remove the OPTIONAL on the parameters field.  I would
really prefer that you defined a different structure for the EdDSA keys as
the use of NamedCurve means that one needs to create an association between
an OID and an enumeration.  I think this is a bad idea, the same value
should be used in both cases.  Having different parameters for the algorithm
depending on where it is encoded (public or private key).  Additionally, one
wants to be able to do the restriction to an EdDSA-ph algorithm.  This means
that one does not use the ECParameters field for those keys.

10.  General - please note that the structure ECParameters from RFC5915 and
RFC5480 is the same as EcpkParameters from RFC3279.  Using two different
names for the same structure looks somewhat confusing.  It would be better
to use ECParameters and not reference 3279 at all.

Jim