Re: EXPLICIT vs IMPLICIT tags in ASN.1
- From: Thomas Pornin <pornin@xxxxxxxxx>
- Date: 28 May 2009 09:20:51 GMT
According to yawnmoth <terra1024@xxxxxxxxx>:
According to <http://www.larmouth.demon.co.uk/tutorials/tagging/
sld018.htm>, IMPLICIT means "you can "override the current tag". Does
that mean that, instead of subjectUniqueID being a BIT STRING that it
could be a SEQUENCE or two mandatory INTEGERs or something? If so,
why would you want to do that? And why bother saying it's a BIT
STRING when it can be arbitrarily overwritten?
When a value (e.g. a BIT STRING) is encoded into a stream of bytes, the
encoding consists of, in that order: a tag (T), a length (L), and the
value (V) itself. The length qualifies the number of bytes used by the
value. The value is encoded according to its type; for instance, a BIT
STRING is encoded as a header byte, then as many bytes as needed for the
bits (the header bytes encode how many bits are significant in the last
byte -- because a bit string may contain a non-multiple of eight number
of bits). Each value type has its own encoding rules. An UTF8String is a
value which is a sequence of Unicode code points, and it is encoded
using UTF-8. An INTEGER value is a big integer, i.e. a mathematical
beast, which is encoded using signed two's complement in big-endian.
The default tag is the one which is conventionally attached to
the type. For a BIT STRING, this is the tag of class UNIVERSAL and
numerical value 3.
When a type is specified as such:
[1] IMPLICIT BIT STRING
then this means: the value is a sequence of bits, and should be encoded
as a BIT STRING (with the header byte and so on); the tag is to be
_replaced_ with a tag of class CONTEXT and numerical value 1. From the
decoder point of view, this means: expect a tag of class CONTEXT and
value 1, and then interpret the value as an encoded string of bits (with
the header byte and so on).
When the tag is explicit, like this:
[1] EXPLICIT BIT STRING
then the tag of class CONTEXT and value 1 does not replace the tag of
BIT STRING; instead, it creates a wrapper structure, so you get a TLTLV.
You have an "outer" TLV where T is the CONTEXT:1 tag, and V is itself
a complete TLV; that inner TLV has the standard BIT STRING tag, and
its value is an encoded BIT STRING.
Technically, this:
[1] EXPLICIT BIT STRING
and this:
[1] IMPLICIT SEQUENCE { value BIT STRING }
yield the same bytes on the wire, for the same value bits.
These tag games are meant to support optional or undetermined values.
The decoder knows what to do of the incoming bytes by looking at the
tag. The default tags are fine for most usages, but imagine this:
SEQUENCE {
b1 BIT STRING OPTIONAL,
b2 BIT STRING OPTIONAL
}
and suppose that you get the bytes for a SEQUENCE with a single BIT
STRING in it. How do you know whether that string is the "b1" or the
"b2" field ? That's ambiguous. Hence, the type above is invalid.
Instead, you must write something like that:
SEQUENCE {
b1 BIT STRING OPTIONAL,
b2 [0] IMPLICIT BIT STRING OPTIONAL
}
which means that the "b1" string, if present, will use the default
tag for bit strgins (i.e. UNIVERSAL:3), which "b2" uses the defined
CONTEXT:0 tag.
Implicit tags are a somewhat misguided space optimization. An explicit
tag adds a wrapping layer, hence it uses a few more bytes. So implicit
tags are often preferred. However, since an implicit tag replaces the
specified type, it can destroy some information, so it is not allowed on
some (meta-)types such as a CHOICE and ANY.
(A "CHOICE" is a type which means "one of the following, use the tag to
know which one you got" so replacing the tag prevents further decoding.
An "ANY" is a type which means "some unspecified type, use some external
information and/or the tag to know what you got".)
It often happens that some tags are added for aesthetic reasons. For
instance, the sequence with the two optional bit strings would often be
specified as such:
SEQUENCE {
b1 [0] IMPLICIT BIT STRING OPTIONAL,
b2 [1] IMPLICIT BIT STRING OPTIONAL
}
because although only one special tag is needed, having two of them
as a more "symmetrical", "balanced" look, which many ASN.1 specification
designers find more appealing.
Conversely, backward compatibility with previous versions of the
specification is often a driving influence. For instance, imagine that
the protocol initially contained this:
SEQUENCE {
b BIT STRING
}
and that you now want to support 0, 1 or 2 bit strings instead of
always exactly one. But you also want the values encoded along the
rules of the previous protocol version to remain valid in the new
protocol, thus supported by new software. This will mean that the
new version will have to contain at least one BIT STRING with the
default tag, not an implicit tag.
(In that specific example, one could also have used:
SEQUENCE (0..2) OF BIT STRING
but that is another issue.)
--Thomas Pornin
.
- Follow-Ups:
- Re: EXPLICIT vs IMPLICIT tags in ASN.1
- From: yawnmoth
- Re: EXPLICIT vs IMPLICIT tags in ASN.1
- References:
- EXPLICIT vs IMPLICIT tags in ASN.1
- From: yawnmoth
- EXPLICIT vs IMPLICIT tags in ASN.1
- Prev by Date: Re: Breaking LFSR.
- Next by Date: Re: RC4 instead of a CBC block cipher for disk encryption?
- Previous by thread: EXPLICIT vs IMPLICIT tags in ASN.1
- Next by thread: Re: EXPLICIT vs IMPLICIT tags in ASN.1
- Index(es):
Relevant Pages
|
