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

[jsp@xxxxxxxxxxxxx (John Pawling)]

Tim, Dean and friends,

One of Dean's comments was that the PKIX Part 1 ASN.1 module does not
include a definition for PresentationAddress.  The 1988 X.411 specification
(which specifies the ORAddress definition used in PKIX Part 1) imports the
syntax for PresentationAddress from the 1988 Recommendation X.520 which
defines it as follow

PresentationAddress ::= SEQUENCE {
	pSelector		[0]	OCTET STRING OPTIONAL,
	sSelector		[1]	OCTET STRING OPTIONAL,
	tSelector		[2]	OCTET STRING OPTIONAL,
	nAddresses		[3]	SET SIZE (1..MAX)  OF  OCTET STRING}

The X.520 ASN.1 module (entitled SelectedAttributeTypes {joint-iso-ccitt
ds(5) module(1) selectedAttributeTypes(5)}) does NOT include "DEFINITIONS
IMPLICIT TAGS ::=", so the context-specific flags are explicit.  Since the
PKIX Part 1 ASN.1 module begins with "DEFINITIONS IMPLICIT TAGS ::=",
recommend that the following definition should be added to the PKIX Part 1
ASN.1 module:

PresentationAddress ::= SEQUENCE {
	pSelector		[0] EXPLICIT OCTET STRING OPTIONAL,
	sSelector		[1] EXPLICIT OCTET STRING OPTIONAL,
	tSelector		[2] EXPLICIT OCTET STRING OPTIONAL,
	nAddresses		[3] EXPLICIT SET SIZE (1..MAX)  OF  OCTET STRING}

- John


At 11:31 AM 5/27/97 -0400, Tim Polk wrote:
>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