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

[Nikos Mavrogianopoulos]

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 <James.Bottomley at HansenPartnership.com> wrote:
>On Sun, 2016-12-25 at 22:08 +0100, Nikos Mavrogiannopoulos wrote:
>> On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley
>> <James.Bottomley at hansenpartnership.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161226/e1e533ce/attachment-0001.html>