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

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 16 Jun 2021 20:53:24 +0000

I confess that until now I never bothered actually looking with a critical eye at RFC 5958, 5208, 5915 and such – because the apps that presumably use them to interoperate, were already written by somebody else and (sorta ;) working.

Now, as I’m looking at extending those definitions to Post-Quantum algorithms and parameters, I’m seeing what appears weird to me.

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?

Yet the definitions invest in the details of the private keys, leaving the public key as “BIT STRING OPTIONAL”. Why is it so?

IMHO, first – PublicKey should be OCTET STRING (probably not OPTIONAL), probably CONTAINING {}. Then, each specific IETF-accepted algorithm should have its own definition of how to serialize its public key, maybe wrapping the result into an OCTET STRING (usually this is done to allow parser that doesn’t understand the format, to skip this field)… 

Is it too late to rectify? And if I’m missing something, could you enlighten me please? Am I barking at the wrong tree altogether? If so, where is the public key serialization described, if not here? And why not here?

Thank you! And apologies for the exhibited ignorance.

Here are some examples of what I’m talking about:

ECPrivateKey ::= SEQUENCE {

     version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),

     privateKey     OCTET STRING,

     parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,

     publicKey  [1] BIT STRING OPTIONAL

   }

OneAsymmetricKey ::= SEQUENCE {

     version                   Version,

     privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,

     privateKey                PrivateKey,

     attributes            [0] Attributes OPTIONAL,

     ...,

     [[2: publicKey        [1] PublicKey OPTIONAL ]],

     ...

   }

PublicKey ::= BIT STRING

                     -- Content varies based on type of key. The

                     -- algorithm identifier dictates the format of

                     -- the key.

--

Regards,

Uri Blumenthal                              Voice: (781) 981-1638 

Secure Resilient Systems and Technologies   Cell:  (339) 223-5363

MIT Lincoln Laboratory                      

244 Wood Street, Lexington, MA  02420-9108      

Web:     https://www.ll.mit.edu/biographies/uri-blumenthal

Root CA: https://www.ll.mit.edu/llrca2.pem

There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 17 Jun 2021 06:19:51 +0000

Blumenthal, Uri - 0553 - MITLL <[email-masked]> 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.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 17 Jun 2021 13:06:50 +0000

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

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

>    >  .  .  . [though]  .  .  . the predominant need appears to be exchanging public
>    > (not private) keys?
>
>    the time.  .  .  .

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?

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Jun 2021 09:50:45 -0400

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

Yes, this is needed.  For example, PKCS#12 can be used to move a private key from one device to another.

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Jun 2021 17:19:34 -0400

I agree with much of Uri's frustration here. My concern is the meta level.
If LAMPS is going to ever close, we have to make sure we are not going to
need something similar in future. Which means that we need to define what
is required to specify a cryptographic algorithm so it is available for use
with IETF protocols.

Note that adding an algorithm to a registry does not mean it is approved
for use by a particular protocol.

CMS serves a much wider audience than S/MIME. PKIX, a wider audience than
either the WebPKI or PKI in general. Same for JOSE, XML Signature and
Encryption, etc. etc.

So I conclude that one of the exit criteria for LAMPS should be a
document describing the list of things that need to be specified so that an
algorithm can be used in various specific IETF protocols and conversely,
what applications using the IETF maintained IANA registries can expect.

I do not want to get into discussions of why the decisions of some
working group ten years ago on algorithm requirements should bind some
other group doing something different today. HTTP is not based on MIME but
it uses the same IANA registry. That is the correct approach in my view.

Going forward, I see no reason why it should be necessary to specify
separate identifiers for the use of a particular algorithm in every
different application protocol. The ASN.1 world is going to need OIDs for
quite some time and the JOSE world is going to be needing text based
labels. The XML world consumes URIs but there is no reason we couldn't
specify a URN prefix to the JOSE labels and use that to avoid further
maintenance issues.

TLS and IPSEC both operate at a layer that is sufficiently deep that we
should just let them do their own thing. And PEM probably isn't much of a
concern going forward.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 17 Jun 2021 22:06:59 +0000

Thank you, and I concur.

--

Regards,

Uri

                                                                                                                                     -  C. A. R. Hoare

From: Spasm <[email-masked]> on behalf of Phillip Hallam-Baker <[email-masked]>
Date: Thursday, June 17, 2021 at 17:20
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [lamps] META Re: [saag] PKIX and related RFCs - definition of Key Packages

I agree with much of Uri's frustration here. My concern is the meta level. If LAMPS is going to ever close, we have to make sure we are not going to need something similar in future. Which means that we need to define what is required to specify a cryptographic algorithm so it is available for use with IETF protocols.

Note that adding an algorithm to a registry does not mean it is approved for use by a particular protocol. 

CMS serves a much wider audience than S/MIME. PKIX, a wider audience than either the WebPKI or PKI in general. Same for JOSE, XML Signature and Encryption, etc. etc.

So I conclude that one of the exit criteria for LAMPS should be a document describing the list of things that need to be specified so that an algorithm can be used in various specific IETF protocols and conversely, what applications using the IETF maintained IANA registries can expect.

I do not want to get into discussions of why the decisions of some working group ten years ago on algorithm requirements should bind some other group doing something different today. HTTP is not based on MIME but it uses the same IANA registry. That is the correct approach in my view.

Going forward, I see no reason why it should be necessary to specify separate identifiers for the use of a particular algorithm in every different application protocol. The ASN.1 world is going to need OIDs for quite some time and the JOSE world is going to be needing text based labels. The XML world consumes URIs but there is no reason we couldn't specify a URN prefix to the JOSE labels and use that to avoid further maintenance issues.

TLS and IPSEC both operate at a layer that is sufficiently deep that we should just let them do their own thing. And PEM probably isn't much of a concern going forward.