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

[Martin Rex <[e-mail]>]

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