On Wed, 2016-11-23 at 14:26 +0100, Richard Levitte wrote: > > Quite frankly, that's a though that should go back to David and his > demand of automatic detection. If anyone would *ever* create a raw > DER file holding a tss OCTET STRING, then the file spec *will* have to > have an indication of what type of content it is. > If we're thinking in URI terms, I could think of a contraption like > file:whatever.pem?t=tsskeyblob ... or dare I say it, > tpmkey:file=whatever.pem (David is so going to hate me ;-) ...)
Nah, that's fine. I mean, I hated you already, but I don't hate you any *more* for that observation. I don't care about supporting every bizarre esoteric format under the sun. All I'm after is consistency between applications for the *common* and *reasonable* file formats. Right now, if I have a PKCS#12 file with my identity certificate, I can use that with a *subset* of the applications installed in my system. If I have a PKCS#8 file, I can use that with a *different* subset of the applications. A different subset according to whether it's PEM or DER. If it's on a PKCS#11 token, I can use that with a *different* subset. And many applications can be configured to build with a choice of crypto libraries, so the formats they support will be *different* from one distribution to another. It's that mess that I'm trying to fix, but only for the key formats which are common enough that users have a reasonable expectation that they'll work. If some nutter starts writing the TPM_KEY12 OCTET STREAM to a DER file without even using the TssBlob structure from the TSS spec, I am not going to lose any sleep over that. And note that I am actively soliciting input on *what* forms should be expected to "Just Work" and which are less important. Perhaps there's a case to be made for ditching DER entirely and expecting people to use PEM? Or at least expect DER to work only for PKCS#12, PKCS#8 and PKCS#1? I'd certainly be OK with never adding any *new* DER forms to the list of "shall be expected to work", and requiring PEM instead for anything new. With the caveat that I *am* being led by what's actually out there in the wild, being issued to users through their corporate and other PKI infrastructure. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev