Re: [lamps] On the need for standardization of software-based interoperable private keys [was: Re: draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)]

[Daniel Kahn Gillmor <[e-mail]>]

On Thu 2021-08-05 13:33:26 +0100, Stephen Farrell wrote:
> We tried that before [1] but it might be worth another shot.
>
> [1] https://tools.ietf.org/wg/sacred/

Thanks for pointing out this history, Stephen.  This predates IETF's
adoption of PKCS#12 (RFC 7292), though, by many years afaict.

The fact remains that there *is* a defacto standard for transfer of
bundled private keys and X.509 certificates, and IETF has formal change
control over it (PKCS#12).  If it doesn't live in LAMPS, despite being
used to exchange certificates and CRLs as well as private keys, i'm not
sure where it would live.  I'm loathe to spin up a new WG.

> I think the critical question, then as now, is whether or not
> applications would adopt.

If we wanted to make it harder to adopt, we could invent something new
from scratch. :)  that doesn't seem like a great idea.

If we wanted to improve existing implementations to enable better
interoperability with the existing defacto standard that we're
responsible for, we could:

 - try to establish a minimal common profile PKCS#12, which is far too
   flexible for its own good, and report bugs against implementations
   which deviate from that profile.  This being the IETF, i'm sure we'd
   come up with more than one "common" profile, but even a half dozen
   profiles would be an improvement over the multidimensional confusion
   that the standard permits.

 - build an interop test suite to identify failures in implementations
   that try to import any of the common profiles.

or,

 - formally deprecate PKCS#12 (e.g. move 7292 from informational to
   historical) and encourage some other standard (a PKZIP file full of
   independent PKCS#8 objects and certificate objects?  that seems
   morally equivalent to PKCS#12 to me, but a much longer lead time to
   get any sort of adoption)

I'll probably end up doing some of this work anyway just because i want
draft-ietf-lamps-samples to contain plausible objects that can be used
by most systems, but i'd be happy to have the WG behind it.

   --dkg