Re: ASN.1 Name joys

[tgindin@xxxxxxxxxx]

     My own suggestions are:

1 -  Include all imported objects with dependencies other than Universal
types.
2 -  Include a table with the Universal tags for string types and times.
3 -  Include EXPLICIT or IMPLICIT on every context-specific tag.  This is
not done primarily to deter the unnecessary use of context-specific tags,
although it may well have that effect.
4 -  If it is thought that #1 and #3 involve copyright problems, require
that every import statement include a note as to whether the objects
defined by that import are implicitly or explicitly typed.  This is an
inferior alternative to #1 and #3.

     I realize that my suggestion in #3 directly contradicts X.680:94
section F.2.12.5, but since that section is not an integral part of the
standard and it is followed immediately by F.2.12.6, which appears to
believe that context-specific tags can be avoided in SET's and CHOICE's by
adding new elements to the end, I don't have to assume that the section
author's views are any more valid than my own.

          Tom Gindin

Robert Moskowitz <rgm-sec@htt-consult.com> on 05/05/2000 04:00:23 PM

To:   ietf-pkix@imc.org
cc:
Subject:  ASN.1 Name joys



I have just completed a 3 day CMP2000 interop workshop (email me if you
wish to participate in the next one 1st week in June).

In the days preceeding and during we yet again had vendors experiencing
ASN.1 coding problems with Name.

I have had threads as follows:

=============================================================

now I have examined the problem [with your ir] in more detail: Our Code
has problems with the field 'subject' [5] in the CertTemplate: The subject
is a NAME and the default for tagging in the CertTemplate SEQUENCE
is IMPLICIT.

Now the problem is, that the NAME  is a CHOICE and for a CHOICE
it is not allowed to use IMPLICIT tagging (see the ASN.1 specification).
So, in the case of  NAME one has to use an EXPLICIT tagging.

=============================================================

Then I get others like:

=============================================================

my interpretation of the PKIHeader->sender/recipient field was
as follows:

both sender and recipient are defined to be of type GeneralName...

      PKIHeader ::= SEQUENCE {
          pvno                INTEGER     { ietf-version2 (1) },
          sender              GeneralName,
          -- identifies the sender
          recipient           GeneralName,
          -- identifies the intended recipient
          messageTime     [0] GeneralizedTime         OPTIONAL,
          <snip>

which is defined in the IMPORTS as:  FROM PKIX1Implicit88

which is defined in RFC-2459 as:

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

therefore it should be tagged as IMPLICIT
and, it can be any number of underlying structures.

so, a Name, although a SEQUENCE by definition, would be implicitly tagged
as [4] { SET{}  SET{} ... }, not SEQUENCE { SET{}  SET{} ... }

otherwise, the underlying name type would not be so easily determined.

=============================================================

As you might imagine, it is challenging to work on CMP interoperablity when
there are questions about 2459 conformance.

Not everyone will be (or want to be) ASN.1 war heros.

What can we do with 2459bis to stop the flow of coding errors????

Do we need an informational RFC giving ASN.1 coding rules so that people do
not have to get the X. whatever???

Robert Moskowitz
ICSA
Security Interest EMail: rgm-sec@htt-consult.com