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

[Russ Housley <[e-mail]>]

> On Aug 9, 2021, at 12:57 PM, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> Signed PGP part
> On Sat 2021-08-07 11:52:07 -0400, Russ Housley wrote:
>>> On Aug 5, 2021, at 1:12 PM, Daniel Kahn Gillmor <[e-mail]> wrote:
>>> 
>>> - 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)
>> 
>> RFC 5208 is the PKCS#8 v1.2 specification.
>> 
>> RFC 5985 is an enhancement to PKCS#8 that allows the certificate to be carried along with the private key.  In addition, RFC 5985 provides a content type for PKCS#8.
>> 
>> RFC 4073 defines a way to carry a collection of contents, each with their own type:
>> 
>>      ContentCollection ::= SEQUENCE SIZE (1..MAX) OF ContentInfo
>> 
>> These seem to be the building blocks that are needed to carrya a collection of PKCS#8-protected private keys along with the associated certificate.
> 
> Thanks, Russ!  I appreciate this collection of pointers, but i am not
> convinced they belong in draft-ietf-lamps-samples today given that i
> don't know of any tooling that is capable of ingesting them.
> 
> If someone in the WG wants to assemble such an object from the keys and
> certs already in the draft, and other folks in the WG can independently
> confirm that it appears to be correct, then i'd be fine with including
> it alongside the PKCS#12 objects that the draft currently publishes.
> I'd be even more strongly convinced if someone can point to an
> implementation that is capable of processing them.
> 
> Including such an object in the spec might be a helpful spur for
> adoption!  But without other people stepping forward to assemble and
> test the pieces and point to implemententations, i'm inclined to leave
> this as future work so we can get draft-ietf-lamps-samples out the door.

I was not suggesting them for lamps-samples.

I was pointing out a simple way to construct an alternative to PKCS#12 for multiple private keys and their certificates.

Russ