Quantcast

[gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

James Bottomley
The reason this comes about is because we already have a standard form
for TPM 1.2 keys here:

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

However, since I'm working on TPM2 enabling for openssl and gnutls, I
need to come up with a new key format because TPM2 requires some extra
parameters and the original TSS KEY BLOB, being a single
ASN1_OCTET_STRING isn't expandable.

As a digression, the extra parameters that TPM2 needs are:

   1. A public key blob.  In TPM12 the key complex was a joint
      public/private part.  In TPM2, the public and private key structures
      have variable length and are supplied separately.
   2. a boolean for emptyAuth.  In TPM12 there's a way to tell if a
      structure has no authorization.  In TPM2 there's no such thing as no
      authorization, but there's a conventional empty authorization to
      replace it but no way of querying whether any given key is using it,
      so we need to know explicitly whether to prompt for a password or
      not.
   3. There are different forms a TPM private key could be in.  One is
      symmetrically encrypted with a TPM private key, which makes it
      loadable, meaning it must be produced on the TPM itself and the
      other is asymmetrically encrypted meaning it can be produced away
      from the TPM but must be imported before being loaded.

I think there's value in having a universal structure for the key
representations, so I'm proposing an ASN1 representation that will work
for both TPM1.2 and TPM2 keys.  I'd also like it to be self describing,
so I think we should use an OID as the initial parameter of the
sequence.  With that, I think the format that works is

TPMKey ::= SEQUENCE {
        type OBJECT IDENTIFIER
        version [0] IMPLICIT INTEGER OPTIONAL
        emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL
        parent [2] IMPLICIT INTEGER OPTIONAL
        publicKey [3] IMPLICIT OCTET STRING OPTIONAL
        privateKey OCTET STRING
}

Where TPM12 keys would have a TPM12Key type and use no optional fields
(meaning only privateKey) and TPM2 keys would have type TPM2LoadableKey
or TPM2ImportableKey type and then make use of all the optional fields
(except version).

Version is there for future expansion, but is unused in the initial
incarnation.

I'm torn on where to get the OIDs from.  Since this is a TPM key, it
might make sense to use the TCG OID (2.23.133) and just add something
they haven't already used, like 10 for key formats, or we could go with
a pkcs OID (1.2.840.113549.1)

If we can agree on this, we can update David's document and make it a
formal RFC.

Thoughts?

James


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] [openssl-dev] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

James Bottomley
On Fri, 2016-12-23 at 21:12 +0100, Richard Levitte wrote:

> In message <[hidden email]> on Fri,
> 23 Dec 2016 10:06:03 -0800, James Bottomley <
> [hidden email]> said:
>
> James.Bottomley> The reason this comes about is because we already
> have a standard form
> James.Bottomley> for TPM 1.2 keys here:
> James.Bottomley>
> James.Bottomley> http://david.woodhou.se/draft-woodhouse-cert-best-pr
> actice.html#ident-tpm
> James.Bottomley>
> James.Bottomley> However, since I'm working on TPM2 enabling for
> openssl and gnutls, I
> James.Bottomley> need to come up with a new key format because TPM2
> requires some extra
> James.Bottomley> parameters and the original TSS KEY BLOB, being a
> single
> James.Bottomley> ASN1_OCTET_STRING isn't expandable.
> James.Bottomley>
> James.Bottomley> As a digression, the extra parameters that TPM2
> needs are:
> James.Bottomley>
> James.Bottomley>    1. A public key blob.  In TPM12 the key complex
> was a joint
> James.Bottomley>       public/private part.  In TPM2, the public and
> private key structures
> James.Bottomley>       have variable length and are supplied
> separately.
> James.Bottomley>    2. a boolean for emptyAuth.  In TPM12 there's a
> way to tell if a
> James.Bottomley>       structure has no authorization.  In TPM2
> there's no such thing as no
> James.Bottomley>       authorization, but there's a conventional
> empty authorization to
> James.Bottomley>       replace it but no way of querying whether any
> given key is using it,
> James.Bottomley>       so we need to know explicitly whether to
> prompt for a password or
> James.Bottomley>       not.
> James.Bottomley>    3. There are different forms a TPM private key
> could be in.  One is
> James.Bottomley>       symmetrically encrypted with a TPM private
> key, which makes it
> James.Bottomley>       loadable, meaning it must be produced on the
> TPM itself and the
> James.Bottomley>       other is asymmetrically encrypted meaning it
> can be produced away
> James.Bottomley>       from the TPM but must be imported before being
> loaded.
> James.Bottomley>
> James.Bottomley> I think there's value in having a universal
> structure for the key
> James.Bottomley> representations, so I'm proposing an ASN1
> representation that will work
> James.Bottomley> for both TPM1.2 and TPM2 keys.  I'd also like it to
> be self describing,
> James.Bottomley> so I think we should use an OID as the initial
> parameter of the
> James.Bottomley> sequence.  With that, I think the format that works
> is
> James.Bottomley>
> James.Bottomley> TPMKey ::= SEQUENCE {
> James.Bottomley>        type            OBJECT IDENTIFIER
> James.Bottomley>        version         [0] IMPLICIT INTEGER OPTIONAL
> James.Bottomley>        emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
> James.Bottomley>        parent          [2] IMPLICIT INTEGER OPTIONAL
> James.Bottomley>        publicKey       [3] IMPLICIT OCTET STRING
> OPTIONAL
> James.Bottomley>        privateKey      OCTET STRING
> James.Bottomley> }
> James.Bottomley>
> James.Bottomley> Where TPM12 keys would have a TPM12Key type and use
> no optional fields
> James.Bottomley> (meaning only privateKey) and TPM2 keys would have
> type TPM2LoadableKey
> James.Bottomley> or TPM2ImportableKey type and then make use of all
> the optional fields
> James.Bottomley> (except version).
> James.Bottomley>
> James.Bottomley> Version is there for future expansion, but is unused
> in the initial
> James.Bottomley> incarnation.
> James.Bottomley>
> James.Bottomley> I'm torn on where to get the OIDs from.  Since this
> is a TPM key, it
> James.Bottomley> might make sense to use the TCG OID (2.23.133) and
> just add something
> James.Bottomley> they haven't already used, like 10 for key formats,
> or we could go with
> James.Bottomley> a pkcs OID (1.2.840.113549.1)
> James.Bottomley>
> James.Bottomley> If we can agree on this, we can update David's
> document and make it a
> James.Bottomley> formal RFC.
> James.Bottomley>
> James.Bottomley> Thoughts?
>
> First reaction is +1, at least for actually making a universally
> parsable description.

Thanks.  After playing more I think I'd like to make the tags explicit
rather than implicit so I can see the contents easily with asn1parse
(and we're not in any way pressed for space, which is the usual reason
for implicit tags).

> One detail that escapes me, though, is why you don't use version for,
> well, TPM versions?  So, something like this?
>
> TCG OBJECT IDENTIFIER ::=
>         { joint-iso-itu-t(2) international-organizations(23) TCG(133)
>   }

Because what OID to use is part of the discussion.  Perhaps I wasn't
clear about what I want: the OID needs to identify what the structure
describes, so one OID for each of the three key types, so it would have
a prefix either in the TCG or pkcs space (or something else if that's
what we agree), then three OID postfixes.

> TPMKey ::= SEQUENCE {
>        type        OBJECT IDENTIFIER    -- always TCG
>        version     [0] INTEGER { v1_2(0), v2(1) } DEFAULT v1_2

Version, I'm envisaging is for expansion of the structure in a
compatible way.  For TPM2 keys, I think we're going to need additional
policy descriptors eventually when people start using a policy to
authorise instead of an authorisation value.  We'd use the version
number to indicate a future expanded structure.

So the OID identifies the object structure and version is for
versioning the actual structure.

James

>        emptyAuth   [1] IMPLICIT BOOLEAN OPTIONAL        -- v2 only
>        parent      [2] IMPLICIT INTEGER OPTIONAL        -- v2 only
>        publicKey   [3] IMPLICIT OCTET STRING OPTIONAL   -- v2 only
>        privateKey  OCTET STRING
> }
>
> Cheers,
> Richard
>
> --
> Richard Levitte         [hidden email]
> OpenSSL Project         http://www.openssl.org/~levitte/
>


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

Nikos Mavrogiannopoulos
In reply to this post by James Bottomley
On Fri, Dec 23, 2016 at 7:06 PM, James Bottomley
<[hidden email]> wrote:
> The reason this comes about is because we already have a standard form
> for TPM 1.2 keys here:
> http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ident-tpm
> However, since I'm working on TPM2 enabling for openssl and gnutls, I
> need to come up with a new key format because TPM2 requires some extra
> parameters and the original TSS KEY BLOB, being a single
> ASN1_OCTET_STRING isn't expandable.
[...]
> I'm torn on where to get the OIDs from.  Since this is a TPM key, it
> might make sense to use the TCG OID (2.23.133) and just add something
> they haven't already used, like 10 for key formats, or we could go with
> a pkcs OID (1.2.840.113549.1)

OIDs under some umbrella normally need to be registered within the
organization they belong to. If you cannot find a suitable
organization to get these OIDs from I'll check whether we can get
something under redhat's OIDs.

> If we can agree on this, we can update David's document and make it a
> formal RFC.

Shouldn't version be first? However, I'm not sure how expandable is
ASN.1 using version fields (I've seen no structure being able to be
re-used using a different version). An alternative approach would to
allow for future extensions, i.e., something like the PKIX Extension
field, which is an OID+data.

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

James Bottomley
On Sat, 2016-12-24 at 14:25 +0100, Nikos Mavrogiannopoulos wrote:

> On Fri, Dec 23, 2016 at 7:06 PM, James Bottomley
> <[hidden email]> wrote:
> > The reason this comes about is because we already have a standard
> > form for TPM 1.2 keys here:
> > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ide
> > nt-tpm
> > However, since I'm working on TPM2 enabling for openssl and gnutls,
> > I need to come up with a new key format because TPM2 requires some
> > extra parameters and the original TSS KEY BLOB, being a single
> > ASN1_OCTET_STRING isn't expandable.
> [...]
> > I'm torn on where to get the OIDs from.  Since this is a TPM key,
> > it might make sense to use the TCG OID (2.23.133) and just add
> > something they haven't already used, like 10 for key formats, or we
> > could go with a pkcs OID (1.2.840.113549.1)
>
> OIDs under some umbrella normally need to be registered within the
> organization they belong to. If you cannot find a suitable
> organization to get these OIDs from I'll check whether we can get
> something under redhat's OIDs.

I think, since it's a key format, the two above are the potential ones.
 It would be TCG if they want to take it into their standard, otherwise
PKCS is RSA Inc.

> > If we can agree on this, we can update David's document and make it
> > a formal RFC.
>
> Shouldn't version be first?

I put OID first because that's what makes the structure self
describing.  You simply need to look for the SEQUENCE OBJECT OID
prefix.  We can easily register our own, of course as well.  If version
goes first, you have a variable prefix.

>  However, I'm not sure how expandable is ASN.1 using version fields
> (I've seen no structure being able to be re-used using a different
> version). An alternative approach would to allow for future
> extensions, i.e., something like the PKIX Extension field, which is
> an OID+data.

As long as the expansion fields are optional, it works nicely.  X509
and X509v3 are examples of version expanded ASN.1

James


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

Nikos Mavrogiannopoulos
On Sat, Dec 24, 2016 at 5:13 PM, James Bottomley
<[hidden email]> wrote:

> I think, since it's a key format, the two above are the potential ones.
>  It would be TCG if they want to take it into their standard, otherwise
> PKCS is RSA Inc.

I wouldn't expect RSA inc to be involved into this as part of PKCS.
They are dead long time ago and have moved to IETF.

>>  However, I'm not sure how expandable is ASN.1 using version fields
>> (I've seen no structure being able to be re-used using a different
>> version). An alternative approach would to allow for future
>> extensions, i.e., something like the PKIX Extension field, which is
>> an OID+data.
>
> As long as the expansion fields are optional, it works nicely.  X509
> and X509v3 are examples of version expanded ASN.1

Only if they are defined in the structure early. Otherwise the early
versions of the implementations wouldn't cope with extensions. To make
it early extendable you'd have to use something lilke
TPMKey ::= SEQUENCE {
        type            OBJECT IDENTIFIER
        version         [0] IMPLICIT INTEGER OPTIONAL
        emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
        parent          [2] IMPLICIT INTEGER OPTIONAL
        publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
        privateKey      OCTET STRING
         extensions      [4]  EXPLICIT Extensions OPTIONAL
}

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

James Bottomley
On Sun, 2016-12-25 at 10:18 +0100, Nikos Mavrogiannopoulos wrote:
> On Sat, Dec 24, 2016 at 5:13 PM, James Bottomley
> <[hidden email]> wrote:
>
> > I think, since it's a key format, the two above are the potential
> > ones.  It would be TCG if they want to take it into their standard,
> > otherwise PKCS is RSA Inc.
>
> I wouldn't expect RSA inc to be involved into this as part of PKCS.
> They are dead long time ago and have moved to IETF.

I think I should give TCG first crack at wanting to own the OID.  The
IETF ones are easy: once you codify it in an RFC, the oid registry auto
extracts it.

> > >  However, I'm not sure how expandable is ASN.1 using version
> > > fields (I've seen no structure being able to be re-used using a
> > > different version). An alternative approach would to allow for
> > > future extensions, i.e., something like the PKIX Extension field,
> > > which is an OID+data.
> >
> > As long as the expansion fields are optional, it works nicely.
> >  X509 and X509v3 are examples of version expanded ASN.1
>
> Only if they are defined in the structure early. Otherwise the early
> versions of the implementations wouldn't cope with extensions. To
> make it early extendable you'd have to use something lilke
>  
> TPMKey ::= SEQUENCE {
>         type            OBJECT IDENTIFIER
>         version         [0] IMPLICIT INTEGER OPTIONAL
>         emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
>         parent          [2] IMPLICIT INTEGER OPTIONAL
>         publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
>         privateKey      OCTET STRING
>          extensions      [4]  EXPLICIT Extensions OPTIONAL
> }

Actually, that's the utility of ASN.1, once you use tagging, you don't
have to do this.  The structure above is identical to:

TPMKey ::= SEQUENCE {
        type            OBJECT IDENTIFIER
        version         [0] IMPLICIT INTEGER OPTIONAL
        emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
        parent          [2] IMPLICIT INTEGER OPTIONAL
        publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
        privateKey      OCTET STRING
 }

If tag 4 isn't present because optional tags are not coded when not
present, so you can expand any ASN.1 structure as long as you have a
clue from the version number that you should be looking for the
optional extras.  The point being I don't have to specify the expansion
now, I can wait until we need it.

I'm pretty certain the next expansion is actually SEQUENCE OF
TPM2Policy but I'm still playing with the format.

James


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

Nikos Mavrogiannopoulos
On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley
<[hidden email]> wrote:

>> TPMKey ::= SEQUENCE {
>>         type            OBJECT IDENTIFIER
>>         version         [0] IMPLICIT INTEGER OPTIONAL
>>         emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
>>         parent          [2] IMPLICIT INTEGER OPTIONAL
>>         publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
>>         privateKey      OCTET STRING
>>          extensions      [4]  EXPLICIT Extensions OPTIONAL
>> }
>
> Actually, that's the utility of ASN.1, once you use tagging, you don't
> have to do this.  The structure above is identical to:
>
> TPMKey ::= SEQUENCE {
>         type            OBJECT IDENTIFIER
>         version         [0] IMPLICIT INTEGER OPTIONAL
>         emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
>         parent          [2] IMPLICIT INTEGER OPTIONAL
>         publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
>         privateKey      OCTET STRING
>  }
>
> If tag 4 isn't present because optional tags are not coded when not
> present, so you can expand any ASN.1 structure as long as you have a
> clue from the version number that you should be looking for the
> optional extras.  The point being I don't have to specify the expansion
> now, I can wait until we need it.

How would that work for example if you want to add an additional field
with information on the type of the key for example (key usage)? You
would add the tag 4 as you say, and then all the previous parsers
written with the initial description will fail parsing the new
structure. X.509 (==PKIX) is only expandable via the extensions field
which is already defined. If you add a field to it, no parser would be
able to read the certificate.

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

James Bottomley
On Sun, 2016-12-25 at 22:08 +0100, Nikos Mavrogiannopoulos wrote:

> On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley
> <[hidden email]> wrote:
> > > TPMKey ::= SEQUENCE {
> > >         type            OBJECT IDENTIFIER
> > >         version         [0] IMPLICIT INTEGER OPTIONAL
> > >         emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
> > >         parent          [2] IMPLICIT INTEGER OPTIONAL
> > >         publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
> > >         privateKey      OCTET STRING
> > >          extensions      [4]  EXPLICIT Extensions OPTIONAL
> > > }
> >
> > Actually, that's the utility of ASN.1, once you use tagging, you
> > don't have to do this.  The structure above is identical to:
> >
> > TPMKey ::= SEQUENCE {
> >         type            OBJECT IDENTIFIER
> >         version         [0] IMPLICIT INTEGER OPTIONAL
> >         emptyAuth       [1] IMPLICIT BOOLEAN OPTIONAL
> >         parent          [2] IMPLICIT INTEGER OPTIONAL
> >         publicKey       [3] IMPLICIT OCTET STRING OPTIONAL
> >         privateKey      OCTET STRING
> >  }
> >
> > If tag 4 isn't present because optional tags are not coded when not
> > present, so you can expand any ASN.1 structure as long as you have
> > a clue from the version number that you should be looking for the
> > optional extras.  The point being I don't have to specify the
> > expansion now, I can wait until we need it.
>
> How would that work for example if you want to add an additional
> field with information on the type of the key for example (key
> usage)? You would add the tag 4 as you say, and then all the previous
> parsers written with the initial description will fail parsing the
> new structure. X.509 (==PKIX) is only expandable via the extensions
> field which is already defined. If you add a field to it, no parser
> would be able to read the certificate.

Um, well, you only want backwards compatibility, you don't really want
forward compatibility.  Assuming something extends the structure and
adds version v2, why would it matter that an old v1 application can't
read a v2 structure because it doesn't understand the tag 4?  Even if
it could it can't make use of the extra fields and something nasty will
happen.  What you want is that the new v2 application can parse both
the v2 structure and the old v1 one, but it's advantageous that a v1
application fails with a v2 structure because it prevents cockups.

James


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

Nikos Mavrogiannopoulos-2
I'd like both backwards and forward compatibility actually, exactly like x509. If an informational field is added like the key usage that I mentioned, I doubt you'd like all the previous consumers incompatible. For other extensions which make the structure totally incompatible you can use the critical flag. Anyway even the original struct is OK, it is exactly like any other key structs we have.

On December 26, 2016 12:47:32 AM GMT+01:00, James Bottomley <[hidden email]> wrote:
On Sun, 2016-12-25 at 22:08 +0100, Nikos Mavrogiannopoulos wrote:
On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley
<[hidden email]> wrote:
TPMKey ::= SEQUENCE {
type OBJECT IDENTIFIER
version [0] IMPLICIT INTEGER OPTIONAL
emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL
parent [2] IMPLICIT INTEGER OPTIONAL
publicKey [3] IMPLICIT OCTET STRING OPTIONAL
privateKey OCTET STRING
extensions [4] EXPLICIT Extensions OPTIONAL
}

Actually, that's the utility of ASN.1, once you use tagging, you
don't have to do this. The structure above is identical to:

TPMKey ::= SEQUENCE {
type OBJECT IDENTIFIER
version [0] IMPLICIT INTEGER OPTIONAL
emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL
parent [2] IMPLICIT INTEGER OPTIONAL
publicKey [3] IMPLICIT OCTET STRING OPTIONAL
privateKey OCTET STRING
}

If tag 4 isn't present because optional tags are not coded when not
present, so you can expand any ASN.1 structure as long as you have
a clue from the version number that you should be looking for the
optional extras. The point being I don't have to specify the
expansion now, I can wait until we need it.

How would that work for example if you want to add an additional
field with information on the type of the key for example (key
usage)? You would add the tag 4 as you say, and then all the previous
parsers written with the initial description will fail parsing the
new structure. X.509 (==PKIX) is only expandable via the extensions
field which is already defined. If you add a field to it, no parser
would be able to read the certificate.

Um, well, you only want backwards compatibility, you don't really want
forward compatibility. Assuming something extends the structure and
adds version v2, why would it matter that an old v1 application can't
read a v2 structure because it doesn't understand the tag 4? Even if
it could it can't make use of the extra fields and something nasty will
happen. What you want is that the new v2 application can parse both
the v2 structure and the old v1 one, but it's advantageous that a v1
application fails with a v2 structure because it prevents cockups.

James


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

James Bottomley
On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote:
> I'd like both backwards and forward compatibility actually, exactly
> like x509. If an informational field is added like the key usage that
> I mentioned, I doubt you'd like all the previous consumers
> incompatible.

OK, so there's a fundamental difference between a v3 X509 certificate
and a TPM key: An X509 certificate is a signature over a set of v1 TBS
data, a public key and a bundle of attributes.  To verify the
certificate or extract the key, you don't need to know what the
attributes are, so you can still "use" the certificate in that form.
 However, you can't get the v1 tool to obey the v3 constraints on the
certificate because it doesn't understand them.

The ASN.1 description of a TPM key contains the actual binary
representation of the key plus a set of information which explains to
the consuming code how to use the key.  Since I can't think of a way of
making use of the key without understanding all of the information
about how to use it, I think it is beneficial that v1 consumers don't
try to use v2 key information because the resulting failure will excite
the TPM's dictionary attack protection.

I gave an example of one such extension: policy authorisations, but
they're definitely of the "if you don't understand these, you can't use
the key" variety.  Perhaps if you can give an example of a potentially
compatible extensions it would help me to see your point and give us a
means of moving forwards.

Thanks,

James

>  For other extensions which make the structure totally incompatible
> you can use the critical flag. Anyway even the original struct is OK,
> it is exactly like any other key structs we have.


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

Nikos Mavrogiannopoulos-2
My comment was on the claim of extendability of the format which as I explained it is simply not true. As for example I already gave the key usage extension. I am fine however with a non extendable format as you proposed.

On December 26, 2016 7:13:40 PM GMT+01:00, James Bottomley <[hidden email]> wrote:
On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote:
I'd like both backwards and forward compatibility actually, exactly
like x509. If an informational field is added like the key usage that
I mentioned, I doubt you'd like all the previous consumers
incompatible.

OK, so there's a fundamental difference between a v3 X509 certificate
and a TPM key: An X509 certificate is a signature over a set of v1 TBS
data, a public key and a bundle of attributes. To verify the
certificate or extract the key, you don't need to know what the
attributes are, so you can still "use" the certificate in that form.
However, you can't get the v1 tool to obey the v3 constraints on the
certificate because it doesn't understand them.

The ASN.1 description of a TPM key contains the actual binary
representation of the key plus a set of information which explains to
the consuming code how to use the key. Since I can't think of a way of
making use of the key without understanding all of the information
about how to use it, I think it is beneficial that v1 consumers don't
try to use v2 key information because the resulting failure will excite
the TPM's dictionary attack protection.

I gave an example of one such extension: policy authorisations, but
they're definitely of the "if you don't understand these, you can't use
the key" variety. Perhaps if you can give an example of a potentially
compatible extensions it would help me to see your point and give us a
means of moving forwards.

Thanks,

James

For other extensions which make the structure totally incompatible
you can use the critical flag. Anyway even the original struct is OK,
it is exactly like any other key structs we have.


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

James Bottomley
On Mon, 2016-12-26 at 21:13 +0100, Nikos Mavrogianopoulos wrote:
> My comment was on the claim of extendability of the format which as I
> explained it is simply not true. As for example I already gave the
> key usage extension. I am fine however with a non extendable format
> as you proposed.

OK, so I think the version is now superfluous, since if anything gets
added it can be recognised by the tag and things not ready to parse
that tag can reject it.

That makes the final form

 TPMKey ::= SEQUENCE {
        type OBJECT IDENTIFIER
        emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL
        parent [1] EXPLICIT INTEGER OPTIONAL
        pubkey [2] EXPLICIT OCTET STRING OPTIONAL
        privkey OCTET STRING
 }

I'll code the v2 patch using this form.

James

> On December 26, 2016 7:13:40 PM GMT+01:00, James Bottomley <
> [hidden email]> wrote:
> > On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote:
> > > I'd like both backwards and forward compatibility actually,
> > > exactly
> > > like x509. If an informational field is added like the key usage
> > > that
> > > I mentioned, I doubt you'd like all the previous consumers
> > > incompatible.
> >
> > OK, so there's a fundamental difference between a v3 X509
> > certificate
> > and a TPM key: An X509 certificate is a signature over a set of v1
> > TBS
> > data, a public key and a bundle of attributes.  To verify the
> > certificate or extract the key, you don't need to know what the
> > attributes are, so you can still "use" the certificate in that
> > form.
> > However, you can't get the v1 tool to obey the v3 constraints on
> > the
> > certificate because it doesn't understand them.
> >
> > The ASN.1 description of a TPM key contains the actual binary
> > representation of the key plus a set of information which explains
> > to
> > the consuming code how to use the key.  Since I can't think of a
> > way of
> > making use of the key without understanding all of the information
> > about how to use it, I think it is beneficial that v1 consumers
> > don't
> > try to use v2 key information because the resulting failure will
> > excite
> > the TPM's dictionary attack protection.
> >
> > I gave an example of one such extension: policy authorisations, but
> > they're definitely of the "if you don't understand these, you can't
> > use
> > the key" variety.  Perhaps if you can give an example of a
> > potentially
> > compatible extensions it would help me to see your point and give
> > us a
> > means of moving forwards.
> >
> > Thanks,
> >
> > James
> >
> > >  For other extensions which make the structure totally
> > > incompatible
> > > you can use the critical flag. Anyway even the original struct is
> > > OK,
> > > it is exactly like any other key structs we have.
>


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Loading...