Re: [lamps] draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)

[Ryan Sleevi <[e-mail]>]

On Wed, Aug 4, 2021 at 8:49 PM Daniel Kahn Gillmor <[e-mail]>
wrote:

> > As Russ and I both noticed, it would appear bob.p12 is going directly
> > to a SEQUENCE, rather than OCTET STRING -> SEQUENCE.
>
> The tooling i've been playing with confirms this read.
>

Right, but bob.p12 does not appear to match this (it goes data -> SEQUENCE,
not data -> OCTET STRING -> SEQUENCE, unless I'm truly holding things
wrong), and that's why I was trying to understand the process for that
being generated.


> From what i can tell, both of these PKCS12 objects are in the definite
> form (good), but both also appear to show only one layer of OCTET STRING
> encoding around the SEQUENCE.  Can you confirm?
>

Right, my previous message tried to explain that this is expected from DER
encoding. The single layer of OCTET STRING is the correct form, the
multiple layers I mentioned were a quirk of how indefinite BER (which NSS
was generating, and which I overlooked) was generating. So we should ignore
this as being the cause here - it was very much PEBKAC on my part for
overlooking the indefinite length on the BER.


> So, if my analysis is correct, maybe the issue isn't about layers of
> OCTET STRING but rather something about the struture of the PKCS#12
> object itself inside those layers?
>

Yes


> Some theories worth testing:
>
>  a) The order of the certificates and encrypted pkcs8 blobs might
>     matter.
>
>  b) The absence of the friendlyName on bob.p12[bag[1]] might matter.
>
> Are there rules for how a PKCS#12 interpreter is supposed to associate
> private keys with certificates that depend on both friendlyName and
> localKeyID matching within the bundle?
>

I don't see any such rules about matching, period, in RFC 7292.