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

[Peter Gutmann <[e-mail]>]

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

>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.

>A lot of the ASN.1 definitions seem to describe how to package private keys.
>Considering that interoperability in the majority of cases is about
>applications communicating “over the wire” using S/MIME, CMS, TLS or IKE key
>exchange, etc. – 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.  Then when people needed to store something other than RSA keys they
invented their own formats extending PKCS #8, principally led by OpenSSL (who
had the most need for it) but occasionally other vendors as well, whoever got
the most mindshare first.  The issue was resolved by PKCS #15 which specified
a general format for public and private keys, but everyone ignored that and
invented their own new format for each new public-key algorithm.

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.

(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).

Peter.