On Tue, 2016-11-22 at 14:32 +0100, Richard Levitte wrote: > In message <1479820334.8937.31.ca...@infradead.org> on Tue, 22 Nov 2016 > 13:12:14 +0000, David Woodhouse <dw...@infradead.org> said: > > dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote: > dwmw2> > > dwmw2> > Not sure I follow... 'file=/foo/bar/key.pem' is just a path / > dwmw2> > parameter that the 'tpmkey' handler is free to interpret in whatever > dwmw2> > way it sees fit. For me as a user, it's just a string. For all I > dwmw2> > care, the URI could just as well be > 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ==' > dwmw2> > That doesn't say anything about the contents of /foo/bar/key.pem, not > dwmw2> > more than file:/foo/bar/key.pem does, or even if there actually is a > dwmw2> > file /foo/bar/key.pem. Maybe I misunderstand what you're after... > dwmw2> > dwmw2> Where files are involved, I do not want the application to be told: > dwmw2> pkcs8:/foo/bar/key > dwmw2> pkcs1:/foo/bar/key > dwmw2> pkcs12:/foo/bar/key or > dwmw2> tpmkey:/foo/bar/key > dwmw2> > dwmw2> I only want the application to be told "/foo/bar/key" > > Ah, yeah, ok, so basically have OpenSSL support the "TSS KEY BLOB" PEM > type would be a way to go, wouldn't you say? That, or add functionality > to have PEM content handlers added dynamically, one for each PEM > content type. > Just please, that "pass the BIO" hack... sorry, I'm not a supporter.
I think the number of "new" PEM formats is going to be vanishingly small, and it's OK to have knowledge of them hard-coded in OpenSSL rather than having a fully dynamic mechanism. Doing it dynamically would be painful — either the appropriate engine needs to be loaded already, or we need a mapping from PEM 'BEGIN' string to the engine name somehow. > dwmw2> It should work out what the contents are for *itself*. Whether they be > dwmw2> PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else. > > Yeah, got it... my thinking was on a tachnical level, that > 'whatever.pem' would have to be handled by OpenSSL itself (or in URI > terms, by the 'file' scheme handler), while 'tpmkey:file=whatever.pem' > would be handled by the 'tpmkey' scheme handler, which is a different > story to me. Yes, they end up being routed to the same engine via entirely different paths. Both need resolving, and we need not to conflate the two. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
