Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

Richard Levitte - VMS Whacker-2
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-practice.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.

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

TPMKey ::= SEQUENCE {
       type        OBJECT IDENTIFIER -- always TCG
       version     [0] INTEGER { v1_2(0), v2(1) } DEFAULT v1_2
       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/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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/
>

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

James Bottomley
In reply to this post by 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

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Erwann Abalea-4
In reply to this post by James Bottomley
Bonjour,

> Le 25 déc. 2016 à 19:44, James Bottomley <[hidden email]> a écrit :
>
> 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.

Which OID registry are you talking about?

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

These structures can be considered identical if and only if one the following conditions is true:
 - they’re defined in a module declared with « EXTENSIBILITY IMPLIED »
 - they both include the extensibility marker (i.e. they’re slightly modified)

If you plan to use BER, CER or DER (and only these), then the parser MUST ignore the extensibility markers (present or not), and work as if they’re present. But that won’t change the ASN.1 definition, only the decoder behaviour.

Cordialement,
Erwann Abalea

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

James Bottomley
In reply to this post by 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.
>

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