Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 13:48 +0100, Richard Levitte wrote:
> Mm...  I'm not sure I agree with the method, passing a BIO for the
> key_id.  I would much rather have seen a patch where OpenSSL's PEM
> module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
> from it, securing it somehow (since key_id is expected to be be NUL
> terminated) and pass that to the engine.

Agreed.

> My vote goes to a URI based spec rather than bastardising PEM files.
> I understand this kinda throws years of developmemt out the window,
> but there you have it.

I think we need both. We need the URI for the keys stored *in* the TPM
where we just need to reference them. And we need (non-bastardised) PEM
files with TPM-wrapped key blobs. The latter is what the engine
supports right now (by filename only).


-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016 
11:57:42 +, David Woodhouse  said:

dwmw2> On Mon, 2016-11-21 at 13:50 +, Blumenthal, Uri - 0553 - MITLL
dwmw2> wrote:
dwmw2> > Frankly, I think this approach of specially-encoded PEM or DER files
dwmw2> > telling the app what key to ask from the engine is madness, compared
dwmw2> > to the straightforward URI approach (no pun intended :).
dwmw2> 
dwmw2> Right. There are two separate things that the TPM can do for keys.
dwmw2> 
dwmw2> There is storage in the TPM itself, and you can reference a key therein
dwmw2> by its UUID. In Nikos's draft, and in GnuTLS, you end up with something
dwmw2> like tpmkey:uuid=7f468c16-cb7f-11e1-824d-b3a4f4b20343;storage=user
dwmw2> 
dwmw2> To use a PEM file for that does seem like madness; I agree.
dwmw2> 
dwmw2> However, Nikos's draft also supports a URI of the form:
dwmw2>  tpmkey:file=/foo/bar/key.pem
dwmw2> 
dwmw2> This, I do not like. It runs entirely contrary to my assertion in
dwmw2> http://david.woodhou.se/draft-woodhouse-cert-best-practice.html that
dwmw2> applications should Just Bloody Work with whatever file they're handed,
dwmw2> without needing to be *told* what the file contains.

Not sure I follow...  'file=/foo/bar/key.pem' is just a path /
parameter that the 'tpmkey' handler is free to interpret in whatever
way it sees fit.  For me as a user, it's just a string.  For all I
care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
That doesn't say anything about the contents of /foo/bar/key.pem, not
more than file:/foo/bar/key.pem does, or even if there actually is a
file /foo/bar/key.pem.  Maybe I misunderstand what you're after...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
> 
> Just let me shamelessly mention my STORE effort again ;-)
> Among others, it does attempt to solve that very problem (in the
> 'file' scheme handler).

Neat. Note that I have a ready-made test suite for you in OpenConnect:
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am

For every one of the key files therein, does your current
implementation work? :)

(Yeah, I need to sort out the tpm emulator in the test environment,
then add some -BEGIN TSS KEY BLOB- files too :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479744347.2309.21.ca...@hansenpartnership.com> on Mon, 21 Nov 2016 
08:05:47 -0800, James Bottomley  said:

James.Bottomley> On Mon, 2016-11-21 at 13:42 +, David Woodhouse wrote:
James.Bottomley> > On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
James.Bottomley> > > 
James.Bottomley> > > Many years ago, I was thinking of something along the same 
lines, 
James.Bottomley> > > but with a .pem file that would just have a few headers, 
holding 
James.Bottomley> > > the name of the intended engine and the key identity, 
something
James.Bottomley> > > like this:
James.Bottomley> > > 
James.Bottomley> > > -BEGIN PRIVATE KEY-
James.Bottomley> > > X-key-id: flarflarflar
James.Bottomley> > > X-key-engine: foo
James.Bottomley> > > -END PRIVATE KEY-
James.Bottomley> > > 
James.Bottomley> > > The intent was that the PEM code would be massaged to 
recognise 
James.Bottomley> > > these headers and would then use ENGINE_by_id() /
James.Bottomley> > > ENGINE_load_private_key() with those data and that would 
be it.
James.Bottomley> > > 
James.Bottomley> > > James, did I catch your intention about right?  I think 
that's
James.Bottomley> > > essentially what e_tpm.c does for loading keys, right?
James.Bottomley> 
James.Bottomley> Yes, that's right.  When any SSL program sees a TPM wrapped 
key, it
James.Bottomley> should just do the right thing if it has the engine capability 
without
James.Bottomley> needing the user to add any options to the command line.

Mm...  I'm not sure I agree with the method, passing a BIO for the
key_id.  I would much rather have seen a patch where OpenSSL's PEM
module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
from it, securing it somehow (since key_id is expected to be be NUL
terminated) and pass that to the engine.

James.Bottomley> > Once the dust settles on TPMv2.0 we should probably put 
together an I
James.Bottomley> > -D for the TPM-wrapped blob PEM files. And I should 
definitely add
James.Bottomley> > something about them to ¹.
James.Bottomley> 
James.Bottomley> Once we agree, I'll be happy to write up something.  We can 
use the pem
James.Bottomley> header concept to extend this format if it becomes necessary.

My vote goes to a URI based spec rather than bastardising PEM files.
I understand this kinda throws years of developmemt out the window,
but there you have it.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Salz, Rich]

> would much rather have seen a patch where OpenSSL's PEM module is
> tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing

Yes, that would be much more consistent with the existing OpenSSL code which -- 
like it or not -- works that way.

> My vote goes to a URI based spec rather than bastardising PEM files.

Sure, if you can figure out which URI scheme to use; there are many of them. :)

/r$

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 12:54 +, Salz, Rich wrote:
> > would much rather have seen a patch where OpenSSL's PEM module is
> > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, 
> > securing
> 
> Yes, that would be much more consistent with the existing OpenSSL
> code which -- like it or not -- works that way.

Yeah. Although I'd note that the OpenSSL code only works that way for
PEM files. I really want to make it work the same way for DER files
too. There's an *attempt* in d2i_AutoPrivateKey() but that doesn't
handle encrypted PKCS#8 IIRC. Or PKCS#12. And the app still shouldn't
have to call different functions for PEM vs. DER files anyway.

> > My vote goes to a URI based spec rather than bastardising PEM files.
> 
> Sure, if you can figure out which URI scheme to use; there are many
> of them. :)

For TPM I am not aware of any scheme other than the one set out in
https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
> 
> Not sure I follow...  'file=/foo/bar/key.pem' is just a path /
> parameter that the 'tpmkey' handler is free to interpret in whatever
> way it sees fit.  For me as a user, it's just a string.  For all I
> care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
> That doesn't say anything about the contents of /foo/bar/key.pem, not
> more than file:/foo/bar/key.pem does, or even if there actually is a
> file /foo/bar/key.pem.  Maybe I misunderstand what you're after...

Where files are involved, I do not want the application to be told:
 pkcs8:/foo/bar/key
 pkcs1:/foo/bar/key
 pkcs12:/foo/bar/key or
 tpmkey:/foo/bar/key

I only want the application to be told "/foo/bar/key"

It should work out what the contents are for *itself*. Whether they be
PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.

And if the string it's given *isn't* a filename but is instead a
PKCS#11 URI or a TPM URI according to Nikos's spec, that should Just
Work too.

User pass string identifying key. Application Just Work™. dwmw2 happy.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479820158.8937.29.ca...@infradead.org> on Tue, 22 Nov 2016 
13:09:18 +, David Woodhouse  said:

dwmw2> On Tue, 2016-11-22 at 12:54 +, Salz, Rich wrote:
dwmw2> > > would much rather have seen a patch where OpenSSL's PEM module is
dwmw2> > > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, 
securing
dwmw2> > 
dwmw2> > Yes, that would be much more consistent with the existing OpenSSL
dwmw2> > code which -- like it or not -- works that way.
dwmw2> 
dwmw2> Yeah. Although I'd note that the OpenSSL code only works that way for
dwmw2> PEM files. I really want to make it work the same way for DER files
dwmw2> too. There's an *attempt* in d2i_AutoPrivateKey() but that doesn't
dwmw2> handle encrypted PKCS#8 IIRC. Or PKCS#12. And the app still shouldn't
dwmw2> have to call different functions for PEM vs. DER files anyway.

Just let me shamelessly mention my STORE effort again ;-)
Among others, it does attempt to solve that very problem (in the
'file' scheme handler).

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479820334.8937.31.ca...@infradead.org> on Tue, 22 Nov 2016 
13:12:14 +, David Woodhouse  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.

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.

I dunno about you, but to me, the URI scheme is not the same as an
indication of what contents I'll get.  But i guess that's a matter of
interpretation.

dwmw2> And if the string it's given *isn't* a filename but is instead a
dwmw2> PKCS#11 URI or a TPM URI according to Nikos's spec, that should Just
dwmw2> Work too.

You *do* indicate those with a URI scheme, though ;-)

dwmw2> User pass string identifying key. Application Just Work™. dwmw2 happy.

:-)

Cheers,
Richard ( who'd be *much* happier if his fingers didn't constantly
  want to typ tmpkey ;-) )

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

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 +, David Woodhouse  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

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote:
> > That's not the proposal.  The proposal is to use PEM form because we can
> > make it uniquely self describing using the guard tags which obviates the
> > problem above.
> 
> Well that's what you want.  David wants more than that :)

S'true :)

> > On the larger issue of non-self describing formats like ASN.1: if your 
> > theory
> > that there's a security hole by allowing opportunistic format detection is
> > correct, simply making the user specify is palming our bug off on to the 
> > user
> > and abdicating responsibility because now when they're tricked into an
> > exploit they can be blamed not openssl.  If such a bug exists, doing
> > opportunistic format detection the better guarantor of overall system
> > security because if such a bug is found, it would have to be fixed within
> > openssl to everyone's benefit.
> 
> We differ.

We do. I think James put it well though, when he talked of "palming our
bug off onto the user and abdicating responsibility". The library
doesn't get to sit in its ivory tower of perfection; you are
responsible for the API you inflict on users and how they actually
*use* it.

And besides, even if we force applications to iterate over the possible
formats for themselves, they aren't going to have a bug *there*. Any
bug will be in our parser for one specific format or another. We didn't
even *save* our reputation by forcing the application authors to jump
through hoops.

And more to the point, you already *do* this, in d2i_AutoPrivateKey().
It's just that you only handle *some* of the known key formats, so the
application has to explicitly try the others. What's being proposed
here is merely that we fix that up to have full coverage — not a
radical new approach at all.

Oh, and that we automatically distinguish between PEM and DER forms,
but *that* much is fairly trivial and safe.

And the locale / character set issue is not relevant here. ASN.1 is
binary, PEM is ASCII.

When we come to talk about passwords, *sure* we can look at character
sets. But that is a somewhat orthogonal issue.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Thomas Francis, Jr.]

On 11/22/16 2:37 PM, David Woodhouse wrote:

On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote:





And the locale / character set issue is not relevant here. ASN.1 is
binary, PEM is ASCII.


PEM should be ASCII; in practice it is not necessarily ASCII.  There are 
several products that produce "PEM files" in various EBCDIC character 
sets.  Other products produce them in ASCII, but then  transfer them 
with an EBCDIC to ASCII conversion.  And in still others, it's the 
customer who transfers it manually, converting from EBCDIC to ASCII when 
the file was ASCII.  These latter two are less common in my limited 
experience, which is fortunate, because recovering from that is very 
difficult.


I've also seen some windows products that will produce "unicode" pem 
files, which may or may not have a BOM at the beginning, and other 
products which produce the files with the UTF-8 BOM at the beginning, too.


While it's easy for me to say these files are malformed, the customer 
doesn't care.  They have the file; they expect it to work.


In most of those cases, the user will open the file, and see exactly 
what they expect, a PEM header, followed by what looks like base64 
encoded data, and a matching footer.  It's very difficult to convince a 
customer the file is incorrect in the face of that.  Even if you get 
them to acknowledge the file isn't in the expected format, again they 
don't care.  They have the file, usually from some very expensive 
software or process, your much less important software had better use it 
(yup, I've had those conversations with customers, fortunately with tech 
support filtering my side of the conversation :) ).


In any event, I don't think it's OpenSSL's job to detect and fix these 
kinds of issues.  Although probably 90% of them could be fixed with a 
simple EBCDIC->ASCII converter, ignoring BOMs and recognizing the 
Windows "unicode" format. :)


TOM
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message 
 on Tue, 
22 Nov 2016 14:42:35 +, "Salz, Rich"  said:

rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether
rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
rsalz> 
rsalz> I disagree with this approach, but that's just my opinion.  I am worried 
about "keep trying something until it works" because you'll get strange errors 
you can't decode, 'only allow N tries' devices will lock you out, and the order 
in which you try things could result in needless long delays.
rsalz> 
rsalz> But don't let that stop you.

I *think* the guessing part is just about the step of loading the file
content and transparently understanding what type of content it is.
That's basically looking at a bunch of bytes and recognising it for
what it is.  When that's done, the trial and error phase is over, and
for stuff that libcrypto has support for, libcrypto will be able to
act, deterministically.

>From the application point of view, this would be just one call, but
we are talking OpenSSL internals now, aren't we?

David, correct me if I got you wrong.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479823032.8937.37.ca...@infradead.org> on Tue, 22 Nov 2016 
13:57:12 +, David Woodhouse  said:

dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Just let me shamelessly mention my STORE effort again ;-)
dwmw2> > Among others, it does attempt to solve that very problem (in the
dwmw2> > 'file' scheme handler).
dwmw2> 
dwmw2> Neat. Note that I have a ready-made test suite for you in OpenConnect:
dwmw2> 
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am
dwmw2> 
dwmw2> For every one of the key files therein, does your current
dwmw2> implementation work? :)
dwmw2> 
dwmw2> (Yeah, I need to sort out the tpm emulator in the test environment,
dwmw2> then add some -BEGIN TSS KEY BLOB- files too :)

All I can see is PEM files...  For any PEM content that OpenSSL
supports, the STORE 'file' scheme loader does as well.  That's just a
one liner, quite precisely this one:

https://github.com/openssl/openssl/pull/1962/files#diff-34958ca30387ac75fa5011f98c18b3baR69

The more interesting part is when it tries to load files it guesses
are raw DER.  It's currently only trying a few chosen content types,
I'm happy to add more as time goes.  However, I suspect that nothing
in your test suite will trigger that part.

TSS KEY BLOBs is a different thing.  That needs added PEM support, and
the STORE 'file' scheme loader will not have to be changed at all.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016 
11:57:42 +, David Woodhouse  said:

dwmw2> Besides, it requires files in the form described by the Portable Data
dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
dwmw2> (which is mostly redundant as in this case we're always talking about
dwmw2> key blobs), the blob length (which is entirely redundant) and then the
dwmw2> actual blob as an OCTET STRING. I don't know of any tool which actually
dwmw2> creates such files.

I'm just having a look at the spec (page 151 in
http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf),
and am a bit confused by the TssBlobType type.  Which is it in
practice, an ENUMERATED or an INTEGER?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Salz, Rich]

> dwmw2> It should work out what the contents are for *itself*. Whether
> dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.

I disagree with this approach, but that's just my opinion.  I am worried about 
"keep trying something until it works" because you'll get strange errors you 
can't decode, 'only allow N tries' devices will lock you out, and the order in 
which you try things could result in needless long delays.

But don't let that stop you.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 16:07 +0100, Richard Levitte wrote:
> In message 
>  on 
> Tue, 22 Nov 2016 14:42:35 +, "Salz, Rich"  said:
> 
> rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether
> rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
> rsalz> 
> rsalz> I disagree with this approach, but that's just my opinion.  I am 
> worried about "keep trying something until it works" because you'll get 
> strange errors you can't decode, 'only allow N tries' devices will lock you 
> out, and the order in which you try things could result in needless long 
> delays.
> rsalz> 
> rsalz> But don't let that stop you.
> 
> I *think* the guessing part is just about the step of loading the file
> content and transparently understanding what type of content it is.
> That's basically looking at a bunch of bytes and recognising it for
> what it is.  When that's done, the trial and error phase is over, and
> for stuff that libcrypto has support for, libcrypto will be able to
> act, deterministically.
> 
> From the application point of view, this would be just one call, but
> we are talking OpenSSL internals now, aren't we?
> 
> David, correct me if I got you wrong.

You have it entirely correct. Rich has a valid concern for the general
case, but it doesn't apply *here* because we're just talking about
interpreting files. No hardware token is going to get upset and lock
you out, just because you actually look inside the file and work out
what type it is, then treat it as that — instead of forcing the
*application* to look inside the file first, then invoke the crypto
library differently for each type of file (or URI), as shown at 
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c#l827

Basically, for every line in that load_certificate() function and the
subfunctions it calls, I hate you :)

When it comes to talking to real hardware, Rich is absolutely right.
You don't just keep trying there. So if you look at the 'Locating
objects in PKCS#11' section of my best practice draft¹ you'll see that
you're only supposed to log into a given token if you *know* that's the
one you need — either because you're looking for a key and you've
already found the corresponding certificate in that token without
having to log in, or because the PKCS#11 URI actually *specified* the
token unambiguously. But that's a separate issue.

-- 
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.8

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 07:44 -0800, James Bottomley wrote:
> 
> > I'm just having a look at the spec (page 151 in
> > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat
> > a_A-final.pdf), and am a bit confused by the TssBlobType type.  Which 
> > is it in practice, an ENUMERATED or an INTEGER?
> 
> It's actually here:
> 
> http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
> 
> It's around page 101, section 10.3 the TPM_KEY12 structure.  That tells
> you what to encrypt and how to construct the encrypted part of the
> blob.  It refers to other structures, so you end up doing a bit of a
> pointer chase through the document.

The TPM_KEY12 structure is what's in the OCTET STRING (that I just
showed). But I believe we're looking at the ASN.1 on page 151 (§3.23
"Portable Data") of the TSS spec:

TssBlobType ::= ENUMERATED
{
Key-Blob (1),-- TCPA_KEY as returned from TPM
PubKey-Blob (2), -- TCPA_PUBKEY as returned from TPM
MigKey-Blob (3), -- TCPA_KEY as return from the TSP 
Tspi_Key_CreateMigrationBlob
In dedicated mode (see the command for details)
SealedData-Blob (4),   -- TCPA_STORED_DATA as returned from TPM
...
}

TssBlobType ::= INTEGER
TssBlob ::= SEQUENCE
{
StructVersion INTEGER, -- Version of this structure; at the moment 1
BlobType TssBlobType,  -- Type of Blob; see enum
BlobLength INTEGER,-- Length of Blob
Blob OCTET STRING  -- Blob as returned from TPM (no ASN1 encoding)
}

To my knowledge nothing actually *implements* this TssBlob. Those PEM
files (like the one I just showed) only contain the OCTET STRING.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
> 
> dwmw2> It is *only* the OCTET STRING of the blob itself. Everything else is
> dwmw2> redundant anyway.
> 
> Oh!  Ok, that makes things much simpler (at least in a way)

Kind of. But then again, there's an argument that it was none of your
business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to the
TPM engine and after that you really don't care about what's in it.

Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary
files (no ASN.1 at all). For some reason it didn't use the TssBlob
object type, although perhaps it should.

When I started looking at it, I used the -BEGIN TSS KEY BLOB-
for an OCTET STRING containing *just* that the code had previously been
writing into its binary files.

If I'd been aware of the TssBlob definition at that time, I suppose I
would have used it instead of just the OCTET STRING. But I didn't.

If we write an I-D covering the TPM keys, perhaps the PEM contents
should be permitted to be *either* a raw OCTET STRING with the key
blob, OR a TssBlob object. Or maybe we should add a
BEGIN TSS BLOB- (without 'KEY' in it) instead?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[James Bottomley]

On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
> In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov
> 2016 11:57:42 +, David Woodhouse  said:
> 
> dwmw2> Besides, it requires files in the form described by the
> Portable Data
> dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob
> type
> dwmw2> (which is mostly redundant as in this case we're always
> talking about
> dwmw2> key blobs), the blob length (which is entirely redundant) and
> then the
> dwmw2> actual blob as an OCTET STRING. I don't know of any tool which
> actually
> dwmw2> creates such files.
> 
> I'm just having a look at the spec (page 151 in
> http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat
> a_A-final.pdf), and am a bit confused by the TssBlobType type.  Which 
> is it in practice, an ENUMERATED or an INTEGER?

It's actually here:

http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf

It's around page 101, section 10.3 the TPM_KEY12 structure.  That tells
you what to encrypt and how to construct the encrypted part of the
blob.  It refers to other structures, so you end up doing a bit of a
pointer chase through the document.

James


-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
> In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016 
> 11:57:42 +, David Woodhouse  said:
> 
> dwmw2> Besides, it requires files in the form described by the Portable Data
> dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
> dwmw2> (which is mostly redundant as in this case we're always talking about
> dwmw2> key blobs), the blob length (which is entirely redundant) and then the
> dwmw2> actual blob as an OCTET STRING. I don't know of any tool which actually
> dwmw2> creates such files.
> 
> I'm just having a look at the spec (page 151 in
> http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf),
> and am a bit confused by the TssBlobType type.  Which is it in
> practice, an ENUMERATED or an INTEGER?

In practice, it doesn't get used at all. The object encoded with
-BEGIN TSS KEY BLOB- and used by both the OpenSSL TPM ENGINE
and by GnuTLS is not the TssBlob object that you're looking at.

It is *only* the OCTET STRING of the blob itself. Everything else is
redundant anyway.

$ openssl asn1parse -i -in tpmkey.pem -inform pem
0:d=0  hl=4 l= 559 prim: OCTET STRING  [HEX
DUMP]:0101001500060100020003000C0802000
00100D6791E892D6B93830F026C6C66B365A0B61B3CBB5B36EA1A13
C67111D49711719E665B5EBAAB5F9CB04D7CC87C78DE56700CD6A8F9B94C92DF029983F
2DA8883841090CEAACD53453516843FEF6689AC5E7D8102B85141B86B2F0E8C99124A70
90C5FB35A902D672E56D2BC2654317DCF578692B8CC441E08E3CCEF8CE86219822250CA
3A23A70EF69B3A092B3DFA70F049B712B885B8EA576C9F3F4E54107DB8F8D678CCF376D
9299BB47013318999FA8099180815D99F90646588508AACF7527E7A6D38C6C53B78C9BA
6F693069F2906B82E5500D5209489E48C29A4B487564AC64CED3FC61D88EF0C27C0E5EE
5AFEB861E3B104F8FCABDBE07DBE4FE42D2B010091175251D67BE97DB4A4F48EF5D
515E9ED64287BF2DFCCCDD6E6791AADC7E6752F2A2DCD3CBC29AB8660947B78C1F15C30
26369AC4A6B5434996CDB3CA659A2A2F48BE26B7E3C5AEBD75A6B6BCB376650138DCAD0
00E46BD94139A9DD596355C0469463E0E7D68C9997724EC7CFACDDC8EFA3C81045F5076
284BA2CA0B935DCFC28793D1BC9E8D2F4F141788B92DA93D3B370C8A24AFF59DEAAC81F
5A96C2299CBA74AA651E0AF92122B4F7524D08027DA71EDB191B115722AEB7F97817346
4484778FF88BC56815420791D7F9FB1ADD781D979A85D69F31970F228A6A12C6FD4FC3C
AF7A9F8F933818D436C5552D7B60A1E48CDEC7E38FC452A359C6E1609EC

$ openconnect -c cert.pem -k tpmkey.pem auth.startssl.com -v
POST https://auth.startssl.com/
Attempting to connect to server 104.192.110.244:443
Connected to 104.192.110.244:443
Using certificate file cert.pem
Using private key file tpmkey.pem
TPM sign function called for 35 bytes.
Using client certificate '192.168.123.1'
TPM sign function called for 51 bytes.
SSL negotiation with auth.startssl.com
...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479829450.2376.10.ca...@hansenpartnership.com> on Tue, 22 Nov 2016 
07:44:10 -0800, James Bottomley  said:

James.Bottomley> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
James.Bottomley> > In message <1479815862.8937.22.ca...@infradead.org> on Tue, 
22 Nov
James.Bottomley> > 2016 11:57:42 +, David Woodhouse  
said:
James.Bottomley> > 
James.Bottomley> > dwmw2> Besides, it requires files in the form described by 
the
James.Bottomley> > Portable Data
James.Bottomley> > dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with 
a blob
James.Bottomley> > type
James.Bottomley> > dwmw2> (which is mostly redundant as in this case we're 
always
James.Bottomley> > talking about
James.Bottomley> > dwmw2> key blobs), the blob length (which is entirely 
redundant) and
James.Bottomley> > then the
James.Bottomley> > dwmw2> actual blob as an OCTET STRING. I don't know of any 
tool which
James.Bottomley> > actually
James.Bottomley> > dwmw2> creates such files.
James.Bottomley> > 
James.Bottomley> > I'm just having a look at the spec (page 151 in
James.Bottomley> > 
http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat
James.Bottomley> > a_A-final.pdf), and am a bit confused by the TssBlobType 
type.  Which 
James.Bottomley> > is it in practice, an ENUMERATED or an INTEGER?
James.Bottomley> 
James.Bottomley> It's actually here:
James.Bottomley> 
James.Bottomley> 
http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
James.Bottomley> 
James.Bottomley> It's around page 101, section 10.3 the TPM_KEY12 structure.  
That tells
James.Bottomley> you what to encrypt and how to construct the encrypted part of 
the
James.Bottomley> blob.  It refers to other structures, so you end up doing a 
bit of a
James.Bottomley> pointer chase through the document.

I'm sorry, I have obviously had you a bit confused.  What I'm
currently interested in is decoding the content of a 'TSS KEY BLOB'
PEM file, and I assume that's a TssBlob type, yeah?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 17:14 +0100, Richard Levitte wrote:
> 
> I'm sorry, I have obviously had you a bit confused.  What I'm
> currently interested in is decoding the content of a 'TSS KEY BLOB'
> PEM file, and I assume that's a TssBlob type, yeah?

No, it's not. (Sorry!)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479830167.8937.43.ca...@infradead.org> on Tue, 22 Nov 2016 
15:56:07 +, David Woodhouse  said:

dwmw2> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
dwmw2> > In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 
2016 11:57:42 +, David Woodhouse  said:
dwmw2> > 
dwmw2> > dwmw2> Besides, it requires files in the form described by the 
Portable Data
dwmw2> > dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob 
type
dwmw2> > dwmw2> (which is mostly redundant as in this case we're always talking 
about
dwmw2> > dwmw2> key blobs), the blob length (which is entirely redundant) and 
then the
dwmw2> > dwmw2> actual blob as an OCTET STRING. I don't know of any tool which 
actually
dwmw2> > dwmw2> creates such files.
dwmw2> > 
dwmw2> > I'm just having a look at the spec (page 151 in
dwmw2> > 
http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf),
dwmw2> > and am a bit confused by the TssBlobType type.  Which is it in
dwmw2> > practice, an ENUMERATED or an INTEGER?
dwmw2> 
dwmw2> In practice, it doesn't get used at all. The object encoded with
dwmw2> -BEGIN TSS KEY BLOB- and used by both the OpenSSL TPM ENGINE
dwmw2> and by GnuTLS is not the TssBlob object that you're looking at.
dwmw2> 
dwmw2> It is *only* the OCTET STRING of the blob itself. Everything else is
dwmw2> redundant anyway.

Oh!  Ok, that makes things much simpler (at least in a way)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[James Bottomley]

On Tue, 2016-11-22 at 16:28 +, David Woodhouse wrote:
> On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
> > 
> > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything
> > else is
> > dwmw2> redundant anyway.
> > 
> > Oh!  Ok, that makes things much simpler (at least in a way)
> 
> Kind of. But then again, there's an argument that it was none of your
> business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to
> the
> TPM engine and after that you really don't care about what's in it.
> 
> Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary
> files (no ASN.1 at all). For some reason it didn't use the TssBlob
> object type, although perhaps it should.
> 
> When I started looking at it, I used the -BEGIN TSS KEY BLOB-
> for an OCTET STRING containing *just* that the code had previously
> been
> writing into its binary files.
> 
> If I'd been aware of the TssBlob definition at that time, I suppose I
> would have used it instead of just the OCTET STRING. But I didn't.
> 
> If we write an I-D covering the TPM keys, perhaps the PEM contents
> should be permitted to be *either* a raw OCTET STRING with the key
> blob, OR a TssBlob object. Or maybe we should add a
> BEGIN TSS BLOB- (without 'KEY' in it) instead?

Before we rathole on this: if we use the current code to just hand off
to the engine, openssl never needs to know the format of the key files
or even what they mean.  If we hard code recognising TPM keys into
openssl, we are going to have to agree (and stick to) a key format. 
 This is one of the decisions that needs making to transform the RFC
into a real patch.

I will note that gnutls does hard code recognising TPM keys so there's
precedent for doing it that way.  However, I have a marginal preference
for letting the loaded engines do it because that's the way that gives
most flexibility with regard to new engines as they come along.  This
problem isn't theoretical: TPM 2.0 keys are very different from TPM 1.2
ones, so they'll likely have a new engine to handle them and a new file
format.

James


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 16:14 +0100, Richard Levitte wrote:
> The more interesting part is when it tries to load files it guesses
> are raw DER.  It's currently only trying a few chosen content types,
> I'm happy to add more as time goes.  However, I suspect that nothing
> in your test suite will trigger that part.

There's a selection of .der and .p12 files there too.

Adding non-ASCII passwords and running in different locales (and
stress-testing both the old and the new PKCS#12 BMPstring bugs) is
still on my TODO list.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message 
<489af892b16b43ee9a7009ffe52db...@usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 
22 Nov 2016 17:40:54 +, "Salz, Rich"  said:

rsalz> > The more interesting part is when it tries to load files it guesses 
are raw DER.
rsalz> 
rsalz> And this part worries me.  I do not think a "security library" should be 
guessing.

It does this by trying to interpret the blob against known ASN.1
definitions, and will only succeed when there's a complete match.  I'm
not terribly worried...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 18:46 +0100, Richard Levitte wrote:
> In message 
> <489af892b16b43ee9a7009ffe52db...@usma1ex-dag1mb1.msg.corp.akamai.com> on 
> Tue, 22 Nov 2016 17:40:54 +, "Salz, Rich"  said:
> 
> rsalz> > The more interesting part is when it tries to load files it guesses 
> are raw DER.
> rsalz> 
> rsalz> And this part worries me.  I do not think a "security library" should 
> be guessing.
> 
> It does this by trying to interpret the blob against known ASN.1
> definitions, and will only succeed when there's a complete match.  I'm
> not terribly worried...

And even if you were, you should be *more* worried about making
*applications* do it for themselves :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Salz, Rich]

> The more interesting part is when it tries to load files it guesses are raw 
> DER.

And this part worries me.  I do not think a "security library" should be 
guessing.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Salz, Rich]

> > It does this by trying to interpret the blob against known ASN.1
> > definitions, and will only succeed when there's a complete match.  I'm
> > not terribly worried...

I am.  With locales and UTF8, the old simple days of text/binary are probably 
long gone.  And if any ASN.1 definition has extensibility in it, then we have 
to be concerned about things being wrapped, something like prefix attacks, and 
so on.  
 
> And even if you were, you should be *more* worried about making
> *applications* do it for themselves :)

I cannot control what an application does, and I am not responsible for any 
other application's reputation.  I do have a strongly vested stake in 
OpenSSL's. 

It is already possible to write a utility library that tries everything in 
turn, and returns an enumeration that says "seems to be an X509 certificate" 
etc.  And then another routine that takes that enumeration and the blob and 
calls the right decoder.  I would be okay with that, even if it were part of 
OpenSSL.  I am opposed to guessing and parsing in one step, and would -1 any PR 
for that, forcing a team discussion.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479833048.2376.21.ca...@hansenpartnership.com> on Tue, 22 Nov 2016 
08:44:08 -0800, James Bottomley  said:

James.Bottomley> On Tue, 2016-11-22 at 16:28 +, David Woodhouse wrote:
James.Bottomley> > On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
James.Bottomley> > > 
James.Bottomley> > > dwmw2> It is *only* the OCTET STRING of the blob itself. 
Everything
James.Bottomley> > > else is
James.Bottomley> > > dwmw2> redundant anyway.
James.Bottomley> > > 
James.Bottomley> > > Oh!  Ok, that makes things much simpler (at least in a way)
James.Bottomley> > 
James.Bottomley> > Kind of. But then again, there's an argument that it was 
none of your
James.Bottomley> > business anyway. If it says "BEGIN TSS KEY BLOB" you hand it 
off to
James.Bottomley> > the
James.Bottomley> > TPM engine and after that you really don't care about what's 
in it.
James.Bottomley> > 
James.Bottomley> > Once upon a time, the TPM engine wrote those TPM_KEY blobs 
to binary
James.Bottomley> > files (no ASN.1 at all). For some reason it didn't use the 
TssBlob
James.Bottomley> > object type, although perhaps it should.
James.Bottomley> > 
James.Bottomley> > When I started looking at it, I used the -BEGIN TSS KEY 
BLOB-
James.Bottomley> > for an OCTET STRING containing *just* that the code had 
previously
James.Bottomley> > been
James.Bottomley> > writing into its binary files.
James.Bottomley> > 
James.Bottomley> > If I'd been aware of the TssBlob definition at that time, I 
suppose I
James.Bottomley> > would have used it instead of just the OCTET STRING. But I 
didn't.
James.Bottomley> > 
James.Bottomley> > If we write an I-D covering the TPM keys, perhaps the PEM 
contents
James.Bottomley> > should be permitted to be *either* a raw OCTET STRING with 
the key
James.Bottomley> > blob, OR a TssBlob object. Or maybe we should add a
James.Bottomley> > BEGIN TSS BLOB- (without 'KEY' in it) instead?
James.Bottomley> 
James.Bottomley> Before we rathole on this: if we use the current code to just 
hand off
James.Bottomley> to the engine, openssl never needs to know the format of the 
key files
James.Bottomley> or even what they mean.  If we hard code recognising TPM keys 
into
James.Bottomley> openssl, we are going to have to agree (and stick to) a key 
format. 
James.Bottomley>  This is one of the decisions that needs making to transform 
the RFC
James.Bottomley> into a real patch.
James.Bottomley> 
James.Bottomley> I will note that gnutls does hard code recognising TPM keys so 
there's
James.Bottomley> precedent for doing it that way.  However, I have a marginal 
preference
James.Bottomley> for letting the loaded engines do it because that's the way 
that gives
James.Bottomley> most flexibility with regard to new engines as they come 
along.  This
James.Bottomley> problem isn't theoretical: TPM 2.0 keys are very different 
from TPM 1.2
James.Bottomley> ones, so they'll likely have a new engine to handle them and a 
new file
James.Bottomley> format.

Actually, I agree with this, and that goes along with how our PEM
routines work (specifically, PEM_X509_INFO_read_bio()), it just
treats the data as an octet string and hands it down to a d2i routine
of choice, with a pointer to where to place the result.

It's not very hard to imagine adding the possibility for external
handlers for specific PEM content types, which could be handed an
octet string and a pointer to a X509_INFO (which is the structure used
to collect the data in), or something like that (I can also imagine
having one separate handler for each type of data that can be
returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL,
and so on and so forth).  That would make it possible for an engine to
declare its own handler during the binding call, along with all other
information it feeds back to libcrypto.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message 
<021a5d5b885845f5ab79c4420232e...@usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 
22 Nov 2016 18:03:31 +, "Salz, Rich"  said:

rsalz> It is already possible to write a utility library that tries
rsalz> everything in turn, and returns an enumeration that says "seems
rsalz> to be an X509 certificate" etc.  And then another routine that
rsalz> takes that enumeration and the blob and calls the right
rsalz> decoder.  I would be okay with that, even if it were part of
rsalz> OpenSSL.  I am opposed to guessing and parsing in one step, and
rsalz> would -1 any PR for that, forcing a team discussion.

Uh...  the d2i functions are already both in one.  Are you saying
they should be split in two, one part that does all the checking and
the other that just decodes, trusting that all checks are already
done?  What you're gonna do there is double part of the work.

But, what I get from you is "what if a octet stream matches two
different ASN.1 types?  Is that it?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Richard Levitte]

In message <1479839148.2376.31.ca...@hansenpartnership.com> on Tue, 22 Nov 2016 
10:25:48 -0800, James Bottomley  said:

James.Bottomley> On Tue, 2016-11-22 at 18:03 +, Salz, Rich wrote:
James.Bottomley> > > > It does this by trying to interpret the blob against 
known ASN.1
James.Bottomley> > > > definitions, and will only succeed when there's a 
complete match.
James.Bottomley> > > >   I'm
James.Bottomley> > > > not terribly worried...
James.Bottomley> > 
James.Bottomley> > I am.  With locales and UTF8, the old simple days of 
text/binary are
James.Bottomley> > probably long gone.  And if any ASN.1 definition has 
extensibility in
James.Bottomley> > it, then we have to be concerned about things being wrapped,
James.Bottomley> > something like prefix attacks, and so on.  
James.Bottomley> >  
James.Bottomley> > > And even if you were, you should be *more* worried about 
making
James.Bottomley> > > *applications* do it for themselves :)
James.Bottomley> > 
James.Bottomley> > I cannot control what an application does, and I am not 
responsible
James.Bottomley> > for any other application's reputation.  I do have a 
strongly vested
James.Bottomley> > stake in OpenSSL's. 
James.Bottomley> > 
James.Bottomley> > It is already possible to write a utility library that tries 
James.Bottomley> > everything in turn, and returns an enumeration that says 
"seems to be 
James.Bottomley> > an X509 certificate" etc.  And then another routine that 
takes that 
James.Bottomley> > enumeration and the blob and calls the right decoder.  I 
would be 
James.Bottomley> > okay with that, even if it were part of OpenSSL.  I am 
opposed to 
James.Bottomley> > guessing and parsing in one step, and would -1 any PR for 
that, 
James.Bottomley> > forcing a team discussion.
James.Bottomley> 
James.Bottomley> That's not the proposal.  The proposal is to use PEM form 
because we
James.Bottomley> can make it uniquely self describing using the guard tags which
James.Bottomley> obviates the problem above.

This is a side thread that discusses the 'file' scheme loader in my
STORE effort.  So, uhmmm, we're a bit away from just PEM here.
However, if we go back to the discussion about TSS KEY BLOBs, yeah,
I've only seen a PEM proposal, and that's a mch easier case.

James.Bottomley> On the larger issue of non-self describing formats like ASN.1: 
if your
James.Bottomley> theory that there's a security hole by allowing opportunistic 
format
James.Bottomley> detection is correct, simply making the user specify is 
palming our bug
James.Bottomley> off on to the user and abdicating responsibility because now 
when
James.Bottomley> they're tricked into an exploit they can be blamed not 
openssl.  If
James.Bottomley> such a bug exists, doing opportunistic format detection the 
better
James.Bottomley> guarantor of overall system security because if such a bug is 
found, it
James.Bottomley> would have to be fixed within openssl to everyone's benefit.

I agree with that sentiment.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[James Bottomley]

On Tue, 2016-11-22 at 18:03 +, Salz, Rich wrote:
> > > It does this by trying to interpret the blob against known ASN.1
> > > definitions, and will only succeed when there's a complete match.
> > >   I'm
> > > not terribly worried...
> 
> I am.  With locales and UTF8, the old simple days of text/binary are
> probably long gone.  And if any ASN.1 definition has extensibility in
> it, then we have to be concerned about things being wrapped,
> something like prefix attacks, and so on.  
>  
> > And even if you were, you should be *more* worried about making
> > *applications* do it for themselves :)
> 
> I cannot control what an application does, and I am not responsible
> for any other application's reputation.  I do have a strongly vested
> stake in OpenSSL's. 
> 
> It is already possible to write a utility library that tries 
> everything in turn, and returns an enumeration that says "seems to be 
> an X509 certificate" etc.  And then another routine that takes that 
> enumeration and the blob and calls the right decoder.  I would be 
> okay with that, even if it were part of OpenSSL.  I am opposed to 
> guessing and parsing in one step, and would -1 any PR for that, 
> forcing a team discussion.

That's not the proposal.  The proposal is to use PEM form because we
can make it uniquely self describing using the guard tags which
obviates the problem above.

On the larger issue of non-self describing formats like ASN.1: if your
theory that there's a security hole by allowing opportunistic format
detection is correct, simply making the user specify is palming our bug
off on to the user and abdicating responsibility because now when
they're tricked into an exploit they can be blamed not openssl.  If
such a bug exists, doing opportunistic format detection the better
guarantor of overall system security because if such a bug is found, it
would have to be fixed within openssl to everyone's benefit.

James

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Salz, Rich]

> That's not the proposal.  The proposal is to use PEM form because we can
> make it uniquely self describing using the guard tags which obviates the
> problem above.

Well that's what you want.  David wants more than that :)
 
> On the larger issue of non-self describing formats like ASN.1: if your theory
> that there's a security hole by allowing opportunistic format detection is
> correct, simply making the user specify is palming our bug off on to the user
> and abdicating responsibility because now when they're tricked into an
> exploit they can be blamed not openssl.  If such a bug exists, doing
> opportunistic format detection the better guarantor of overall system
> security because if such a bug is found, it would have to be fixed within
> openssl to everyone's benefit.

We differ.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Blumenthal, Uri - 0553 - MITLL]

James.Bottomley> Yes, that's right.  When any SSL program sees a TPM 
wrapped key, it
James.Bottomley> should just do the right thing if it has the engine 
capability without
James.Bottomley> needing the user to add any options to the command line.

Mm...  I'm not sure I agree with the method, passing a BIO for the
key_id. 

I’m sure I rather disagree, and rather strongly.

I would much rather have seen a patch where OpenSSL's PEM
module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
from it, securing it somehow (since key_id is expected to be be NUL
terminated) and pass that to the engine.

I would much rather use PEM only to contain keys/certs instead of “pointing” at 
them in some weird way.

My vote goes to a URI based spec rather than bastardising PEM files.

+10^101. ☺

I understand this kinda throws years of developmemt out the window,
but there you have it.

“It’s never too late to turn back on a wrong road”
 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev