Subject: [pkix] New Version Notification for draft-josefsson-pkix-textual-04

From: Sean Leonard <[email-masked]>
Date: Tue, 01 Jul 2014 15:35:08 -0700

Greetings S/MIME, PKIX, and SAAG lists:

A revised draft of PKIX text encodings has been published. There are 
only small changes.

Simon asked Stephen and Kathleen if they could sponsor the document.

We think it is pretty close to done, but look forward to reactions and 
comments.

Kind regards,

Sean Leonard

-------- Original Message --------
Subject: 	New Version Notification for draft-josefsson-pkix-textual-04.txt
Date: 	Tue, 01 Jul 2014 15:05:27 -0700
From: 	[email-masked]

A new version of I-D, draft-josefsson-pkix-textual-04.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:	draft-josefsson-pkix-textual
Revision: 04
Title:	  Text Encodings of PKIX and CMS Structures
Document date:	2014-06-30
Group:	  Individual Submission
Pages:	  15
URL: 
http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-04.txt
Status:   https://datatracker.ietf.org/doc/draft-josefsson-pkix-textual/
Htmlized: http://tools.ietf.org/html/draft-josefsson-pkix-textual-04
Diff:   http://www.ietf.org/rfcdiff?url2=draft-josefsson-pkix-textual-04

Abstract:
    This document describes and discuss the text encodings of Public-Key
    Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate
    Revocation Lists (CRLs), PKCS #10 Certification Request Syntax, PKCS
    #7 structures, Cryptographic Message Syntax (CMS), PKCS #8 Private-
    Key Information Syntax, and Attribute Certificates.  The text
    encodings are well-known, are implemented by several applications and
    libraries, and are 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.

Please note that it may take a couple of minutes from the time of 
submission until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Jul 2014 13:47:35 +0300

[ Trimming all lists except pkix ]

I am all in favor of this document progressing. Two reasons:

First, I (and I’m sure many others) have had to implement this format. There is a lot of software out there that uses these formats, and many others need to prepare input for such software. The format is not rocket science, but the usual way to implement this (which is what I did at the time) is to look at OpenSSL and do as it does. Having a document describing this is a great alternative to attempting to read OpenSSL.

Second, I am currently shepherding a document ([1]) that relies on this as a normative reference. If this document doesn’t progress, we’ll have to just rip off large parts of it, and that would be a shame.

A few editorial comments:
- First line of the abstract: s/discuss/discusses/
- Too many spaces between “M.” and “Rose” in the introduction.

Other comments:
- Regarding the label in the -----BEGIN and -----END lines, section 2 says "The label type implies that the encoded data follows the specified syntax. Parsers MUST handle non-conforming data gracefully.”. What does “gracefully” mean? Not crash?  Always good advice. But if a parser expects to get a certificate, but the label says “-----BEGIN cErTiFiCaTe-----“, should it parse?  What if it says “-----BEGIN CRL-----“?
- Section 4.3: I’ve also seen .pem used for these files. 

Yoav

[1] https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

On Jul 2, 2014, at 1:35 AM, Sean Leonard <[email-masked]> wrote:

> A revised draft of PKIX text encodings has been published. There are only small changes.
> 
> We think it is pretty close to done, but look forward to reactions and comments.
> 
> Kind regards,
> 
> Sean Leonard
> 
> URL: http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-04.txt

---

From: Sean Turner <[email-masked]>
Date: Wed, 2 Jul 2014 23:48:41 -0400

> First, I (and I’m sure many others) have had to implement this format. There is a lot of software out there that uses these formats, and many others need to prepare input for such software. The for…

I’ve done the same thing and favor progressing this document for the same reason.

spt

---

From: Sean Leonard <[email-masked]>
Date: Wed, 02 Jul 2014 23:01:32 -0700

Thanks for the positive comments (both Yoav and Sean T). My responses to 
the things raised are below.

> - First line of the abstract: s/discuss/discusses/
ACK
> - Too many spaces between “M.” and “Rose” in the introduction.
I am not seeing this. I only see one space between, as in: "M. Rose". 
Are you looking at version 04?
> - Regarding the label in the -----BEGIN and -----END lines, section 2 says "The label type implies that the encoded data follows the specified syntax. Parsers MUST handle non-conforming data gracef…
First of all I have reason to believe that most applications are 
case-insensitive...but I need to double check that. As this doc is more 
descriptive than prescriptive, we will circle back after running some 
tests on application software out there.

I suppose that "gracefully" means don't crash and provide the most 
user-helpful feedback--if any. Here are three scenarios:

1. A user imports a certificate into the application, either via 
copy-and-paste (e.g., copy-and-paste into a web form) or opening a file. 
Even if the label is "CRL", /in context/ the application is expecting a 
certificate, so reasonable behavior would be to attempt to parse the 
contents as a certificate. If it is in fact a certificate, the label is 
irrelevant, because the application is taking data in (i.e., the file is 
not being written to), and the user accomplished the goal of getting the 
certificate in.

2. An application is run from a command-line or script to do something 
useful with PKIX data. For example, you have:
   somecmd -i blob-of-bytes.txt --text
In such a case, "somecmd" does not really know what blob-of-bytes.txt 
contains. Therefore when parsing the data, a reasonable guess is that if 
it starts with -----BEGIN CERTIFICATE-----, it should set the ASN.1 
decoder to expect the Certificate SEQUENCE PDU. If the decoder errors 
out, it would be reasonable for the command to error out. One could 
imagine that if the command started iterating through all of the 
possible PKIX ASN.1 PDUs (in what order? kind of arbitrary), the input 
(which may well be malicious) could trigger some kind of buffer overflow 
or untested program state.

3. Similar to 2., an application is run to do something useful, but the 
format is specified. Example:
   tellmecms -i blob-of-bytes.txt --text
In this case, tellmecms is going to take in a CMS object (and for 
backwards compatibility, maybe PKCS #7 data as well). So it is expecting 
-----BEGIN CMS-----, and will tolerate -----BEGIN PKCS7-----. If it sees 
an incorrect label like CRL, it would be reasonable to issue a warning 
to stdout or stderr, but to continue decoding the base64 in case the 
contents really are some CMS thing.

So I guess that's what we meant when the document says "gracefully". One 
can spin out many different cases and come up with reasonable operating 
behaviors. I am open to suggestions on what the document says, but would 
like to avoid a litany of examples.

> - Section 4.3: I’ve also seen .pem used for these files.
Yeah...I don't like the .pem extension (even though the perennial 
favorite OpenSSL has been using it for years). One reason why I don't 
like it is because .pem is used by OpenSSL for just about 
everything...but in fact the actual text output is only tangentially 
related to the original PEM specs. So if we say "some applications use 
.pem for certificates", we may as well repeat that ad nauseam for every 
structure in the document. My personal view is that they should be 
output to and input from .txt files, since they are text.

Sean

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Jul 2014 09:28:35 +0300

Thanks, Sean.

I’ve checked again, both the txt and html-ized version of the draft, and it shows two spaces as in “based on a proposal by M.  Rose”.

Yoav

On Jul 3, 2014, at 9:01 AM, Sean Leonard <[email-masked]> wrote:

> Thanks for the positive comments (both Yoav and Sean T). My responses to the things raised are below.
> 
> I am not seeing this. I only see one space between, as in: "M. Rose". Are you looking at version 04?
>> 
>> Other comments:
> First of all I have reason to believe that most applications are case-insensitive...but I need to double check that. As this doc is more descriptive than prescriptive, we will circle back after running some tests on application software out there.
> 
> I suppose that "gracefully" means don't crash and provide the most user-helpful feedback--if any. Here are three scenarios:
> 
> 1. A user imports a certificate into the application, either via copy-and-paste (e.g., copy-and-paste into a web form) or opening a file. Even if the label is "CRL", /in context/ the application is expecting a certificate, so reasonable behavior would be to attempt to parse the contents as a certificate. If it is in fact a certificate, the label is irrelevant, because the application is taking data in (i.e., the file is not being written to), and the user accomplished the goal of getting the certificate in.
> 
> 2. An application is run from a command-line or script to do something useful with PKIX data. For example, you have:
> In such a case, "somecmd" does not really know what blob-of-bytes.txt contains. Therefore when parsing the data, a reasonable guess is that if it starts with -----BEGIN CERTIFICATE-----, it should set the ASN.1 decoder to expect the Certificate SEQUENCE PDU. If the decoder errors out, it would be reasonable for the command to error out. One could imagine that if the command started iterating through all of the possible PKIX ASN.1 PDUs (in what order? kind of arbitrary), the input (which may well be malicious) could trigger some kind of buffer overflow or untested program state.
> 
> 3. Similar to 2., an application is run to do something useful, but the format is specified. Example:
> In this case, tellmecms is going to take in a CMS object (and for backwards compatibility, maybe PKCS #7 data as well). So it is expecting -----BEGIN CMS-----, and will tolerate -----BEGIN PKCS7-----. If it sees an incorrect label like CRL, it would be reasonable to issue a warning to stdout or stderr, but to continue decoding the base64 in case the contents really are some CMS thing.
> 
> So I guess that's what we meant when the document says "gracefully". One can spin out many different cases and come up with reasonable operating behaviors. I am open to suggestions on what the document says, but would like to avoid a litany of examples.
> 
> Yeah...I don't like the .pem extension (even though the perennial favorite OpenSSL has been using it for years). One reason why I don't like it is because .pem is used by OpenSSL for just about everything...but in fact the actual text output is only tangentially related to the original PEM specs. So if we say "some applications use .pem for certificates", we may as well repeat that ad nauseam for every structure in the document. My personal view is that they should be output to and input from .txt files, since they are text.
> 
> Sean
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix