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

[str4d <[e-mail]>]

On 12/16/2016 02:27 AM, David Benjamin wrote:
> 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.

I've figured out the source of my confusion (and you're right, it wasn't
related to draft-irtf-cfrg-eddsa, that was my mis-remembering): section
7 of draft-ietf-curdle-pkix is somewhat obtuse (to someone not
well-versed in IETF lingo) as to how the various ASN.1 types are
stacked. Specifically, on my first read of that section it seemed that
the EdPrivateKey type took the place of the PrivateKey type in
OneAsymmetricKey. But reading it again now, I can see that the intent of
the section is:

OneAsymmetricKey ::= SEQUENCE {
    ...,
    privateKey PrivateKey(EdPrivateKey(byte sequence))
    ...
}

I think the confusing language is the use of "wrapped in" followed by
"placed in", which implied to me that these were different actions, when
in fact they both refer to the same action of wrapping in OCTET STRING
(resulting in the aforementioned two layers).

Perhaps a clarification in this section might be pertinent? Or maybe I'm
an outlier, and everyone who normally reads these specs will be
completely familiar with the intended usage constraints of ASN.1 types
*shrug*

In any case, thanks for clearing up my confusion! Should I wait around
for consensus on whether the layering is likely to change, or go ahead
with implementing as-is? I don't really want to implement a second
backwards-compatibility handler later ^_^;

Cheers,
str4d