On Wed, 2016-11-23 at 13:13 +0000, Salz, Rich wrote: > > But, what I get from you is "what if a octet stream matches two different > > ASN.1 types? Is that it? > > Yes among others. How do you know it will *never* happen?
Because if anyone tries to invent yet *another* ASN.1 form for storing keys, I am going to personally visit them in the small hours and stick a bat up their nightshirt? Hopefully we don't need to add completely new ones; we can use the existing PKCS#8 and PKCS#12 containers for new things. But even if a new form is invented which is ambiguous with existing forms, that's OK too. We don't support 'detection' of that new format by its ASN.1 structure. It'll be PEM-only like the TSS blobs are unless the type is explicitly specified. There is potential for confusion if the new object type doesn't just have the same ASN.1 structure as the old object, but objects of the new type can be completely valid objects of the old type too, and can be loaded as such. But that would have been a problem *anyway*. There's nothing new here. If I make a new object type which looks like a PKCS#1 RSA key but is actually something completely different, it's *already* likely that OpenSSL will load that new object as if it was an RSA key in some cases. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
