Re: [pkix] Strawman on EdDSA/Ed25519 for PKIX Certificate/CRLs

[Simon Josefsson <[e-mail]>]

Erwann Abalea <[e-mail]> writes:

> Bonjour,

Hello.  Thank you for the feedback!

> Section 5: EdDSAParameters is an ENUMERATED with (for now) only one value:
> "ed25519", which designates a signature algorithm and not a set of public
> key parameters. I guess one might want to find "curve25519" and "curve448"
> here. Since this type is used with a public key algorithm, naming it with a
> signature algorithm might not be suited.

Actually "ed25519" designates the EdDSA parameters.  They have an impact
on how the public key looks -- EdDSA public keys are not compatible
across hash functions.  Ed25519 implies SHA-512, which implies how the
public key is derived.  I tried to clarify this point by adding the
following sentence:

      The value "ed25519" means the set of EdDSA parameters
      associated with Ed25519, including hash function and curve.

Saying "curve25519" does not feel right to me since it only describes
the curve.  To know the encoding the public key encoding for EdDSA you
also need to know the hash function.

Do you agree?

> Section 5: the subjectPublicKey BIT STRING seems to contain an additional
> OCTET STRING, which isn't necessary at this moment (however, since point
> encoding hasn't been decided yet at CFRG, it may change).

I don't know if you looked at -00 or -01.  In -00 there was an
additional OCTET STRING step.  People suggested that it just waste
space, so I removed it for -01.  I have now added another sentence
clarifying that it is not there:

      <t>The raw binary EdDSA public key is encoded directly in the
      subjectPublicKey BIT STRING object.  Note that unlike some other
      schemes, there is no additional OCTET STRING encoding step.</t>

> Section 6: what is the rationale to define keyUsage values here? I'd drop
> this section.

I copied this from RFC 5480.  I'm not sure what value there is in having
it, but it looks harmless and potentially useful to me.  I could remove
it too.

> Section 7: signature parameters will be necessary and will be declared
> either within the algorithm OID (as is done with ECDSA-with-*), within the
> parameters data element, or both (as is done with RSASSA-PSS); right now,
> Ed25519 is hardcoded to use SHA512, but you'll have to consider EdDSA with
> other hash functions, or different curves (it's not yet decided which hash
> function to use with curve448).

My intention is that the signature parameters follow from the public key
parameters.  The document says:

      <t>This document identify an AlgorithmIdentifier OID for EdDSA
      signatures.  No parameters are defined.  The EdDSA parameters
      follow from the public-key parameters.</t>

Is there any value in repeating the parameter for the signature?  To
validate the signature, you need the public key anyway.

> Section 7: signature encoding itself must also be defined (or referenced);
> for ECDSA, it's a SEQUENCE of 2 INTEGERs; here, it seems that r and s are
> concatenated, but it's stated nowhere (maybe draft-josefsson-eddsa-ed25519?)

Yes, I'm hoping draft-josefsson-eddsa-ed25519 takes care of that, see
section 4.3 of it.  I added some text pointing this out:

      This value is the opaque value ENC(R) || ENC'(S) described in
      section 4.3 of <xref target="I-D.josefsson-eddsa-ed25519"/>.

> Section 8: the example certificate doesn't use the EdDSAParameters type to
> indicate the curve used.
> Section 8: the example certificate doesn't follow section 7 (parameters
> MUST be absent)

Yep, the test vector needs to be update -- will work on that.

Thanks,
/Simon

>
>
> 2015-06-15 22:10 GMT+02:00 Simon Josefsson <[e-mail]>:
>
>> Hi,
>>
>> I have updated the document a bit.  It appears likely that EdDSA will be
>> usable with other parameters than Ed25519, so I made the EdDSA
>> parameters an algorithm parameter rather than implied from the OID.
>>
>> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-01
>>
>> An (already outdated) example of an EdDSA X.509 certificate and EdDSA
>> public-key is also included, so you can throw it at your ASN.1 parsers.
>>
>> /Simon
>>
>> _______________________________________________
>> pkix mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>