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)]

[Ryan Sleevi <[e-mail]>]

On Thu, Aug 5, 2021 at 12:32 PM Carl Wallace <[e-mail]>
wrote:

> [CW] I was not suggesting that but instead that a message be encrypted for
> each of your end points. I'm not sure why we are clinging to one encryption
> key per person. <snip>


Agreed.

In the parallel discussion being had by Michael Richardson and Rich Salz (
https://mailarchive.ietf.org/arch/msg/spasm/puyG9qwhxAQRBGbh8WIFxSZuPDQ/ ),
Michael asks

If we can get the legacy guys to open up their code, why fix PKCS12 if they
> could just move to PKCS8? (or PKCS1 or...?)
>

And I think that closely relates to the point you're making here.
Specifying an interoperable profile for PKCS#12 is a lot of effort, from a
specification side, and doesn't really address the implementation problem
of needing to support, for better or worse, existing keys. That is, it
seems we'll still have legacy producing bad-legacy, and then we'll have new
producing new-good, but implementations will end up needing to support both
paths, because in order for folks to adopt new-good, they'll want to bring
things in from old-legacy. The result of this is that, from an implementer
perspective, supporting/enforcing new-good is purely more work for them,
minimally at the production side (encoding), but if the goal is to reduce
the many mistakes of PKCS#12, then also at consumption side (decoding).

While it's true that old-legacy should be able to accept new-good, by
virtue of DER being compatible with BER, the inverse doesn't hold.

So Michael's question about activation energy is entirely relevant to what
I believe you're getting at, which is: If we're going to do anything,
should we be doing something tangibly better, and leaving this whole
silliness in the past? And yeah, I agree, we can do better, by reducing the
amount of key slinging that is happening, and being comfortable with the
existence of multiple keys. Protocols such as WebAuthN are designed around
this concept, as are the hardware tokens implementing it; the notion of
many keys (a key for origin/application), rather than trying to have One
Key to Rule Them All.

That still has the state change issue of old-legacy to new-good, but makes
it clearer that we're moving to a different system, which ends up being
more explicit that, yes, there are interoperability issues with old/new
expected, because they're unavoidable either way.

As it relates to the question of "Well, how do we deal with legacy", I
remain very much of the opinion of PKCS#8 being "good enough" as a format,
as it's what PKCS#12 uses under the hood still. So every PKCS#12 consumer
has the ability to consume PKCS#8 functionally, and that eliminates a huge
swath of complexity issues, so that works. The question of slinging keys
around becomes something dealt with at the protocol level, rather than the
format level, such as by accepting that a single entity may have many keys.
Yes, key management is hard, but that doesn't mean we should accept that
the solution is to put all of our proverbial eggs in one key basket. That
doesn't simplify the complexity, it just rearranges it (to key protection
and revocation).