Re: [apps-discuss] [pkix] PKIX text encodings

"Miller, Timothy J." <> Mon, 30 January 2012 13:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3047921F86D1; Mon, 30 Jan 2012 05:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ffY4rm1sEeSZ; Mon, 30 Jan 2012 05:06:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 783BB21F86C4; Mon, 30 Jan 2012 05:06:28 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id C964421B0926; Mon, 30 Jan 2012 08:06:27 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG ( []) by (Postfix) with ESMTP id BABB721B094C; Mon, 30 Jan 2012 08:06:27 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([]) by IMCCAS02.MITRE.ORG ([]) with mapi id 14.01.0339.001; Mon, 30 Jan 2012 08:06:27 -0500
From: "Miller, Timothy J." <>
To: "" <>, Paul Hoffman <>
Thread-Topic: [pkix] PKIX text encodings
Thread-Index: AQHM3VUNcMLmsjko+UWci5xLcgDxQpYk1JcA
Date: Mon, 30 Jan 2012 13:06:26 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 30 Jan 2012 08:03:36 -0800
Cc: "" <>, "" <>, "" <>
Subject: Re: [apps-discuss] [pkix] PKIX text encodings
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Jan 2012 13:06:29 -0000

> Any reasonable ASN.1 decoder can reliably tell apart [...]

While any ASN.1 decoder + a little logic can discern one ASN.1 encoded
object from another, it would *really* help *non-decoding* applications to
have simple magic numbers when serializing ASN.1 to a file.

This has been a long-standing pet peeve of mine since I was asked to write
a scanner to find PKCS#12 files.  There's enough variation in encoding
that it's a real PITA to do a lightweight decode and still have a
reasonable false positive rate.

-- T

On 1/27/12 6:37 PM, "Martin Rex" <> wrote:

>Paul Hoffman wrote:
>> Martin Rex wrote:
>> >
>> > the Label that is used within '-----BEGIN <some-label>----'
>> > should be ignored on the receiver side, and all implemented formats
>> > should be tried, that are applicable for the requested operation.
>> This would cause things like private keys and public keys to be mixed
>Not necessarily.  If your ASN.1 decoder can not distinguish your private
>from your public key, then you have a whole different kind of problem.
>> I propose this is not a good idea from a security perspective.
>Huh?  That textual label is not integrity protected in any way,
>so how should this be a security problem?
>This is really only about convenience for admins.
>> Instead, Simon might add some text saying that some applications
>> sometimes ignore the label in order to be more liberal, but in doing
>> so can cause problems with systems that assume those labels are
>HUH?  How could being liberal on *INPUT* possibly cause problems?
>Any reasonable ASN.1 decoder can reliably tell apart
>  - X.509 certificates
>  - private keys
>  - encrypted private keys
>  - pkcs10 requests
>  - crls
>  - pkcs7/cms 
>  - pkcs7/cms as certificate bag
>  - pkcs7/cms as crl bag
>  - pkcs12
>So any implementation that is ignoring the explicit label, will have to
>use the implicit label from successfuly ASN.1 decode of the types
>of objects that are applicable for the requested operation.
>Microsoft seems to ignore the label.  If you double-click on
>a pkcs7 file (extension .p7s or .p7b) it will be PEM-decoded independent
>of what label is used.  Same for certificate (.cer).
>I find it much more confusing when only a few, but non-unique labels
>are accepted:
>OpenSSL seems to accept certs with "X509 CERTIFICATE" and "CERTIFICATE"
>and PKCS7 as "PKCS7" or "CERTIFICATE" but _not_ "X509 CERTIFICATE"
>> Just a thought: we define *new* labels that do what we think everyone
>> should do, such as multiple items in the block. There would not be much
>> uptake on those new labels in the short run, but could become the
>> standard 20 years from now.
>For OUTPUT we should try to find an reuse the most commonly used label,
>because the installed base is going to be with us another 10+ years.
>pkix mailing list