Re: [Curdle] Review of draft-ietf-curdle-pkix-04

[David Benjamin <[e-mail]>]

On Wed, Mar 29, 2017 at 12:31 PM David Benjamin <[e-mail]>
wrote:

> Overall, the document looks good to me. I've actually just implemented it
> along with the TLS bits in BoringSSL and our Go testing implementation.
> Seems to work. (Though I haven't done anything with the signature yet, just
> parsing out keys. Our X.509 story is a little funny since Chrome currently
> uses OS verifiers.)
>
> I have a handful of comments. They are all entirely editorial and mostly
> nitpicks.
>
> In section 3,
>
>    The same algorithm identifiers are used for identifying a public key,
>    identifying a private key and identifying a signature (for the four
>    EdDSA related OIDs).  Additional encoding information is provided
>    below for each of these locations.
>
> "four EdDSA related OIDs" should now be "two EdDSA related OIDs"
>
> In section 4,
>
>    o  subjectPublicKey contains the byte stream of the public key.
>       While the encoded public keys for the current algorithms are all
>       an even number of octets, future curves could change that.
>
> I would suggest replacing the last sentence with "For the algorithms
> defined in this document, the encoded public keys are an even number of
> octets." If future curves do something funny, they'll be defined with
> independent OIDs and won't be bound by any explanatory notes in this
> document.
>
> In section 5,
>
>    If the keyUsage extension is present in a certificate that indicates
>    id-X25119 or id-X448 in SubjectPublicKeyInfo, then the following MUST
>    be present:
>
> "id-X25119" should be "id-X25519".
>
> Also, a exceedingly nitpicky nitpick: the various lists of keyUsage values
> are all indented differently. I'm not sure if this is an artifact of some
> centering thing or a formatting error.
>
> In section 7,
>
>    For the keys defined in this document, the private key is always an
>    opaque byte sequence.  The ASN.1 type CurvePrivateKey is defined in
>    this document to hold the byte sequence.  Thus when encoding a
>    OneAsymmetricKey object, the private key is wrapped in an
>    CurvePrivateKey object and wrapped by the OCTET STRING of the
>    'privateKey' field.
>
> The 'privateKey' field is described with single quotes, but in the
> following paragraph, the "privateKey", "privateKeyAlgorithm", and
> "publicKey" fields are described with double quotes.
>
> In section 8,
>
>    When the curve is known, use a more specific string.  For the id-
>    EdDSA25519 value use the string "Ed25519".  For id-EdDSA448 use
>    "Ed448".
>
> In keeping with its own advice and to match the names in section 3,
> "id-EdDSA25519" should be "id-Ed25519" and "id-EdDSA448" should be
> "id-Ed448".  The names also show up elsewhere in the document and should
> match.
>

Er, by "the names", I meant "id-EdDSA25519". That is, there are other
instances which should be switched too. (Actually "id-Ed25519" only shows
up once, but I think that is a better name.)


> In section 10.2,
>
> The OIDs in the sample certificate are referred to as "EdDSA 25519
> signature algorithm" and "ECDH 25519 key agreement", contradicting the
> document's own advice on human-readable names.
>
> David
>