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

Ryan Sleevi <> Thu, 29 July 2021 23:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BD623A1121 for <>; Thu, 29 Jul 2021 16:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mb9xa2aJS4-g for <>; Thu, 29 Jul 2021 16:58:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5241C3A10E0 for <>; Thu, 29 Jul 2021 16:58:54 -0700 (PDT)
Received: by with SMTP id u2so618780plg.10 for <>; Thu, 29 Jul 2021 16:58:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IaSimbxMIxDp9jU6zCP8NW1sZi1RmOqsG7aR8TSV6g8=; b=KRTtNRTlsOa9oQrbJCv8SLPVTiEtV3OsTO/3ZsF2F//vyfg97k2VpQjWPVlX7a33MO S3WI6OYmIjVxTM2krM0IO8u2VNZUX7jYScn4q24TYbZEOBahut862bzgnzYLNNqNKrlD RAt9ivmboXfPwkGd5RQ6LXMHMuXSytzvR/f5W1kBJfXMr5d4LWCOfZJtmbGw2mYx/jJ1 YJwQxHcA1ZUZ7rxAMyP1eqQsAB7UdukJ6Ro7zpOS9p43xLDMmzOo0cApzooOThBOjT+I jU8j72dKpViQsRQyP/uHVZwIBbfw16QRhnKtjC8xFIC++Nhde4FDPGh9D0yhfwO9bggu T79Q==
X-Gm-Message-State: AOAM530+bqe3Le9QaTV6PJyOyKLz71AOUFvyRLIOqPiWjiUEteEkrhRe D0loJsOkB1+QO9XzhhyUukr6HZ9y7a0=
X-Google-Smtp-Source: ABdhPJw7khxg/g7Qi5M/RKSiFr2uJ3R3rIQeJPhrORethlNsQPEfjnTqYg1Rmw2mzdnhzvsP2MYqOg==
X-Received: by 2002:aa7:90cd:0:b029:333:baa9:87b7 with SMTP id k13-20020aa790cd0000b0290333baa987b7mr7547723pfk.23.1627603133397; Thu, 29 Jul 2021 16:58:53 -0700 (PDT)
Received: from ( []) by with ESMTPSA id x7sm4825509pfn.70.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 16:58:53 -0700 (PDT)
Received: by with SMTP id j1so12563652pjv.3 for <>; Thu, 29 Jul 2021 16:58:53 -0700 (PDT)
X-Received: by 2002:a17:902:d112:b029:12c:2004:981d with SMTP id w18-20020a170902d112b029012c2004981dmr6845497plw.29.1627603132852; Thu, 29 Jul 2021 16:58:52 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Thu, 29 Jul 2021 19:58:41 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Daniel Kahn Gillmor <>
Content-Type: multipart/alternative; boundary="00000000000091adb505c84be208"
Archived-At: <>
Subject: Re: [lamps] draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jul 2021 23:59:06 -0000

On Thu, Jul 29, 2021 at 7:17 PM Daniel Kahn Gillmor <>

> 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., , 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

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 -

The reason for the double encoding is because - 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.