Re: [saag] PKIX and related RFCs - definition of Key Packages

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

> I think the short answer is that public keys are usually exchanged by sending certificates.

I'm not sure I understand - private keys usually are not exchanged at all, and yet there's a whole bunch of ASN.1 stuff describing them.

> Raw public keys that are not associated with an identity can lead to subtle security
> vulnerabilities (Mallory swaps Mallory's public key for Alice's without Bob noticing). 

This is supposed to be not about what good a standalone public key is - but about how to represent and encode that public key in an interoperable way. Whether such encoding makes sense outside of any context is a totally different question, which to me seems irrelevant to the main one - how to encode a public key that is not a simple big integer.

> Sorry to be the bearer of bad news, but you may be headed for a serious encounter
> with X.509, e.g., via RFC 5280.

That is indeed bad news, but on the other hand - a good start. __

>    >Yet the definitions invest in the details of the private keys, leaving the
>    >public key as “BIT STRING OPTIONAL”. Why is it so?
>
>    Cargo cult protocol design.  Back in the late 1980s someone decided that holes
>    containing keys had to be BIT STRINGs.  So today, thirty-plus years later,
>    holes containing keys are still (mostly) BIT STRINGs even though what's
>    present in the hole is always an OCTET STRING.

Excellent. That means there's no hidden wisdom in there, and I can (and will) in my design revert this to what Common Sense suggests: an OCTET STRING CONTAINING the specific format/encoding structure that a specific algorithm (e.g., lattice-based) would require for ensuring an app can correctly decode it in an interoperable way.

>    > A lot of the ASN.1 definitions seem to describe how to package private keys.
>    >  .  .  . [though]  .  .  . the predominant need appears to be exchanging public
>    > (not private) keys?
>
>    More cargo cult protocol design.  PKCS #8 specified the format for RSA private
>    keys but nothing else, for the simple reason that there was nothing else at
>    the time.  .  .  .
>
>    As a result, when you write an RFC specifying the format for public keys for
>    algorithm X for, for example, S/MIME, you also need to specify the private-key
>    format even though it has nothing to do with S/MIME.  Rot bilong kago.

Hmm... What would happen if in a new document I choose not to specify private-key format...? 
Given the fact that it's (practically) never present on the wire, and compliance/interoperability for its implementation cannot be tested?

>    (And as a general note, a lot of the WTF?!!? stuff in PKIX is explainable
>    through cargo cult protocol design, it's not just these two).

I see. Thank you very much for explaining - unfortunately, it makes a lot of sense. ☹

On the other hand, it seems to mean that (due to this lack of definitions) there's nothing to be backward-compatible with, so one can (finally, hopefully, maybe) do it right...

Thanks!