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

[David Woodhouse]

On Fri, 2016-11-25 at 08:54 +0100, Nikos Mavrogiannopoulos wrote:
> On Thu, Nov 24, 2016 at 4:33 PM, David Woodhouse  wrote:
> > On Thu, 2016-11-24 at 14:26 +0100, Nikos Mavrogiannopoulos wrote:
> > > On Wed, Nov 23, 2016 at 10:10 PM, David Woodhouse  
> > > wrote:
> > > > > Locales is not the only thing you have to worry about. UTF-8 and 
> > > > > UTF-16
> > > > > can express the same string in various (different) ways, so they 
> > > > > cannot
> > > > > be directly used as passwords. I have recently added RFC7613
> > > > > "normalization" to gnutls, to address the differences.
> > > > > 
> > > > > https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html
> > > > 
> > > > Right. You normalise to NFC, yes? That's what my draft recommends. It's 
> > > > a
> > > > shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
> > > > better than PKCS#8 :)
> > > 
> > > NFC normalization is one step of RFC7613. I think recommending RFC7613
> > > is better than making any recommendation.
> > 
> > Hmmm I'd be happier if RFC7613 had any mention of using its
> > profiles for key derivation. (And even happier if the PKCS#12 and
> > PKCS#8 standards mandated its use!)
> 
> They predate it by several years. At the time they were published very
> few could conceive how UTF-8/unicode would look like.

The original PKCS documents predated the publication of Unicode by a
few months in 1991. Sure, *NOBODY* could have predicted in early 1991
that some kind of coherent approach to character sets would be a good
idea ☺

And yes, UTF-8 came later (1992, I believe¹) but isn't necessary. Even
the original RSA PKCS#12 uses Unicode, and specifies the use of
BMPString for key derivation. Although it neglected to specify any
normalisation. (Did normalisation exist, at that point?)

Even by the time PKCS#5 was brought into the IETF fold in 2000
(RFC2898) it was fairly clear that you kind of had to agree on the
mapping of password characters to numbers, and it was "recommended that
applications follow some common text encoding rules. ASCII and UTF-8
[27] are two possibilities."

I know, it's useless to look back and, with the benefit of hindsight,
criticise the original standards. I'm mostly just reacting to your
"excuse". And standards *do* evolve. PKCS#8 was updated again in
RFC5958 and even then it could have been mandated that UTF-8/NFC be
used for key derivation.

> > This is really something that should be required of the software which
> > *creates* the key file. I've tried to limit my draft to the *use* of
> > existing files — but on the plus side, that means I can say things like
> > "try X and if that doesn't work try Y", at least for the file
> > decryption, if not for hardware.
> > So sure, if there is existing software which is *creating* key files
> > and using the rules in RFC7613 when it does so, then it makes sense for
> > me to suggest that.
> 
> gnutls after 3.5.7 will be using RFC7613 for all types of passwords.

Including *rejecting* passwords such as '' as
shown in example 17 in §4.3? Or do we end up in a situation where
applications which are *loading* key files should attempt such a
password anyway, even though it *shouldn't* work?

And how about PKCS#12? RFC7613 mandates UTF-8 but we just ignore that
bit and do UTF-16 instead for PKCS#12, with the rest of the RFC7613
rules?

-- 
dwmw2

¹ https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

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 Thu, 2016-11-24 at 14:26 +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, Nov 23, 2016 at 10:10 PM, David Woodhouse  wrote:
> > > Locales is not the only thing you have to worry about. UTF-8 and UTF-16
> > > can express the same string in various (different) ways, so they cannot
> > > be directly used as passwords. I have recently added RFC7613
> > > "normalization" to gnutls, to address the differences.
> > > 
> > > https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html
> > 
> > Right. You normalise to NFC, yes? That's what my draft recommends. It's a
> > shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
> > better than PKCS#8 :)
> 
> NFC normalization is one step of RFC7613. I think recommending RFC7613
> is better than making any recommendation.

Hmmm I'd be happier if RFC7613 had any mention of using its
profiles for key derivation. (And even happier if the PKCS#12 and
PKCS#8 standards mandated its use!)

This is really something that should be required of the software which
*creates* the key file. I've tried to limit my draft to the *use* of
existing files — but on the plus side, that means I can say things like
"try X and if that doesn't work try Y", at least for the file
decryption, if not for hardware.

So sure, if there is existing software which is *creating* key files
and using the rules in RFC7613 when it does so, then it makes sense for
me to suggest that.

-- 
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 <1479993631.8937.91.ca...@infradead.org> on Thu, 24 Nov 2016 
13:20:31 +, David Woodhouse  said:

dwmw2> On Wed, 2016-11-23 at 22:33 +0100, Richard Levitte wrote:
dwmw2> > That being said, though, your recommendation should probably specify
dwmw2> > (after discussing it) exactly what keys, certs and so on should be
dwmw2> > supported. Otherwise, everyone will have a slightly different idea of
dwmw2> > what's reasonable and you will end up in the same space as today... 
dwmw2> 
dwmw2> Oh $DEITY yes, that's the whole point. And I don't think I've left much
dwmw2> ambiguity there. As ever, suggestions for improvement would be most
dwmw2> welcome...

dwmw2> http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#formats
dwmw2> 
dwmw2> 5.  File formats
dwmw2> 
dwmw2>...
...

D'oh, I feel silly now.

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 Wed, 2016-11-23 at 22:33 +0100, Richard Levitte wrote:
> That being said, though, your recommendation should probably specify
> (after discussing it) exactly what keys, certs and so on should be
> supported. Otherwise, everyone will have a slightly different idea of
> what's reasonable and you will end up in the same space as today... 

Oh $DEITY yes, that's the whole point. And I don't think I've left much
ambiguity there. As ever, suggestions for improvement would be most
welcome...

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

4.1.  File name

   Many applications support the use of certificates and private keys
   stored in files on the file system.  Such applications MUST support
   the use of files in any of the formats mandated in Section 5, in both
   PEM and DER containers.

   Applications MUST NOT require the user to provide any additional
   hints regarding the contents of the file, such as whether the
   contents are in PEM or DER format.  This MUST be determined by the
   application itself, automatically.

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#formats

5.  File formats

   ...

   Applications MUST accept all of the formats below without requiring
   any additional information from the user or the configuration.  Where
   an application has an existing "key format" or similar option which
   has historically been required to disambiguate between formats
   (either the formats below or between PEM and DER), application SHOULD
   NOT document this use of that legacy option as current practice, and
   SHOULD default to working it out automatically.  Application authors
   who cannot achieve this SHOULD consider taking up goat farming, and
   never touching a cryptographic application again in their life.

5.1.  PKCS#1 and other native ASN.1 encodings

   Applications MUST support unencrypted private keys:

   o  RSA keys in PKCS#1 form as defined by [RFC2437]
   o  DSA keys in the ASN.1 form defined by OpenSSL and documented in
  Appendix B (if DSA keys are supported at all)
   o  ECDSA keys in the form defined by [RFC5915]
   o  EdDSA keys in the form defined by [I-D.ietf-curdle-pkix]

5.2.  PKCS#8

   Applications MUST support keys stored in PKCS#8 form as defined in
   [RFC5208] for all key types.  Applications MUST support unencypted
   PKCS#8 objects, as well as those which are encrypted in various forms
   as discussed in Section 6.1.

   Applications MAY support the updated version of PKCS#8 is defined in
   [RFC5958]. ...

5.3.  PKCS#12

   Applications MUST support the use of certificates and keys from
   PKCS#12 objects ([RFC7292]), encrypted with any of the the methods
   mandated in Section 6.1.  Applications MUST support the use of at
   least SHA1 and SHA256 HMAC, and SHOULD support other HMAC algorithms
   which become common.

6.  Private keys

6.1.  Encryption

   Applications MUST support the encrypted PEM files in the form based
   on [RFC1423] which is commonly used by historical versions of
   OpenSSL, with at least the DES-EDE3-CBC, AES-128-CBC and AES-256-CBC
   modes.

   For PKCS#12 [RFC7292] and PKCS#8 [RFC5208] formats, applications MUST
   support reading objects stored with the following encryption methods:

   o  PBES1 pbeWithMD5AndDES-CBC [RFC2898]
   o  PBES1 pbeWithSHA1And3-KeyTripleDES-CBC [RFC7292]
   o  PBES2 AES-128-CBC (OID: 2.16.840.1.101.3.4.1.2) [RFC2898]
   o  PBES2 AES-256-CBC (OID: 2.16.840.1.101.3.4.1.42) [RFC2898]

   The weak methods included in the above list are unfortunately still
   commonplace, and thus clients need to keep supporting them as noted
   in Section 11.  However, applications MAY emit a warning to the user
   when weak (or no) encryption is used, and MAY require an additional
   configuration directive to enable the use of weakly-encrypted and
   unencrypted keys.

   The presence of these algorithms in the list is not in any way to be
   taken as approval for tools to continue creating objects in such
   forms.  Except for a brief discussion in Section 6.3. the creation of
   private keys is outside the scope of this document.

   ...

-- 
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]

Richard Levitte  skrev: (23 november 2016 22:23:18 CET)
>
>
>David Woodhouse  skrev: (23 november 2016 19:42:29
>CET)
>>On Wed, 2016-11-23 at 17:00 +, Salz, Rich wrote:
>>> 
>>> > FWIW I am perfectly content for applications *not* to
>automatically
>>work
>>> > with such keys. Making the user jump through extra hoops to use
>>them
>>> > would be perfectly fine in my book.
>>> 
>>> oh I see.  "Users shouldn't care, it should just work"  But only for
>>some keys.
>>> 
>>> Part of my I am opposed to guessing.
>>
>>For me it's the other way round. Magically detecting *that* particular
>>perfectly valid PKCS#1 RSA key is actually intended for the gem engine
>>would indeed be guessing. It's a bizarre abuse of PKCS#1 and it
>doesn't
>>seem reasonable for anyone to "guess" that without explicit direction.
>>
>>But for the sane and common cases of PKCS#1, PKCS#8, PKCS#12 and
>>similar files in both DER and PEM forms, for *those* it makes sense
>for
>>applications to Just Work. And it shouldn't really involve "guessing".
>
>I take that as "recognizing what we decide to support". And as has
>already been mentioned, we already do that with d2i_AutoPrivatekey. 

That being said, though, your recommendation should probably specify (after 
discussing it) exactly what keys, certs and so on should be supported. 
Otherwise, everyone will have a slightly different idea of what's reasonable 
and you will end up in the same space as today... 

Cheers 
Richard 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
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]

David Woodhouse  skrev: (23 november 2016 19:42:29 CET)
>On Wed, 2016-11-23 at 17:00 +, Salz, Rich wrote:
>> 
>> > FWIW I am perfectly content for applications *not* to automatically
>work
>> > with such keys. Making the user jump through extra hoops to use
>them
>> > would be perfectly fine in my book.
>> 
>> oh I see.  "Users shouldn't care, it should just work"  But only for
>some keys.
>> 
>> Part of my I am opposed to guessing.
>
>For me it's the other way round. Magically detecting *that* particular
>perfectly valid PKCS#1 RSA key is actually intended for the gem engine
>would indeed be guessing. It's a bizarre abuse of PKCS#1 and it doesn't
>seem reasonable for anyone to "guess" that without explicit direction.
>
>But for the sane and common cases of PKCS#1, PKCS#8, PKCS#12 and
>similar files in both DER and PEM forms, for *those* it makes sense for
>applications to Just Work. And it shouldn't really involve "guessing".

I take that as "recognizing what we decide to support". And as has already been 
mentioned, we already do that with d2i_AutoPrivatekey. 

Cheers 
Richard 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
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 15:49 +, David Woodhouse wrote:
>> 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.
>
> Locales is not the only thing you have to worry about. UTF-8 and UTF-16
> can express the same string in various (different) ways, so they cannot
> be directly used as passwords. I have recently added RFC7613
> "normalization" to gnutls, to address the differences.
>
> https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html

Right. You normalise to NFC, yes? That's what my draft recommends. It's a
shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
better than PKCS#8 :)


-- 
dwmw2

-- 
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 Wed, 2016-11-23 at 17:00 +, Salz, Rich wrote:
> 
> > FWIW I am perfectly content for applications *not* to automatically work
> > with such keys. Making the user jump through extra hoops to use them
> > would be perfectly fine in my book.
> 
> oh I see.  "Users shouldn't care, it should just work"  But only for some 
> keys.
> 
> Part of my I am opposed to guessing.

For me it's the other way round. Magically detecting *that* particular
perfectly valid PKCS#1 RSA key is actually intended for the gem engine
would indeed be guessing. It's a bizarre abuse of PKCS#1 and it doesn't
seem reasonable for anyone to "guess" that without explicit direction.

But for the sane and common cases of PKCS#1, PKCS#8, PKCS#12 and
similar files in both DER and PEM forms, for *those* it makes sense for
applications to Just Work. And it shouldn't really involve "guessing".

-- 
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]

> FWIW I am perfectly content for applications *not* to automatically work
> with such keys. Making the user jump through extra hoops to use them
> would be perfectly fine in my book.

oh I see.  "Users shouldn't care, it should just work"  But only for some keys.

Part of my I am opposed to 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

[David Woodhouse]

On Wed, 2016-11-23 at 14:41 +, Peter Sylvester Edelweb wrote:
> 
> An exemple used by the 'gem' engine.
> 
> openssl rsa -in key.pem -text
> Private-Key: (4096 bit)
> modulus:
>     00:c4:d9:a4:27:ea:17:10:09:35:79:89:fc:10:1f:
>     01:39:34:b7:23:93:5a:61:05:af:b1:04:49:8a:68:
>  
>     95:69:23:21:8d:20:a3:60:e6:e5:65:69:bf:b6:41:
>     f2:40:5c:1d:e3:53:15:90:ff:6d:34:26:45:46:b6:
> 
>    97:f6:7c:f6:0f:5d:d8:59:02:a8:3c:b0:b4:06:2f:
>     c7:b7:c7
> publicExponent: 65537 (0x10001)
> privateExponent: 1 (0x1)
> prime1: 44 (0x2c)
> prime2: 41 (0x29)
> exponent1: 1 (0x1)
> exponent2: 1 (0x1)
> coefficient: 1 (0x1)

Oh, that's special :)

FWIW I am perfectly content for applications *not* to automatically
work with such keys. Making the user jump through extra hoops to use
them would be perfectly fine in my book.

-- 
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 Wed, 2016-11-23 at 10:53 +, David Woodhouse wrote:
> On Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote:
> > 
> > Right...
> > 
> > But then, embedding everything in an OCTET STRING isn't exactly a
> > novel idea either.  How do we discern a DER encoded TSS KEY BLOB 
> > from whatever else that had the same "novel" idea? An OCTET STRING 
> > is an OCTET STRING is an OCTET STRING...  See the dragons hovering 
> > over there? ;-)
> 
> We don't. Crap like that is auto-detected in PEM form only. And yes, 
> it *really* should have used the TssBlob structure, not just the 
> OCTET STRING.

Well, not that I'm advocating doing this, but for TPM keys we actually
can.  The binary content is recognisable even if it just contains a
TPM_KEY12 structure.  The first two bytes are a fixed tag, the second
two must be zero and then we have a set of flags and length fields with
fairly restricted value ranges.  The encrypted private key, authority
and hashes are at the end, so there's an effective and quite long
header at the beginning.  For an RSA2048 key, the structure will always
be 559 bytes long as well.

However, to get back to the plan: you want an additional "do I
recognise this PEM" file callback instead of a "try this bio" one.  I
can code that up and see what it looks like.

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 Wed, 2016-11-23 at 15:21 +0100, Richard Levitte wrote:
> In message <1479908025.8937.74.ca...@infradead.org> on Wed, 23 Nov 2016 
> 13:33:45 +, David Woodhouse  said:
> 
> dwmw2> On Wed, 2016-11-23 at 13:13 +, Salz, Rich wrote:
> dwmw2> > > But, what I get from you is "what if a octet stream matches two 
> different
> dwmw2> > > ASN.1 types?  Is that it?
> dwmw2> > 
> dwmw2> > Yes among others.  How do you know it will *never* happen?
> dwmw2> 
> dwmw2> Because if anyone tries to invent yet *another* ASN.1 form for storing
> dwmw2> keys, I am going to personally visit them in the small hours and stick
> dwmw2> a bat up their nightshirt?
> 
> (let's keep the heat down, shall we?)

You're no fun :)

> dwmw2> Hopefully we don't need to add completely new ones; we can use the
> dwmw2> existing PKCS#8 and PKCS#12 containers for new things.
> dwmw2> 
> dwmw2> But even if a new form is invented which is ambiguous with existing
> dwmw2> forms, that's OK too. We don't support 'detection' of that new format
> dwmw2> by its ASN.1 structure. It'll be PEM-only like the TSS blobs are unless
> dwmw2> the type is explicitly specified.
> 
> Errr...  Now I'm confused.  Wasn't that (explicit type spec) exactly
> what you didn't want to see, no matter if the file was PEM or raw DER?

I do not want to see it for *reasonable* file types which are in
*common* use¹. Users should be able to just give the filename to the
application, and expect it to Just Work.

Invent something new and esoteric and stupid, and I don't care about
that as much. I might have been joking about visiting you in the small
hours, but I'm *not* going to tell applications that they have to
accept your format automatically, and that they can't make users jump
through hoops to explicitly specify it.

-- 
dwmw2

¹ And I'm still more than happy to take input on which file types meet
  that definition, and adjust my draft accordingly.

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

[Peter Sylvester Edelweb]

On 11/23/2016 02:33 PM, David Woodhouse wrote:
> 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.
>

An exemple used by the 'gem' engine.

openssl rsa -in key.pem -text
Private-Key: (4096 bit)
modulus:
00:c4:d9:a4:27:ea:17:10:09:35:79:89:fc:10:1f:
01:39:34:b7:23:93:5a:61:05:af:b1:04:49:8a:68:
 
95:69:23:21:8d:20:a3:60:e6:e5:65:69:bf:b6:41:
f2:40:5c:1d:e3:53:15:90:ff:6d:34:26:45:46:b6:

   97:f6:7c:f6:0f:5d:d8:59:02:a8:3c:b0:b4:06:2f:
c7:b7:c7
publicExponent: 65537 (0x10001)
privateExponent: 1 (0x1)
prime1: 44 (0x2c)
prime2: 41 (0x29)
exponent1: 1 (0x1)
exponent2: 1 (0x1)
coefficient: 1 (0x1)

-BEGIN RSA PRIVATE KEY-
MIICHwIBAAKCAgEAxNmkJ+oXEAk1eYn8EB8BOTS3I5NaYQWvsQRJimg3roh2YLrs
YI4KljjdJcN8EfvyIKfonUDJSRxn4BNInqq8EErhcG8j+BcO+D178RJVvfoiiA/b
f1ru5rxuRywLKD3875QVvA6quc5V5I7EybEDO+v6yhlEZp3TN+3qSdTHnXZwBB7B
rh8Z7XbF7yWKNIeb3rRgfVUodxA5lYTBM92TRdz48b/NT6eS4+hrPvsFu71vCSQB
zbBWukwzzmIEfzGnzJ2NUwaq1uPC1HmzyqMrS90YVdZpTA8yTOVys2HXrUsguTD+
nCTgCizPBYUQe4iYmAgznTPpZ3KHiWGu2Il5lQRzrDcbOqtfvnon8ELqsK7+4QU3
9nNol7BCqPOmcWcT8Kx80qq11AKQYFEX5OygzI+Qp/F1o4oTlIs5/FFtBZZQ/T5+
j9DuewkpDfecKioBpVskZzwOnI9834u+CxCSqfYpb1XYD42HxnxLhsTjcYBzTbx+
xQUnpIUD6HxaCLFfNcCDYJSpD7KXHzO+pekyuLig1DNBlhVRa6i3yYj9JpmraW+6
1Sk2CQ7nvyB4FKAeXUFpCzS0eMZ7lPQ9qXlPiPF2eP//Jgg1FPvnQc+MHcGVaSMh
jSCjYOblZWm/tkHyQFwd41MVkP9tNCZFRraX9nz2D13YWQKoPLC0Bi/Ht8cCAwEA
AQIBAQIBLAIBKQIBAQIBAQIBAQ==
-END RSA PRIVATE KEY-
-- 
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]

> Essentially, you're suggesting that we split out the matching part of the d2i
> functions and put that to good use.  Or do you have some other idea, along
> the lines if magic?

NO.  I am suggesting add one new routine that tries varies "convert to native" 
and returns which conversion worked.  And then another new routine that takes 
that return value and calls that conversion routine directly.  The cost of 
doing this is one extra d2i.  By the application.  And that first routine 
should ideally return a bitmask of all functions that succeeded so that 
handling ambiguities are built-in to the API.
 
> rsalz> Security libraries *should not guess.*
> 
> Isn't telling the application "we think it's a FOO" guessing?  What's the
> application going to do, go "nh, methinks it's a BAR" and try to decode
> the blob as that (and most probably fail) rather than FOO?

It might.  Or it might throw up its hands and give up.  Or it might check to 
see if the file is ambiguous and do something.  The point is, it is not openssl 
that is doing that.  
-- 
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 
<2360f57bb7504a328e5517ac92e19...@usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 
23 Nov 2016 13:51:03 +, "Salz, Rich"  said:

rsalz> 
rsalz> > Why is it different if we do exactly that in libcrypto?
rsalz> 
rsalz> Because *we* are not guessing.  We are telling the application
rsalz> "we think it's a FOO" and then letting the application decide
rsalz> what to do.

We don't have the functionality to do it that way, at all.  All we
have are the d2i functions, which will either return with an error
indication or return the fully parsed and decoded structure.

Essentially, you're suggesting that we split out the matching part of
the d2i functions and put that to good use.  Or do you have some other
idea, along the lines if magic?

rsalz> Security libraries *should not guess.*

Isn't telling the application "we think it's a FOO" guessing?  What's
the application going to do, go "nh, methinks it's a BAR" and try
to decode the blob as that (and most probably fail) rather than FOO?

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 <1479908025.8937.74.ca...@infradead.org> on Wed, 23 Nov 2016 
13:33:45 +, David Woodhouse  said:

dwmw2> On Wed, 2016-11-23 at 13:13 +, Salz, Rich wrote:
dwmw2> > > But, what I get from you is "what if a octet stream matches two 
different
dwmw2> > > ASN.1 types?  Is that it?
dwmw2> > 
dwmw2> > Yes among others.  How do you know it will *never* happen?
dwmw2> 
dwmw2> Because if anyone tries to invent yet *another* ASN.1 form for storing
dwmw2> keys, I am going to personally visit them in the small hours and stick
dwmw2> a bat up their nightshirt?

(let's keep the heat down, shall we?)

dwmw2> Hopefully we don't need to add completely new ones; we can use the
dwmw2> existing PKCS#8 and PKCS#12 containers for new things.
dwmw2> 
dwmw2> But even if a new form is invented which is ambiguous with existing
dwmw2> forms, that's OK too. We don't support 'detection' of that new format
dwmw2> by its ASN.1 structure. It'll be PEM-only like the TSS blobs are unless
dwmw2> the type is explicitly specified.

Errr...  Now I'm confused.  Wasn't that (explicit type spec) exactly
what you didn't want to see, no matter if the file was PEM or raw DER?

-- 
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 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

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

[Richard Levitte]

In message 
 on Wed, 
23 Nov 2016 13:13:05 +, "Salz, Rich"  said:

rsalz> 
rsalz> > Uh...  the d2i functions are already both in one.  Are you saying 
they
rsalz> > should be split in two, one part that does all the checking and the 
other that
rsalz> > just decodes, trusting that all checks are already done?  What you're 
gonna
rsalz> > do there is double part of the work.
rsalz> 
rsalz> Well, not double, but first do the cascade then return an
rsalz> indicator of which specific one worked.  Then the application
rsalz> can call a routine to again do the decode.

Why is it different if we do exactly that in libcrypto?

rsalz> If it bothers you, return the size as an output parameter.
rsalz> That fits with our i2d model.

Dunno about you, but I'm talking d2i, not i2d.  Different beast.

rsalz> > But, what I get from you is "what if a octet stream matches two 
different
rsalz> > ASN.1 types?  Is that it?
rsalz> 
rsalz> Yes among others.  How do you know it will *never* happen?

I don't, and in some cases (such as the TSS KEY BLOB), there will most
likely ONLY be a PEM decoder, which is a much easier ballgame.

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 ;-) ...)


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

[Salz, Rich]

> 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.

Well, not double, but first do the cascade then return an indicator of which 
specific one worked.  Then the application can call a routine to again do the 
decode.

If it bothers you, return the size as an output parameter.  That fits with our 
i2d model.
 
> 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?
-- 
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 15:26 -0500, Thomas Francis, Jr. wrote:
> On 11/22/16 2:37 PM, David Woodhouse 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.

Ewww.

I have to confess that I'm mostly disinclined to care. I'll just go
back to your first sentence cited above, and "clarify" my original
statement to "the PEM that we *support* is ASCII".

But if people *really* expect it to work... would you seriously suggest
that this abomination (at least the EBCDIC and UTF-16+BOM variants) is
something that applications ought to support automatically? If so,
perhaps you'd be arguing that I should update my draft at
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html to
mandate support for it? I suppose checking for a BOM and eating UTF-16
really *isn't* that complicated for an application.

As things stand I suppose I should at least mention it, but I'm
inclined to say that applications MAY support these variants but are
not required to.

-- 
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

[Peter Sylvester Edelweb]

There is at least one real life HSM engine, that encodes numerical identifiers 
as "pseudo prime
numbers", you end up with a
RSA private key that has 1 and 2 prime numbers?

No new ASN.1

Best



On 11/23/2016 11:47 AM, Richard Levitte wrote:
> In message <1479894913.8937.58.ca...@infradead.org> on Wed, 23 Nov 2016 
> 09:55:13 +, David Woodhouse  said:
>
> dwmw2> On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
> dwmw2> > 
> dwmw2> > 
> dwmw2> > dwmw2> So maybe it's just "content types" that we have handlers for, 
> each with
> dwmw2> > dwmw2> an optional PEM tag for matching, *and* an optional match 
> function
> dwmw2> > dwmw2> which is given the parsed ASN.1 and checks if it's a match.
> dwmw2> > 
> dwmw2> > I'm not sure what you mean with a match function...  but going off on
> dwmw2> > a limb, how about a reference to an OpenSSL style ASN1 description?
> dwmw2> > So basically, for an imaginary TSS KEY BLOB (one that actually would
> dwmw2> > use that TssBlob definition we talked about earlier), these three
> dwmw2> > items would be specified:
> dwmw2> > 
> dwmw2> > "TSS KEY BLOB",
> dwmw2> > ASN1_ITEM_rptr(TSS_BLOB),   /* TSS_BLOB ASN1 stuff defined in 
> engine */
> dwmw2> > handler /* Essentially a d2i function */
> dwmw2> > 
> Richard
>

-- 
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 Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote:
> 
> Right...
> 
> But then, embedding everything in an OCTET STRING isn't exactly a
> novel idea either.  How do we discern a DER encoded TSS KEY BLOB from
> whatever else that had the same "novel" idea? An OCTET STRING is an
> OCTET STRING is an OCTET STRING...  See the dragons hovering over
> there? ;-)

We don't. Crap like that is auto-detected in PEM form only. And yes, it
*really* should have used the TssBlob structure, not just 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

[Richard Levitte]

In message <1479894913.8937.58.ca...@infradead.org> on Wed, 23 Nov 2016 
09:55:13 +, David Woodhouse  said:

dwmw2> On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > 
dwmw2> > dwmw2> So maybe it's just "content types" that we have handlers for, 
each with
dwmw2> > dwmw2> an optional PEM tag for matching, *and* an optional match 
function
dwmw2> > dwmw2> which is given the parsed ASN.1 and checks if it's a match.
dwmw2> > 
dwmw2> > I'm not sure what you mean with a match function...  but going off on
dwmw2> > a limb, how about a reference to an OpenSSL style ASN1 description?
dwmw2> > So basically, for an imaginary TSS KEY BLOB (one that actually would
dwmw2> > use that TssBlob definition we talked about earlier), these three
dwmw2> > items would be specified:
dwmw2> > 
dwmw2> >     "TSS KEY BLOB",
dwmw2> >     ASN1_ITEM_rptr(TSS_BLOB),   /* TSS_BLOB ASN1 stuff defined in 
engine */
dwmw2> >     handler /* Essentially a d2i function */
dwmw2> > 
dwmw2> > Or did you mean that the matching would also involve checking the
dwmw2> > contents of the OCTET_STRING that TSS KEY BLOBs currently are, to see
dwmw2> > if they correspond to your structures?  If that's what you mean, my
dwmw2> > gut feeling tells me - and I haven't had my morning coffee yet - we're
dwmw2> > now moving into a territory where I fully expect dragons...  not to
dwmw2> > mention the worries Rich expressed.
dwmw2> 
dwmw2> Oh $DEITY no,  not looking in the contents of the OCTET_STRING.
dwmw2> Basically I'm thinking of doing precisely what d2i_AutoPrivateKey()
dwmw2> already does, just with expanded coverage and slightly less hard-coded
dwmw2> stuff.



dwmw2> Doing it like that would prevent any implementations (like the one in
dwmw2> the TPM engine) from being *tempted* to go prodding around in the
dwmw2> contents of OCTET STRINGs. Which is probably a feature :)

Right...

But then, embedding everything in an OCTET STRING isn't exactly a
novel idea either.  How do we discern a DER encoded TSS KEY BLOB from
whatever else that had the same "novel" idea? An OCTET STRING is an
OCTET STRING is an OCTET STRING...  See the dragons hovering over
there? ;-)

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 Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
> 
> 
> dwmw2> So maybe it's just "content types" that we have handlers for, each with
> dwmw2> an optional PEM tag for matching, *and* an optional match function
> dwmw2> which is given the parsed ASN.1 and checks if it's a match.
> 
> I'm not sure what you mean with a match function...  but going off on
> a limb, how about a reference to an OpenSSL style ASN1 description?
> So basically, for an imaginary TSS KEY BLOB (one that actually would
> use that TssBlob definition we talked about earlier), these three
> items would be specified:
> 
>     "TSS KEY BLOB",
>     ASN1_ITEM_rptr(TSS_BLOB),   /* TSS_BLOB ASN1 stuff defined in engine */
>     handler /* Essentially a d2i function */
> 
> Or did you mean that the matching would also involve checking the
> contents of the OCTET_STRING that TSS KEY BLOBs currently are, to see
> if they correspond to your structures?  If that's what you mean, my
> gut feeling tells me - and I haven't had my morning coffee yet - we're
> now moving into a territory where I fully expect dragons...  not to
> mention the worries Rich expressed.

Oh $DEITY no,  not looking in the contents of the OCTET_STRING.
Basically I'm thinking of doing precisely what d2i_AutoPrivateKey()
already does, just with expanded coverage and slightly less hard-coded
stuff.

The "match" part there is a little simplistic; we basically parse the
ASN.1 into a STACK_OF(ASN1_TYPE), then 

 if (sk_ASN1_TYPE_num(inkey) == 6)
   /* it's DSA in OpenSSL's format */
 if (sk_ASN1_TYPE_num(inkey) == 4)
   /* it's ECDSA according to RFC5915 */
 if (sk_ASN1_TYPE_num(unkey) == 3)
   /* Unencrypted PKCS#8 */

... etc.

Those checks could possibly stand to be a *little* more discerning, and
 each one might live in a specific format-handler's "ASN.1 match"
function. But that's the general idea. And we *do* already have the
"decide, then parse" model that Rich was talking about.

And yes, if we're going to make the checks slightly more discerning
then instead of just counting the items in the sequence, we could see
if it matches the ASN.1 description. And as you say, it doesn't have to
be a match *function* for each handler; just the ASN.1 description. 

Doing it like that would prevent any implementations (like the one in
the TPM engine) from being *tempted* to go prodding around in the
contents of OCTET STRINGs. Which is probably a feature :)

-- 
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 Wed, 2016-11-23 at 09:39 +0100, Tomas Mraz wrote:
> 
> I also would not be too much worried - the API call should not be
> completely universal - the application should know whether it is
> loading a certificate or private key. It should just be able to use a
> single call to load a certificate in PEM, DER, or whatever other
> possible data format. The same for private keys, etc.

Well, except in the case where the application asks to use a PKCS#12
file as the identity. In which case you want to load cert, key, and
supporting cert chain all from the same place.

And you often have a PEM file which contains both the certificate and
the private key.

But yes, generally you *know* what you're looking for.

-- 
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 <1479889418.8937.54.ca...@infradead.org> on Wed, 23 Nov 2016 
08:23:38 +, David Woodhouse  said:

dwmw2> On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Actually, I agree with this, and that goes along with how our PEM
dwmw2> > routines work (specifically, PEM_X509_INFO_read_bio()), it just
dwmw2> > treats the data as an octet string and hands it down to a d2i routine
dwmw2> > of choice, with a pointer to where to place the result.
dwmw2> > 
dwmw2> > It's not very hard to imagine adding the possibility for external
dwmw2> > handlers for specific PEM content types, which could be handed an
dwmw2> > octet string and a pointer to a X509_INFO (which is the structure used
dwmw2> > to collect the data in), or something like that (I can also imagine
dwmw2> > having one separate handler for each type of data that can be
dwmw2> > returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL,
dwmw2> > and so on and so forth).  That would make it possible for an engine to
dwmw2> > declare its own handler during the binding call, along with all other
dwmw2> > information it feeds back to libcrypto.
dwmw2> 
dwmw2> Yeah, something like that.
dwmw2> 
dwmw2> It's worth noting that the 'PEM content types' are just the same as the
dwmw2> 'DER content types'. It's just that if you have a PEM header, you know
dwmw2> precisely *which* DER content type you have after base64-decoding (and
dwmw2> decryption in some cases), and you don't have to do what
dwmw2> d2i_AutoPrivateKey() does to infer it from the ASN.1 structure.

True.

dwmw2> So maybe it's just "content types" that we have handlers for, each with
dwmw2> an optional PEM tag for matching, *and* an optional match function
dwmw2> which is given the parsed ASN.1 and checks if it's a match.

I'm not sure what you mean with a match function...  but going off on
a limb, how about a reference to an OpenSSL style ASN1 description?
So basically, for an imaginary TSS KEY BLOB (one that actually would
use that TssBlob definition we talked about earlier), these three
items would be specified:

"TSS KEY BLOB",
ASN1_ITEM_rptr(TSS_BLOB),   /* TSS_BLOB ASN1 stuff defined in engine */
handler /* Essentially a d2i function */

Or did you mean that the matching would also involve checking the
contents of the OCTET_STRING that TSS KEY BLOBs currently are, to see
if they correspond to your structures?  If that's what you mean, my
gut feeling tells me - and I haven't had my morning coffee yet - we're
now moving into a territory where I fully expect dragons...  not to
mention the worries Rich expressed.

Cheers,
Richard ( coffee.  Now! )

-- 
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

[Tomas Mraz]

On St, 2016-11-23 at 00:03 +0100, Richard Levitte wrote:
> In message <021a5d5b885845f5ab79c4420232e...@usma1ex-dag1mb1.msg.corp
> .akamai.com> on Tue, 22 Nov 2016 18:03:31 +, "Salz, Rich"  akamai.com> 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?

I also would not be too much worried - the API call should not be
completely universal - the application should know whether it is
loading a certificate or private key. It should just be able to use a
single call to load a certificate in PEM, DER, or whatever other
possible data format. The same for private keys, etc.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)



-- 
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:06 +0100, Richard Levitte wrote:
> 
> 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.

Yeah, something like that.

It's worth noting that the 'PEM content types' are just the same as the
'DER content types'. It's just that if you have a PEM header, you know
precisely *which* DER content type you have after base64-decoding (and
decryption in some cases), and you don't have to do what
d2i_AutoPrivateKey() does to infer it from the ASN.1 structure.

So maybe it's just "content types" that we have handlers for, each with
an optional PEM tag for matching, *and* an optional match function
which is given the parsed ASN.1 and checks if it's a match.

-- 
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 <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

[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

[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

[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

[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

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

[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]

> > 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

[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

[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

[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

[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

[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 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

[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

[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 <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 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 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

[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 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

[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

[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

[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 
 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

[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 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

[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

[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

[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

[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

[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

[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

[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 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 <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

[Richard Levitte]

I'm leaning in that direction as well.

Speaking of URIs, you might be interested in some work I did last
week, which would do good to get a bit of external scrutiny.

https://github.com/openssl/openssl/pull/1961 (for URI decoding)
https://github.com/openssl/openssl/pull/1962 (a STORE module that
essentially uses a URI and tries to fetch certs, keys, crls, ... from
it)

Please have a look.

Cheers,
Richard

In message <20161121135052.18280523.78584.102...@ll.mit.edu> on Mon, 21 Nov 
2016 13:50:43 +, "Blumenthal, Uri - 0553 - MITLL" <u...@ll.mit.edu> said:

uri> Frankly, I think this approach of specially-encoded PEM or DER files 
telling the app what key to ask from the engine is madness, compared to the 
straightforward URI approach (no pun intended :).
uri> 
uri> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE 
network.
uri>   Original Message  
uri> From: David Woodhouse
uri> Sent: Monday, November 21, 2016 08:43
uri> To: Richard Levitte; openssl-dev@openssl.org
uri> Reply To: openssl-dev@openssl.org
uri> Cc: James Bottomley
uri> Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM 
based RSA keys in openssl
uri> 
uri> On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
uri> > 
uri> > Many years ago, I was thinking of something along the same lines, but
uri> > with a .pem file that would just have a few headers, holding the name
uri> > of the intended engine and the key identity, something like this:
uri> > 
uri> >     -BEGIN PRIVATE KEY-
uri> >     X-key-id: flarflarflar
uri> >     X-key-engine: foo
uri> >     -END PRIVATE KEY-
uri> > 
uri> > The intent was that the PEM code would be massaged to recognise these
uri> > headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
uri> > with those data and that would be it.
uri> > 
uri> > James, did I catch your intention about right?  I think that's
uri> > essentially what e_tpm.c does for loading keys, right?
uri> ‎
uri> Right. The TPM engine currently uses BEGIN TSS KEY BLOB-; I
uri> added that a few years back (it used to just dump the binary blob
uri> instead). Both the TPM ENGINE and GnuTLS will load those files, as
uri> noted at http://www.infradead.org/openconnect/tpm.html
uri> 
uri> The problem is that applications have to jump through special hoops to
uri> recognise the files and invoke the engine (and there's a special API in
uri> GnuTLS too). It would be good if the appropriate engine could be
uri> invoked *automatically*, so the crypto library just does the right
uri> thing without all the applications even having to *know* about it.
uri> (Just like GnuTLS will automatically Just Work in many situations when
uri> presented with a PKCS#11 URI instead a filename, as OpenSSL also
uri> should, but doesn't yet.)
uri> 
uri> However, the contents of the PEM file should *not* be OpenSSL-specific
uri> and have engine names; I objected to James's original incarnation of
uri> this, which had something like -BEGIN tpm ENGINE PRIVATE KEY-
uri> and had the "tpm" engine automatically loaded on demand. It needs to be
uri> something generic. Which means engines need to indicate *which* PEM
uri> headers they can grok. And maybe the solution to this will tie in with
uri> the general fixes we need for "normal" key files, so that applications
uri> can Just Work with all of those too (qv¹).
uri> 
uri> Once the dust settles on TPMv2.0 we should probably put together an I-D 
uri> for the TPM-wrapped blob PEM files. And I should definitely add
uri> something about them to ¹.
uri> 
uri> -- 
uri> dwmw2
uri> 
uri> ¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
-- 
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 Mon, 2016-11-21 at 13:42 +, David Woodhouse wrote:
> On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
> > 
> > Many years ago, I was thinking of something along the same lines, 
> > but with a .pem file that would just have a few headers, holding 
> > the name of the intended engine and the key identity, something
> > like this:
> > 
> > -BEGIN PRIVATE KEY-
> > X-key-id: flarflarflar
> > X-key-engine: foo
> > -END PRIVATE KEY-
> > 
> > The intent was that the PEM code would be massaged to recognise 
> > these headers and would then use ENGINE_by_id() /
> > ENGINE_load_private_key() with those data and that would be it.
> > 
> > James, did I catch your intention about right?  I think that's
> > essentially what e_tpm.c does for loading keys, right?

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

> Right. The TPM engine currently uses BEGIN TSS KEY BLOB-; I
> added that a few years back (it used to just dump the binary blob
> instead). Both the TPM ENGINE and GnuTLS will load those files, as
> noted at http://www.infradead.org/openconnect/tpm.html
> 
> The problem is that applications have to jump through special hoops 
> to recognise the files and invoke the engine (and there's a special 
> API in GnuTLS too). It would be good if the appropriate engine could 
> be invoked *automatically*, so the crypto library just does the right
> thing without all the applications even having to *know* about it.
> (Just like GnuTLS will automatically Just Work in many situations 
> when presented with a PKCS#11 URI instead a filename, as OpenSSL also
> should, but doesn't yet.)
> 
> However, the contents of the PEM file should *not* be OpenSSL
> -specific and have engine names; I objected to James's original 
> incarnation of this, which had something like
>  -BEGIN tpm ENGINE PRIVATE KEY-
> and had the "tpm" engine automatically loaded on demand. It needs to 
> be  something generic. Which means engines need to indicate *which* 
> PEM headers they can grok. And maybe the solution to this will tie in
> with the general fixes we need for "normal" key files, so that
> applications can Just Work with all of those too (qv¹).

Right, I forgot to add in the blurb that I'm looking for a mechanism
that all SSL implementations could follow, so it can't be tied to
anything specific in openSSL (like the engine name).  I modelled it on
gnutls because that has the same "just works(tm)" characteristic that I
was looking for.

> Once the dust settles on TPMv2.0 we should probably put together an I
> -D for the TPM-wrapped blob PEM files. And I should definitely add
> something about them to ¹.

Once we agree, I'll be happy to write up something.  We can use the pem
header concept to extend this format if it becomes necessary.

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

[Nikos Mavrogiannopoulos]

On Mon, 2016-11-21 at 13:42 +, David Woodhouse wrote:

> Right. The TPM engine currently uses BEGIN TSS KEY BLOB-; I
> added that a few years back (it used to just dump the binary blob
> instead). Both the TPM ENGINE and GnuTLS will load those files, as
> noted at http://www.infradead.org/openconnect/tpm.html
> The problem is that applications have to jump through special hoops
> to
> recognise the files and invoke the engine (and there's a special API
> in
> GnuTLS too). It would be good if the appropriate engine could be
> invoked *automatically*, so the crypto library just does the right
> thing without all the applications even having to *know* about it.
> (Just like GnuTLS will automatically Just Work in many situations
> when
> presented with a PKCS#11 URI instead a filename, as OpenSSL also
> should, but doesn't yet.)

Note that for TPM wrapped keys, there was no new API introduced for
gnutls. The intention is to access such keys using a special URI [0].
However, since tpm2.0 is a completely different beast, I no longer
believe on direct TPM support, without a PKCS#11 wrapper.

[0]. https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01

regards,
Nikos

-- 
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]

Frankly, I think this approach of specially-encoded PEM or DER files telling 
the app what key to ask from the engine is madness, compared to the 
straightforward URI approach (no pun intended :).

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: David Woodhouse
Sent: Monday, November 21, 2016 08:43
To: Richard Levitte; openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Cc: James Bottomley
Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM 
based RSA keys in openssl

On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
> 
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
> 
>     -BEGIN PRIVATE KEY-
>     X-key-id: flarflarflar
>     X-key-engine: foo
>     -END PRIVATE KEY-
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 
> James, did I catch your intention about right?  I think that's
> essentially what e_tpm.c does for loading keys, right?
‎
Right. The TPM engine currently uses BEGIN TSS KEY BLOB-; I
added that a few years back (it used to just dump the binary blob
instead). Both the TPM ENGINE and GnuTLS will load those files, as
noted at http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -BEGIN tpm ENGINE PRIVATE KEY-
and had the "tpm" engine automatically loaded on demand. It needs to be
something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv¹).

Once the dust settles on TPMv2.0 we should probably put together an I-D 
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ¹.

-- 
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html


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 Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
> 
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
> 
>     -BEGIN PRIVATE KEY-
>     X-key-id: flarflarflar
>     X-key-engine: foo
>     -END PRIVATE KEY-
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 
> James, did I catch your intention about right?  I think that's
> essentially what e_tpm.c does for loading keys, right?

Right. The TPM engine currently uses BEGIN TSS KEY BLOB-; I
added that a few years back (it used to just dump the binary blob
instead). Both the TPM ENGINE and GnuTLS will load those files, as
noted at http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -BEGIN tpm ENGINE PRIVATE KEY-
and had the "tpm" engine automatically loaded on demand. It needs to be
 something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv¹).

Once the dust settles on TPMv2.0 we should probably put together an I-D 
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ¹.

-- 
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

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

[Blumenthal, Uri - 0553 - MITLL]

Thank you! I think I understand. (Sounds like an ugly and hardly necessary 
complication to me – not to mention that there might not be a filesystem to 
keep those around, but…)
— 
Regards,
Uri


On 11/16/16, 5:06 PM, "openssl-dev on behalf of Dr. Stephen Henson" 
 wrote:

On Wed, Nov 16, 2016, Richard Levitte wrote:

> If I understand correctly, the intention is to avoid having to use
> ENGINE_load_private_key() directly or having to say '-keyform ENGINE'
> to the openssl commands, and to avoid having to remember some cryptic
> key identity to give with '-key'.  Instead of all that, just give the
> name of a .pem file with '-key' and if that file contains some kind of
> magic information that the engine can understand, it will dig out a
> reference to the hw protected key.
> 
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
> 
> -BEGIN PRIVATE KEY-
> X-key-id: flarflarflar
> X-key-engine: foo
> -END PRIVATE KEY-
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 

Yes me too. Though if you're doing that something like "ENGINE PRIVATE KEY"
or "OPENSSL ENGINE PRIVATE KEY" as just "PRIVATE KEY" is associated with
PKCS#8.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



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

[Dr. Stephen Henson]

On Wed, Nov 16, 2016, Richard Levitte wrote:

> If I understand correctly, the intention is to avoid having to use
> ENGINE_load_private_key() directly or having to say '-keyform ENGINE'
> to the openssl commands, and to avoid having to remember some cryptic
> key identity to give with '-key'.  Instead of all that, just give the
> name of a .pem file with '-key' and if that file contains some kind of
> magic information that the engine can understand, it will dig out a
> reference to the hw protected key.
> 
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
> 
> -BEGIN PRIVATE KEY-
> X-key-id: flarflarflar
> X-key-engine: foo
> -END PRIVATE KEY-
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 

Yes me too. Though if you're doing that something like "ENGINE PRIVATE KEY"
or "OPENSSL ENGINE PRIVATE KEY" as just "PRIVATE KEY" is associated with
PKCS#8.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
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]

If I understand correctly, the intention is to avoid having to use
ENGINE_load_private_key() directly or having to say '-keyform ENGINE'
to the openssl commands, and to avoid having to remember some cryptic
key identity to give with '-key'.  Instead of all that, just give the
name of a .pem file with '-key' and if that file contains some kind of
magic information that the engine can understand, it will dig out a
reference to the hw protected key.

Many years ago, I was thinking of something along the same lines, but
with a .pem file that would just have a few headers, holding the name
of the intended engine and the key identity, something like this:

-BEGIN PRIVATE KEY-
X-key-id: flarflarflar
X-key-engine: foo
-END PRIVATE KEY-

The intent was that the PEM code would be massaged to recognise these
headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
with those data and that would be it.

James, did I catch your intention about right?  I think that's
essentially what e_tpm.c does for loading keys, right?

Cheers,
Richard ( gotta love to see someone use "flarflarflar" as a key id ;-) )

In message <60f14e07-d0dc-486f-aff7-c74f5929b...@ll.mit.edu> on Wed, 16 Nov 
2016 15:56:05 +, "Blumenthal, Uri - 0553 - MITLL"  said:

uri> My apologies – I don’t fully understand “file based engine keys”. I 
thought the keys were either on a hardware device (a TPM, a PKCS#11-accessible 
HSM or smartcard, etc), or in a file. If a key is in a file – it’s not an 
“engine key”.
uri> 
uri> What am I missing, and what’s your use case(s)?
uri> — 
uri> Regards,
uri> Uri
uri> 
uri> 
uri> On 11/16/16, 10:46 AM, "openssl-dev on behalf of James Bottomley" 
 wrote:
uri> 
uri> [David Woodhouse told me that openssl-dev is a closed list, so the
uri> original messages got trashed.  This is a resend with apologies to
uri> David and Peter]
uri> 
uri> One of the principle problems of using TPM based keys is that there's
uri> no easy way of integrating them with standard file based keys.  This
uri> proposal adds a generic method for handling file based engine keys that
uri> can be loaded as PEM files.  Integration into the PEM loader requires a
uri> BIO based engine API callback which the first patch adds.  The second
uri> patch checks to see if the key can be loaded by any of the present
uri> engines.  Note that this requires that any engine which is to be used
uri> must be present and initialised via openssl.cnf.
uri> 
uri> I'll also post to this list the patch to openssl_tpm_engine that makes
uri> use if this infrastructure so the integration of the whole can be seen.
uri>  It should also be noted that gnutls has had this functionality since
uri> 2012.
uri> 
uri> The patch was done against 1.0.2h for easier testing and you can try it
uri> and the openssl_tpm_engine out (if you run openSUSE) here:
uri> 
uri> https://build.opensuse.org/project/show/home:jejb1:Tumbleweed
uri> 
uri> James
uri> 
uri> ---
uri> 
uri> James Bottomley (2):
uri>   engine: add new flag based method for loading engine keys
uri>   pem: load engine keys
uri> 
uri>  crypto/engine/eng_int.h  |  1 +
uri>  crypto/engine/eng_pkey.c | 38 ++
uri>  crypto/engine/engine.h   | 26 ++
uri>  crypto/pem/pem_pkey.c|  5 +
uri>  4 files changed, 70 insertions(+)
uri> 
uri> -- 
uri> openssl-dev mailing list
uri> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
uri> 
-- 
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]

My apologies – I don’t fully understand “file based engine keys”. I thought the 
keys were either on a hardware device (a TPM, a PKCS#11-accessible HSM or 
smartcard, etc), or in a file. If a key is in a file – it’s not an “engine key”.

What am I missing, and what’s your use case(s)?
— 
Regards,
Uri


On 11/16/16, 10:46 AM, "openssl-dev on behalf of James Bottomley" 
 wrote:

[David Woodhouse told me that openssl-dev is a closed list, so the
original messages got trashed.  This is a resend with apologies to
David and Peter]

One of the principle problems of using TPM based keys is that there's
no easy way of integrating them with standard file based keys.  This
proposal adds a generic method for handling file based engine keys that
can be loaded as PEM files.  Integration into the PEM loader requires a
BIO based engine API callback which the first patch adds.  The second
patch checks to see if the key can be loaded by any of the present
engines.  Note that this requires that any engine which is to be used
must be present and initialised via openssl.cnf.

I'll also post to this list the patch to openssl_tpm_engine that makes
use if this infrastructure so the integration of the whole can be seen.
 It should also be noted that gnutls has had this functionality since
2012.

The patch was done against 1.0.2h for easier testing and you can try it
and the openssl_tpm_engine out (if you run openSUSE) here:

https://build.opensuse.org/project/show/home:jejb1:Tumbleweed

James

---

James Bottomley (2):
  engine: add new flag based method for loading engine keys
  pem: load engine keys

 crypto/engine/eng_int.h  |  1 +
 crypto/engine/eng_pkey.c | 38 ++
 crypto/engine/engine.h   | 26 ++
 crypto/pem/pem_pkey.c|  5 +
 4 files changed, 70 insertions(+)

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



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