Re: Problems w/ ASN.1 in PKIX part 1

[Tim Polk <wpolk@xxxxxxxx>]

At 01:43 PM 5/27/97 +1000, Dean Povey wrote:
>Hi all, 
>
>Sorry if this has already been discussed, but I have been running my ASN.1
>compiler across the ASN.1 source from the PKIX part 1 document and have come
>up with the following problems.
>

Dean,

This has not been discussed before; you have provided a great service! That
draft made the I-D deadline (before the Memphis meeting) by minutes, and the ASN.1 could have used a bit more attention. I did not have time to compile it before the deadline, so a few things slipped through.

On first glance, I agree with all your comments and fixes.  I have some information on EXTENSION-ATTRIBUTES:
>
>8. Apart from that my compiler also bitches about the UNIQUE keyword used in 
>the
>   definition of EXTENSION-ATTRIBUTE as in:
>
>   EXTENSION-ATTRIBUTE ::= SEQUENCE {
>      extension-attribute-type [0] INTEGER (0..ub-extension-attributes) UNIQUE,
>      extension-attribute-value [1] ANY DEFINED BY extension-attribute-type
>   }
>
>   Can anyone tell me what UNIQUE does?
>
>
UNIQUE was not in the X.208 standard, but was added in the '93 ASN.1.  I will remove the construct from the PKIX-1 ASN.1 module, so your compiler will be happy. Regarding the semantics of UNIQUE, I searched my ASN.1 docs and here is what I found.

>From ISO 8824-2/Rec. X.681,
> "The presence of the keyword "UNIQUE" specifies that this field is an identifier field. If the keyword is present, [the field may be OPTIONAL but may not have a DEFAULT value]."

In 8824-2's "Additional Definitions", identifier field is defined as:
>
> identfier field: A fixed-type value field of a class selected to provide
> unique identification of information objects in that class. Values of the 
> identifier field, if supplied, are required to be unambiguous within any 
> information object set that is defined for that class. They may, but need 
> not, serve to unambiguously identify information objects of that  class
> within some broader scope.

>	Notes

>	1 The identifier field has a fixed ASN.1 type, and values of that  type
> can be carried in the protocol to identify information objects within the
> class.
>
>	2 The scope within which the identifier is unambiguous is that of an
> information object set. It could, however, also be made unambiguous within
> any given abstract syntax, or within an entire application context, or could
> even be global across all classesand all application contexts by use of the
> object identifier type for the identifier field.

I am *not* an ASN.1 expert, but I interpret all that for EXTENSION-ATTRIBUTE as "this is an integer in the range (0..ub-extension-attributes) which has a unambiguous meaning in the context of an extension-attribute-type, and it unambiguously defines the type of the extension-attribute-value."  Finding the unambiguous meaning defined for that integer is whole new problem, of course.

I hope this is of some use.

Thanks,

Tim Polk
NIST
wpolk@nist.gov