Subject: Re: ASN.1 , Constructed Encoding

From: [email-masked]
Date: Mon, 3 Apr 2000 10:51:59 -0400

The 0x20 bit of the tag byte (or the tag first byte when the tag value
is 31 or above) means "constructed".  Thus a constructed IA5 string will
have an outer tag of 0x36 and an inner tag of 0x16, a constructed octet
string will have an outer tag of 0x24 and an inner tag of 0x04, and a
constructed bit string with definition [2] IMPLICIT BIT STRING would have
an outer tag of 0xA2 and an inner tag of 0x03 while a primitive with that
definition would have a tag of 0x82.
     Maybe somebody else can answer you about word delimiters, since I'm
not sure what you mean.  An IA5String can contain many different non-text
characters which you could interpret as word delimiters, including space,
period (which is in your example), and many more.

          Tom Gindin

"chandrasekaran natarajan" <[email-masked]> on 04/03/2000
10:11:36 AM

Please respond to [email-masked]

To:   [email-masked]
cc:
Subject:  ASN.1 , Constructied Encoding

hello,

can any one clear my doubts regarding ASN.1 constructed encoding . Its as
follows

Given a IA5String  value "[email-masked]" and constructed
encoding as

36 13
     16 05 74 65 73 74 31
     16 01 40
     16 07 72 73 61 2e 63 6f 6d

can some one let me know how the first entry 36 is
got ? Is it a Implementor Defined Tag or has it been
Standardised for IA5Strings with Constructed encoding.

And also please let me know  If there is any delimeter for
words apart from @.

Thanks

chandar

---

From: Hans Schupp <[email-masked]>
Date: Mon, 03 Apr 2000 17:08:09 +0200

[email-masked] wrote

>      The 0x20 bit of the tag byte (or the tag first byte when the
> tag value is 31 or above) means "constructed".  Thus a constructed
> IA5 string will have an outer tag of 0x36 and an inner tag of 0x16,

Wrong.
At least if one sticks to X.690, where the encoding of ASN.1 character
strings is defined. There it says, that each character string is encoded
as if it were defined [UNIVERSAL x] IMPLICIT OCTET STRING
This results in the inner tag being 0x04!

> a constructed octet string will have an outer tag of 0x24 and an
> inner tag of 0x04, and a constructed bit string with definition
> [2] IMPLICIT BIT STRING would have an outer tag of 0xA2 and an inner
> tag of 0x03 while a primitive with that definition would have a tag
> of 0x82.

Correct. :-)

Given the above argument, this encoding is not correct. It should be
36 13
      04 05 74 65 73 74 31
      04 01 40
      04 07 72 73 61 2e 63 6f 6d

> And also please let me know  If there is any delimeter for

The '@' character is no delimiter here. The string can be divided at
arbitrary places (i.e. the character at this position doesn't mean
anything).
Logically, the whole thing is still one string, it is only the encoding,
that is split into several parts.

Hope it helps,
Hans Schupp

---

From: "Darren Harter" <[email-masked]>
Date: Mon, 3 Apr 2000 16:51:49 +0100

Hans,

[UNIVERSAL X] IMPLICIT OCTET STRING always gets a tag encoded as (in binary)
001X XXXX where XXXXX is the X in the [UNIVERSAL X].  The IMPLICIT keywords
forces the encoding of OCTET STRING, but not its tag.  So in the case of
IA5String, it is indeed 0x36 when constructed (or part of an explicit
encoding) and 0x16 when not constructed (and not part of an explicit
encoding).

If the definition was IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
instead of IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING you would get
the following:

36 1B 04 19
		36 07 04 05 test1
		36 03 04 01 @
		36 09 04 07 rsa.com

Because it is IMPLICIT the three contained strings fall back to their
default (unconstructed) tags on 0x16, but the outer (constructed) tag stays
a 0x36.  The explicit OCTET STRING tags of 0x04 disappear in this case.

The original poster's encoding was correct as

36 13
	16 05 test1
	16 01 @
	16 07 rsa.com

You are correct in that the only leagal X.690 encoding of this is in a
single non-constructed IA5String with the following encoding:

16 0D [email-masked]

Hope this all helps,

Darren

---------------------------------------------------------------------
Darren Harter B.Sc. (Hons) MBCS CEng
European Professional Services Group,
Entegrity Solutions Corp.

Tel:	+44 (0) 1452 371383
Fax:	+44 (0) 1452 371384
Cell:	+44 (0) 7801 812850

Mail: <mailto:[email-masked]>
Web: <http://www.entegrity.com>

---------------------------------------------------------------------
Visit us on Stand No 654 at Infosecurity 2000 and enter our
FREE competition to WIN A HALF CASE OF CHAMPAGNE!

11-13 April in the National Hall, Olympia Exhibition Centre, London
---------------------------------------------------------------------

-----Original Message-----
From: Hans Schupp [mailto:[email-masked]]
Sent: 03 April 2000 16:08
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: ASN.1 , Constructed Encoding

[email-masked] wrote

Wrong.

Correct. :-)

Hope it helps,
Hans Schupp

---

From: Hans Schupp <[email-masked]>
Date: Mon, 03 Apr 2000 18:35:15 +0200

Darren Harter wrote:

> The IMPLICIT keywords forces the encoding of OCTET STRING, but not
> its tag.  So in the case of IA5String, it is indeed 0x36 when
> constructed (or part of an explicit encoding) and 0x16 when not
> constructed (and not part of an explicit encoding).

Agree. But this is no contradiction to my posting.

> If the definition was 
>   IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
> instead of 
>   IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING
> you would get the following:
> 
> 36 1B 04 19
>                 36 07 04 05 test1
>                 36 03 04 01 @
>                 36 09 04 07 rsa.com

No, definitely not.
Please read carefully X.690 paragraph 8.14 ("Encoding of a tagged
value"). You will find, that the encoding of a tagged value is done by
taking the encoding of the base type (OCTET STRING in our discussion)
and adding the explicit tag in front of it.

So the example string encoded as 
  [UNIVERSAL 16] EXPLICIT OCTET STRING
becomes
  36 15 04 13
              04 05 test1
              04 01 @
              04 07 rsa.com

The respective is valid for implicit tagging: the base encoding is
modified by throwing away the original tag and using the new one instead
(while preseving the "constructed" bit).
Please have a look at paragraph 8.14.3 for exact wording.

> Because it is IMPLICIT the three contained strings fall back to
> their default (unconstructed) tags on 0x16, but the outer
> (constructed) tag stays a 0x36.  The explicit OCTET STRING tags
> of 0x04 disappear in this case.
> 

No. I still stay with my original argument.

The example we use here has great resemblance with the example used in
paragraph 8.20.6 of X.690. That one supports my point of view.

> You are correct in that the only leagal X.690 encoding of this is
> in a single non-constructed IA5String with the following encoding:
> 
> 16 0D [email-masked]

I'm sorry, if my English isn't good enough to make myself clear.
I didn't mean to say _that_, but the following:
Even though the encoding is done in three chunks (which is perfectly
valid in BER, but not in DER), the logical string that is expressed by
this encoding is the same as "[email-masked]" encoded in one chunk.

Best regards,
Hans Schupp

PS: I refer to X.690 (1994 E) aka ISO/IEC 8825-1: 1995 (E)

---

From: "Darren Harter" <[email-masked]>
Date: Tue, 4 Apr 2000 11:13:27 +0100

Hans,

No need to appologise, your English is perfectly clear.  I think we are
probably both correct but about different things, and our discussion may
have been at slightly cross perposes.  Let me try and explain.
Unfortunately, I don't have a copy of X.690 to hand here, but my
understanding is that for all standard ASN.1 types there can be three and
only three forms of encoding.  Let's take BOOLEAN as an example, go back to
first principles and gain some common ground:

Type1:	BOOLEAN

This encodes as 01 01 'DATA' where DATA is 0 for false, and non-zero for
true (always FF in DER).  Where the leading 01 is the boolean tag
([UNIVERSAL 1]) and the second 01 is the length.

Type2:	<Tag> IMPLICIT BOOLEAN

Let's consider the case where tag is [0] - i.e [0] IMPLICIT BOOLEAN.  When
the IMPLICIT keyword is present, the normal tag is replaced by the indicated
tag and the encoding in this case becomes 80 01 'DATA' where the 'DATA' and
01 have exactly the same meaning as in Type 1.

Type3:	<Tag> EXPLICIT BOOLEAN

Let's again consider the case where tag is [0] - i.e. [0] EXPLICIT BOOLEAN.
When the EXPLICIT keyword is present, the normal tag is retained in the
encoding and the indicated tag is prepended.  The encoding therefore becomes
A0 03 01 01 'DATA'.  Essentially, the original encoding from Type 1 becomes
the 'Value' part of an outer encoding.  In this case the outer tag is 'A0'
not '80' as its 'DATA' contains an ASN.1 encoding (01 01 FF) and therefore
has to be flagged as constructed.  EXPLICITly encoded types are always
flagged as constructed.

As far as I am aware, these are the rules for the 'encoding of a tagged
value'.

Following the above rules for a Type 2 definition of IA5String of [UNIVERSAL
22] IMPLICIT OCTET STRING, the normal tag for OCTET STRING (04) would not
appear in the encoding of an IA5String, but the 'DATA' part of the encoding
will be formed according to the rules for OCTET STRINGs - i.e. I arbitrary
stream of 8-bit words.

Given this, the IA5String that we are discussing is slightly strange as the
three encodings that contain the 'test1', '@', and 'rsa.com' parts
collectively form the 'DATA' part of the encoding for a single IA5String - I
think we're probably in agreement up to this point.  These parts should fall
under the specific rules for encoding the value of IA5Strings.  If the
IA5String rules state that the component parts should be encoded as OCTET
STRINGs, then you are right and 04 tags should be used for the component
parts.  However, if the rules for IA5String say that the component parts
should be encoded as IA5Strings (using the above definition), then IMHO you
are wrong, and 16 tags should be used.

In your version of the encoding we have a ASN.1 equal to:

ConstructedIA5String ::= [UNIVERSAL 22] IMPLICIT SEQUENCE OF OCTET STRING

whereas in my version we have

ConstructedIA5String ::= [UNIVERSAL 22] IMPLICIT SEQUENCE OF IA5String
IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING

With IMPLICIT exchanged for EXPLICIT in my other example.

What is important for this discussion is what the 'DATA' encoding rules for
IA5String say.

Can anybody post an appropriate paragraph from X.680/X.690 that describes
the internal 'DATA' encoding of IA5String?

Kind regards,

Darren

-----Original Message-----
From: Hans Schupp [mailto:[email-masked]]
Sent: 03 April 2000 17:35
To: Darren Harter
Cc: [email-masked]; [email-masked]
Subject: Re: ASN.1 , Constructed Encoding

No, definitely not.

Best regards,
Hans Schupp