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

[Ryan Sleevi <[e-mail]>]

On Thu, Jul 29, 2021 at 7:17 PM Daniel Kahn Gillmor <[e-mail]>
wrote

> If anyone has any tooling that can make a clear and concise picture of
> the differences between the objects (or can condense the screenfuls of
> text that most detailed debuggers produce to highlight the specific
> changes), that would be super useful.
>

 So I don't have a great answer for you here - I don't play much with
CMS/P7, but there's a pretty clear difference between laundered and
original that most tools (e.g. https://github.com/google/der-ascii,
https://lapo.it/asn1js/ , openssl asn1parse ) point out

In bob.p12, starting with offset 22, it goes
  CONSTRUCTED context-specific tag 0 (len 6049)
    OCTET STRING (len 6045)
       SEQUENCE (len 6041)

In bob.laundered.p12, starting with offset 18, it goes
  CONSTRUCTED context-specific tag 0 (len 6948)
    OCTET STRING (len 6944)
      OCTET STRING (len 6938)
        SEQUENCE (len 6936)

That is, there's a double OCTET STRING encoding here before the actual
content.

It's clear that in both of these tag-0 is part of the ContentInfo structure
(as it's part of a sequence with the previous value being the id-data OID).

id-data is an OCTET STRING type, with the interpretation left to the
application - https://datatracker.ietf.org/doc/html/rfc5652#section-4

The reason for the double encoding is because
https://datatracker.ietf.org/doc/html/rfc7292#section-4.1 - that is
   The content field of the authSafe shall, either
   directly (data case) or indirectly (signedData case), contain a BER-
   encoded value of type AuthenticatedSafe."

I'm not sure if this is your root cause, because I haven't poked to see
which of Apple's decoders and which of Thunderbirds' encoders are in play,
but it would _seem_ they're consistent in interpreting this as:

- 5652 requires that `id-data` be an OCTET STRING
- 7972 requires that the *contents* of that OCTET STRING be a BER-encoded
value of type AuthenticatedSafe, expressed as an OCTET STRING

Hence, "double" OCTET STRING encoded - the first to satisfy 5652, the
second to satisfy 7972.

At least, just judging from the first few bytes.