Subject: FW: PKIX: String representation of GeneralName

From: "Amit Kapoor" <[email-masked]>
Date: Fri, 5 Nov 1999 12:50:52 -0800

And here I thought I was doing the right thing by signing my
	messages...:-)
	All right...(and before Peter Gutman responds ;-)), I am sending
	the message again.

-----------------------------

Hi James,

	You are right, in that there is a standardized string representation for
	any ASN.1 object.  However here are our reasons for not using it, and
	I believe your examples demonstrate the same:

1.	It is not user readable as in the IPAddress.  I think it will be a wee
	bit difficult for someone
	to translate the hex form to the standard and more friendly dotted form.
2.	DN name representation. (BTW, thanks to Tom Gindin@IBM, we have changed
	to RFC 2253 for UTF8 support)

	Instead of trying to mix and match two separate schemes, we tried to come
	up with one single scenario.   We also added "intuitive format" as one of
	the goals upfront.  You have also proposed the same to some extent, and
what
	we are disagreeing on is which is more "intuitive".

	regards

Amit

--------------------------------------------------------------------------
-----------------------------------------------

Amit,

There is already a standardized string representation of GeneralName
values.  It is ASN.1 value notation.  As stated in the X.680 summary,
ASN.1 provides "a notation .. for specifying values of these [ASN.1]
types".  Almost all specifications defining ASN.1 types also use value
notation to define some values, e.g. object identifier values, version
values, default values, algorithm identifier values etc.

Below are the examples from your draft in value notation:

	rfc822Name:"[email-masked]"

	dNSName:"gandalf.trustpoint.com"

	uniformResourceIdentifier:"http://www.trustpoint.com/"

	iPAddress:'C0A8000A'H

	registeredId:{ 1 2 3 4 5 6 }

Value notation looks very similar to the notation in draft-generalname.txt
for most general name choices.  The major exception is directory name.  A
directory name has such a rich syntax (an ordered collection of levels,
each with 1 or more values, each value with an arbitrary type) that it is
always going to be awkward to devise a human-friendly notation for all
possible values.  So it is probably reasonable to use RFC 1779 [DN] for
this choice:

	directoryName:CN=Amit Kapoor, O=Trustpoint, L=Mountain View,
ST=California, C=US

Your labels (e.g. "mail", "ip") may seem easier than the value notation
labels (e.g. "rfc822Name", "iPAddress") but the later match precisely &
obviously to fields in the type definition.  You get value notation for
free whenever a new ASN.1 type is defined.  Value notation offers a
notation for all the GeneralName choices (e.g. otherName), not just the 6
your draft lists.  Value notation offers a notation for all possible
values (e.g. values with unusual or unprintable characters).  It is likely
that anyone wanting a text representation for GeneralName values today
will want a text representation for values of another ASN.1 type tomorrow
so value notation, which works for all ASN.1 types, is preferable.

----------
From: 	Amit Kapoor[SMTP:[email-masked]]
Sent: 	Tuesday, 2 November 1999 9:34
To: 	PKIX
Subject: 	String representation of GeneralName

a draft to document a string representation of GeneralName

	http://www.trustpoint.com/draft-generalname.txt

-----------------------------------------------------
Certificate Authority: http://www.smeme.com
CA root : http://www.smeme.com/faq_operational.html#16
-----------------------------------------------------