Subject: Re: [pkix] Text Encodings of PKIX and CMS Structures (-01)

From: [email-masked] (Martin Rex)
Date: Thu, 2 Aug 2012 02:26:41 +0200 (CEST)

Comments based on the PKIX @ IETF-84 presentation.

I typically refer to the textual format as
"PEM-framed, base64-encoded Format", because of the PEM boundary markers.

The code I have written myself will choke on any Mime-Headers inserted
after the -----BEGIN boundary marker -- except for the support of the
OpenSSL PKCS5 encrypted private key, where these headers are AFAIK necessary
for processing/decoding the content.

A while ago I did add support for conveying CRLs out-of-band (file-based),
but realized that for really making an offline CRL check feasible,
it would be reasonable to convey a "bag-of-CRLs" packaged in a single
file, rather than individual CRLs, and chose PKCS#7 SIGNED_DATA with
no data as the container.  Individual, plain CRLs are also supported
an treated as a bag-of-CRL containing exactly one CRL.

-Martin

Sean Leonard wrote:
> Greetings PKIX:
> 
> Simon Josefsson and I have been working on the -01 revision to 
> "pkix-textual", currently titled:
> Text Encodings of PKIX and CMS Structures
> 
> We would like to propose this for adoption as a WG item.
> 
> In comparison to the original -00 draft, this revision has several 
> changes, including:
> - more history
> - discussion of interoperability
> - inclusion of CMS and PKCS #8/Asymmetric Key types
> - ABNF
> - addresses certain points made off-list
> 
> Some may have some questions, like "why 'X509 CRL' and not 'CRL'" and so 
> forth. Hopefully the draft addresses those, but I am also working on a 
> compatibility matrix that records what a lot of common implementations 
> actually emit or accept (the tests have been done, but need to be put 
> into a digestible spreadsheet). Most statements in the draft are based 
> on interoperability tests and experience, for maximum compatibility.