[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The definition of OtherName in 3280bis differs with X.509?




It is true that an INSTANCE OF <DefinedObjectClass> is equivalent to
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
    type-id     <DefinedObjectClass>.&id,
    value        [0] EXPLICIT <DefinedObjectClass>.&Type
}
 
Therefore, if the "AnotherName" type is, as claimed, defined to replace
the "INSTANCE OF OTHER NAME" type, its syntax should be:
 
AnotherName ::= [UNIVERSAL 8] IMPLICIT SEQUENCE
{
    type-id      OBJECT IDENTIFIER,
    value        [0] EXPLICIT ANY DEFINED BY type-id
}
 
(Note that in RFC 2459, 3280 and 3280bis, the text wrongly claims
that "AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER".
The reason why the statement is wrong is that OTHER-NAME
is an information object class while AnotherName is a data type, and
a data type can not replace an information object class.
The correct way of saying that should be "AnotherName replaces
INSTANCE OF OTHER-NAME", because "INSTANCE OF OTHER-NAME"
is a data type.)
 
However, to my knowledge of ASN.1, since the default tagging mode of the
PKIX1Implicit88 module is "IMPLICIT TAGS", the DER encoding will be the
same with or without the "[UNIVERSAL 8] IMPLICIT" tagging precede the
SEQUENCE type. The reason is that the outer implicit tag (i.e., the tag [0]
precedes the "AnotherName" type in the GeneralName type) will always
overwrite the inner tag no matter the inner tag is an "[UNIVERSAL 8] IMPLICIT
SEQUENCE" or  simply a "SEQUENCE".
 
My conclusion to this issue is that even the syntax is inconsistent between
PKIX and ITU-T X.509, it is luckly that their DER encodings will still be the
same.
 
Nevertheless, one thing we should note is that the "AnotherName" type should
not be used alone without any implicit tag precede, otherwise it will result
inconsistent DER encoding with ITU-T X.509. For example, if someday we
define a type named "ListOfAnotherNames" as the following:
 
ListOfAnotherNames ::= SEQUENCE OF AnotherName
 
With our current definition of the "AnotherName" type, the DER encoding
of an "AnotherName" value will different with the case where it is defined
as the following:
 
ListOfAnotherNames ::= SEQUENCE OF INSTANCE OF OTHER-NAME
 
So, now the question is "do we need to change the syntax of AnotherName
to be syntactically aligned with ITU-T X.509?"
 
Wen-Cheng Wang
----- Original Message -----
To: 赵 敏
Cc: pkix
Sent: Thursday, November 09, 2006 3:01 AM
Subject: Re: The definition of OtherName in 3280bis differs with X.509?

I do not understand ASN.1 well enough to answer the question below, but someone else on the PKIX mail list may be able to respond.

I can say, however, that the ASN.1 for OtherName in 3280bis is the same as the ASN.1 for OtherName in RFC 2459 (January 1999) and RFC 3280 (April 2002), so if it in an error it is a very old error.

Dave


-------- Original Message --------
Subject: The difinition of OtherName in 3280bis differs with X.509?
Date: Wed, 08 Nov 2006 14:23:38 +0800
From: 赵 敏 <qzzm@xxxxxxxxxxx>
To: david.cooper@xxxxxxxx


Hello David:
   In rfc3280bis,Setion 4.2.1.6:
OtherName ::= SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
    Setion A.2
-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

AnotherName ::= SEQUENCE {
    type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }

But in X.509(2005),Setion 4.2.1.6:
GeneralName ::= CHOICE {
 otherName [0] INSTANCE OF OTHER-NAME, 
 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 }
OTHER-NAME ::= TYPE-IDENTIFIER
In X.681(2002),Annex A:
A.2 The TYPE-IDENTIFIER information object class is defined as:
TYPE-IDENTIFIER ::= CLASS
{
 &id OBJECT IDENTIFIER UNIQUE,
 &Type
}
WITH SYNTAX {&Type IDENTIFIED BY &id}
X.681(2002),Annex C The instance-of type:
C.7 The associated sequence type shall be:
SEQUENCE
{
 type-id <DefinedObjectClass>.&id,
 value [0] <DefinedObjectClass>.&Type
}
where "<DefinedObjectClass>" is replaced by the particular 
"DefinedObjectClass" used in the "InstanceOfType" notation.

So,INSTANCE OF OTHER-NAME associated sequence type shall be:
OtherName ::= SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
But,this is associated sequence type,not the encoding rules.The definition 
of BER/DER is in X690.
In X690(2002),Setion 8.16 Encoding of an instance-of value
8.16.1 The encoding of the instance-of type shall be the BER encoding of 
the following
sequence type with the value as specified in 8.16.2:
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
  type-id <DefinedObjectClass>.&id,
  value [0] EXPLICIT <DefinedObjectClass>.&Type
}
where "<DefinedObjectClass>" is replaced by the particular 
"DefinedObjectClass" used in the
"InstanceOfType" notation.
  So,I think the definition of OtherName in the '88 ASN.1 syntax should 
be:
OtherName ::= [UNIVERSAL 8] IMPLICIT SEQUENCE {
   type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }
  
  Because the tag of otherName is IMPLICIT,the encode value of GeneralName 
in rfc3280bis is identical of X.509.

                          
                   zhaomin