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

James Bottomley James.Bottomley at HansenPartnership.com
Sun Dec 25 19:44:51 CET 2016


On Sun, 2016-12-25 at 10:18 +0100, Nikos Mavrogiannopoulos wrote:
> On Sat, Dec 24, 2016 at 5:13 PM, James Bottomley
> <James.Bottomley at hansenpartnership.com> 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




More information about the Gnutls-devel mailing list