Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03

[David Benjamin <[e-mail]>]

On Thu, Dec 15, 2016 at 1:42 AM str4d <[e-mail]> wrote:

> On 12/15/2016 02:23 AM, David Benjamin wrote:
> > On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara <
> [e-mail]>
> > wrote:
> >
> >> On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote:
> >>> Hello,
> >>>
> >>> I am currently updating my EdDSA Java library to implement the current
> >>> spec for key encoding [0] (previously I used
> >>> draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in
> >>> PKCS#8 format for private keys). The example public key given in
> >>> draft-ietf-curdle-pkix-03 [1] passes my tests, however the example
> >>> private key [2] does not.
> >>>
> >>> It appears that the private key material within the example is 34
> bytes,
> >>> but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which
> >>> AFAICT the present draft defers to for encoding), the private key is
> the
> >>> b-bit seed k, which is 32 bytes.
> >>>
> >>> Am I missing something? If the example keys in the present draft are
> >>> correct, it would be helpful to add a reference that clarifies their
> >>> exact encoding.
> >>
> >> Apparently the key is wrapped in OCTET STRING twice for some reason,
> >> so the length is actually 32 bytes (the first 2 are second OCTET STRING
> >> header).
> >>
> >
> > Is it too late to change that / was there any particular reason for this?
> > Not that saving or using two bytes really matters, but it seems
> unnecessary
> > when we already have an OCTET-STRING-shaped hole to put our octet string
> in.
> >
>
> Additionally, it is somewhat strange that the same document
> (draft-irtf-cfrg-eddsa-08) would define that the public key requires no
> additional OCTET STRING wrapping, while the private key does. I
> personally don't have a problem implementing it this way if that is what
> the WG decides, but one of the two documents needs to be updated
> regardless of whether or not this is changed (either to change it or to
> clarify the encoding).
>

Even if it stays as-is, I do not think draft-irtf-cfrg-eddsa should be
changed to mention the OCTET STRING wrapping. EdDSA public and private keys
are encoded as specified by draft-irtf-cfrg-eddsa-08. If you just need to
store one of those, you use it. Neither use ASN.1 at that layer since
there's no need. Serialization asks for a byte string, and we already have
a way to return a byte string.

If you need to store them in an SPKI or PKCS#8 blob, you then follow
draft-ietf-curdle-pkix which calls into that serialization and adds a bunch
of ASN.1. The PKCS#8 wrapping, for some reason, prescribes two layers of
OCTET STRING wrapping right now. This, though odd, is still self-consistent.

David