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

Hi,

Please indicate if the text added by Jim clarifies the previous confusion,
and if we can close the thread.

My understanding of the text is:
"""the private key is wrapped in an CurvePrivateKey object """
CurvePrivateKey = OCTET STRING ( private key)
"""and wrapped by the OCTET STRING of the 'privateKey' field."""
privateKey = OCTET STRING (OCTET STRING (private key))

Am I correct ?

Yours,
Daniel

On Mon, Dec 19, 2016 at 4:34 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> In my local version, I have done the following:
>
>
>
> 1.       Changed EdPrivateKey to CurvePrivateKey.  I hope that this will
> not cause any confusion with the ECPrivateKey type defined in RFC5915.
>
> 2.      I have changed the last sentence in the paragraph mentioned below
> to
>         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.
>
> 3.      I have also expanded the appendix with the private key example to
> have 1) the current PEM format, 2) an ASN.1 dump and 3) the value of the
> private key.
>
>
>
> I debated using the OKP (Octet Key Pair) which was used in JOSE and COSE
> but decided not to.
>
>
>
> Jim
>
>
>
>
>
> *From:* David Benjamin [mailto:davidben@chromium.org]
> *Sent:* Thursday, December 15, 2016 11:18 PM
> *To:* Jim Schaad <ietf@augustcellars.com>
>
> *Cc:* curdle@ietf.org
> *Subject:* Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03
>
>
>
> So we don't end up with two variants of this floating around (this thread
> gives one data point of the current text being misinterpreted), What do you
> think about these editorial changes?
>
>
>
> 1. In the paragraph beginning "For the keys defined in this document
> [...]", add a sentence like "Note the opaque byte sequence is wrapped in
> OCTET STRINGs twice in total."
>
>
>
> 2. EdPrivateKey sounds like this only applies to Ed* rather than both Ed*
> and X*. It should probably be renamed. But the best name I can come up with
> right now is PrivateKeyWrapper, which is terrible. Another option is to
> avoid defining a type and just say:
>
>
>
>    For the keys defined in this document, the private key is always an
>
>    opaque byte sequence.  This is encoded in a OneAsymmetricKey
>
>    object by wrapping the sequence in an ASN.1 OCTET STRING
>
>    and placing its DER encoding in the 'privateKey' field. Note that
>
>    'privateKey' is itself an OCTET STRING, so the original byte
>
>    sequence is wrapped in OCTET STRINGs twice in total.
>
>
>
> David
>
>
>
> On Fri, Dec 16, 2016 at 1:56 AM David Benjamin <davidben@chromium.org>
> wrote:
>
> Ah, yes, I see OpenSSL has already shipped code which serializes X25519 in
> this way, as early as OpenSSL 1.1.0 in September. That's unfortunate. It
> would have been preferable to avoid this confusing double wrapper, but so
> it goes I guess.
>
>
>
> David
>
>
>
> On Fri, Dec 16, 2016 at 12:53 AM Jim Schaad <ietf@augustcellars.com>
> wrote:
>
> I believe that the OpenSSL people would be sad if we changed this at this
> time.  I did some interop testing with their developers before the last
> version was released and the OCTET STRING wrapper on the private key is
> what we were doing at the time.
>
> Jim
>
> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David Benjamin
> Sent: Wednesday, December 14, 2016 5:23 AM
> To: Ilari Liusvaara <ilariliusvaara@welho.com>; str4d <str4d@i2pmail.org>
> Cc: curdle@ietf.org
> Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03
>
> On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara <mailto:
> ilariliusvaara@welho.com> 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.
>
>
>
> David
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
>