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

From: "David A. Cooper" <[email-masked]>
Date: Wed, 08 Nov 2006 11:01:12 -0800

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:

赵 敏 <[email-masked]>

To:

[email-masked]

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

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 9 Nov 2006 13:41:59 +0800

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 ----- 
  From: David A. Cooper 
  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:  赵 敏 <[email-masked]> 
        To:  [email-masked] 

Hello David:

  

                   zhaomin

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 10 Nov 2006 15:35:39 +0100

X509 does not define a type OtherName.
it uses : otherName [0] INSTANCE OF OTHER-NAME,

This gives indeed the same encoding as in the PKIX texts.
In order to be closer to X509, one could have used

otherName [0] SEQUENCE {

If someone uses OtherName in another contexts (without tags) this
cannot be in conflict with X.509, since OtherName does not exist.

David A. Cooper wrote:
> 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
>
>
> Subject: 	The difinition of OtherName in 3280bis differs with X.509?
> From: 	赵 敏 <[email-masked]> <mailto:[email-masked]>
> To: 	[email-masked] <mailto:[email-masked]>
>
>
>
> Hello David:

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 14 Nov 2006 15:34:59 +0100

In RFC 4043 there seems to be a bug. 

The spec uses ATTRIBUTE instead of OTHER-NAME.  i.e. shouldn't this be:

permanentIdentifier OTHER-NAME ::= {PermanentIdentifier IDENTIFIED BY
id-on-permanentIdentifier}

and OTHER-NAME imported