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

["Miller, Timothy J." <[e-mail]>]

> 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

On 1/27/12 6:37 PM, "Martin Rex" <[e-mail]> wrote:

>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
>_______________________________________________
>pkix mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix