On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley <[email protected]> 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 ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ TrouSerS-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/trousers-tech
