On Tue, 2010-10-26 at 08:54 -0500, Douglas E. Engert wrote:
>
> On 10/25/2010 11:19 PM, Andre Zepezauer wrote:
> > Hello,
> >
> > anyone with good knowledge of ASN.1 out there? The point is, that in my
> > opinion the current encoding of TokenInfo.lastUpdate is wrong. It is of
> > type CHOICE and therefore EXPLICIT tagging has to be used. CHOICE is
> > always tagged EXPLICIT. Correct?
Correction:
***A tagged CHOICE within a ComponentList*** is always tagged
EXPLICIT?!? See example MyType below:
> I am no ASN.1 expert, but the "A Layman's Guide to a Subset of ASN.1, BER and
> DER"
> (From RSA 1993) Google for this, as there are a number of sources.
>
> 5.5 CHOICE
> The CHOICE type denotes a union of one or more alternatives.
>
> The types must have distinct tags. This requirement is typically satisfied
> with explicit or implicit tagging on some of the alternatives.
>
> An example could be the ECDSA/ECDH parameters (RFC 3279, PKCS#11:
>
> EcpkParameters ::= CHOICE {
> ecParameters ECParameters,
> namedCurve OBJECT IDENTIFIER,
> implicitlyCA NULL }
>
>
> From PKCS#11 v2.30"
> The CKA_EC_PARAMS or CKA_ECDSA_PARAMS attribute value is known as the
> “EC domain parameters” and is defined in ANSI X9.62 as a choice of three
> parameter
> representation methods with the following syntax:
> Parameters ::= CHOICE {
> ecParameters ECParameters,
> namedCurve CURVES.&id({CurveNames}),
> implicitlyCA NULL
> }
>
> The tags are distinct, so implicit tagging can be used.
That's correct for the definition of a CHOICE. But if a ChoiceType is
used as a component of a SEQUENCE, then things are different:
MyType ::= SEQUENCE {
paramFirst Parameters OPTIONAL,
paramSecond [0] Parameters OPTIONAL
}
EXPLICIT tagging:
30 04 A0 02 05 00
IMPLICIT tagging:
30 02 80 00 -- information on type is lost
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
