Re: [openssl-dev] [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 {
typeOBJECT 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 <
> james.bottom...@hansenpartnership.com> 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

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

[Erwann Abalea]

Bonjour,

> Le 25 déc. 2016 à 19:44, James Bottomley 
>  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
>>  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 {
>>typeOBJECT 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 {
>typeOBJECT 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

Re: [openssl-dev] [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

Re: [openssl-dev] [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
>  wrote:
> > > TPMKey ::= SEQUENCE {
> > > typeOBJECT 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 {
> > typeOBJECT 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

Re: [openssl-dev] [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
>  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 {
> typeOBJECT 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 {
typeOBJECT 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

Re: [openssl-dev] [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
>  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