Bonjour,
> Le 25 déc. 2016 à 19:44, James Bottomley
> <james.bottom...@hansenpartnership.com> 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
>> <james.bottom...@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.
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
