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

[Paul Hoffman <[e-mail]>]

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