Subject: [apps-discuss] PKIX text encodings

From: Simon Josefsson <[email-masked]>
Date: Fri, 27 Jan 2012 14:45:06 +0100

Folks,

See announcement below for a document that attempts to describe the
de-facto deployed usage of so called "PEM encoding" of X.509 related
data blobs, including the '-----BEGIN CERTIFICATE-----' format.  Many
applications and security libraries rely on these formats, but to my
knowledge they have never been standardized and there is unfortunately
some confusion and ambiguity as a result.

https://tools.ietf.org/html/draft-josefsson-pkix-textual

As usual, comments and suggestions are appreciated.  I'm not certain
what fora is best for discussing the document, but I suspect the apps
area group may be an appropriate venue, thus I'm adding an appropriate
Mail-Followup-To header.  If anyone believes discussion is inappropriate
there, I'm happy to move the discussion elsewhere.

If someone remembers the history around how the format was created,
anecdotal or otherwise, that would also be helpful.

Thanks,
Simon

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : Text Encodings of Some Security Related Structures
> 	Author(s)       : Simon Josefsson
> 	Filename        : draft-josefsson-pkix-textual-00.txt
> 	Pages           : 10
> 	Date            : 2012-01-27
>
>    This document describe and discuss the text encodings of Public-Key
>    Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate
>    Revocation Lists (CRLs), PKCS #10 Certificate Request Syntax, PKCS #7
>    structures, and Attribute Certificates.  The text encodings are well-
>    known, implemented by several applications and libraries, and is
>    widely deployed.  This document is intended to articulate the de-
>    facto rules that existing implementations operate by, and to give
>    recommendations that will promote interoperability going forward.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-josefsson-pkix-textual-00.txt

---

From: Sean Turner <[email-masked]>
Date: Fri, 27 Jan 2012 09:50:14 -0500

Simon,

The same kind of format is also used for keys:

https://datatracker.ietf.org/doc/rfc5915/
https://datatracker.ietf.org/doc/rfc5958/

Is it worth pointing to the media types for the objects?

If you're going to reference RFC 4648, then you need to specify which 
alphabet (the apps guys are always pointing this out).

spt

On 1/27/12 8:45 AM, Simon Josefsson wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Jan 2012 10:20:42 -0800

On Jan 27, 2012, at 10:11 AM, 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 up. I propose this is not a good idea from a security perspective. 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 important.

> 
> Normally, these PEM-framed base64 encodings are used for administrative
> interfaces used by humans that are used with a low frequency,
> rather for authentication exchanges that are used with a high
> frequency. For administrative user interfaces it is usually sensible to
> spend a few extra CPU cycles to improve the usability.
> 
> Strongly recommeding standardized labelling on output of these formats
> is OK, and may facilitate troubleshooting.
> 
> But on input, e.g. when processing a certification response, the
> administrative interface should IMO be tolerant to accept a single
> certificate (provided the remaining certs required to build a
> complete path are already present), accept a sequence of several
> certificates, or a PKCS#7 container carry multiple certificates,
> independent of what labels are used with BEGIN/END.

These are all separate issues, but definitely worthy of discussion in the document. "Some systems will accept multiple certificates in a single text block, while others will reject the entire text block as malformed if more than one certificate is included."

> When the administrative interface has access to the PKI credentials
> for which a certification response is to be processed, then it
> can detect the end-entity cert automatically, compose the full
> and correctly ordererd certificate chain automatically, and ignore
> any superfluous/unrelated certs that may have been part of the input.
> 
> 
> Btw. PKCS#7 can also be used as a carry bag for multiple CRLs,
> which can be used to allow revocation checking in offline
> scenarios or on isolated networks.

Indeed.

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.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Jan 2012 19:11:05 +0100 (MET)

Simon,

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 28 Jan 2012 01:37:45 +0100 (MET)

Paul Hoffman wrote:
> Martin Rex wrote:
> This would cause things like private keys and public keys to be mixed up.

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

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.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Jan 2012 20:29:27 -0800

> from your public key, then you have a whole different kind of problem.

Indeed, but it is a new problem that you probably didn't plan for. There is no need to introduce the problem at this late date.

> so how should this be a security problem?

These blobs are often handed around out-of-band, so removing a bit of information can indeed introduce a security problem.

> This is really only about convenience for admins.

That's one view, but not the only one.

> of objects that are applicable for the requested operation.

You are assuming, I believe incorrectly, that the ASN.1 decoding is happening in the same part of the system as the base64 decoding. That's not a safe assumption. In your code, it might be fine; it is probably not fine in all code. Why throw away valuable information?

> of what label is used.  Same for certificate (.cer).

Um, so? That's one implementation.

> and PKCS7 as "PKCS7" or "CERTIFICATE" but _not_ "X509 CERTIFICATE"

Fully agree. That's why it is good that someone (Simon!) is doing this work.

> because the installed base is going to be with us another 10+ years.

You and I live in different universes.

--Paul Hoffman

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 30 Jan 2012 13:06:26 +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