ASN.1 SET type restrictions

Question

I'm confused about the limitations on the ASN.1 SET type. In general, I realize that a SET type is basically the same as a SEQUENCE, except the order of the components doesn't matter.

The seminal book on ASN.1, "ASN.1 — Communication Between Heterogeneous Systems" by Olivier Dubuisson, has this to say about SETs:

If the component order of the SEQUENCE type does not matter, the key- word SET is used for modeling such a non-ordered structure:

 Description ::= SET {    
   surname IA5String,   
   first-name IA5String,  
   age INTEGER  }

In this case, the application can provide the components to the encoder in the best order for it.

What I immediately notice here is that in Dubuisson's example, the SET has two IA5String types in it. This seems to contradict what I've read here in this tutorial, which explicitly says that:

The type and value notations for SET are similar to SEQUENCE, except that the type of each component must be distinct from all others and the values can be in any order.

So how can a SET legally have two IA5String types? I'm inclined to trust Olivier Dubuisson's book over some random Internet tutorial, however, it doesn't make any sense that a SET type could have multiple components of the same type. The reason is that, in ASN.1, type identifiers aren't encoded, (at least for most common encodings like BER) so the decoder would have no way of knowing which component the IA5String applies to - is it surname or firstname? There's no way to tell if the ordering doesn't matter.

So did Olivier Dubuisson make a huge mistake here? (He also doesn't mention anywhere in his lengthy description of SET types anything about the fact that a SET can't have more than one of each type.)

Answer 1

If there are two components with the same type in a SET, they can indeed not be distinguished. The example can still be correct provided it appears in a module with automatic tagging.

Answer 2

The standard (X.680, 27.3) requires that the types of the components of a SET type all have different tags.

The "Description" type in the example violates this requirement if the enclosing ASN.1 module has IMPLICIT TAGS or EXPLICIT TAGS (because the types of the components surname and first-name have the same tag "universal 22"), but it is legal if the enclosing ASN.1 module has AUTOMATIC TAGS (because the types of those components now have different tags--"context-specific 0" and "context-specific 1", respectively--automatically assigned to them in replacement of the "universal 22" tags).