Internet Draft Amit Kapoor (Trustpoint)
PKIX Working Group Ronald Tschalr (Trustpoint)
Expires in 6 months
November 4, 1999
A String Representation of General Name
<draft-ietf-pkix-generalname-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2, 2000
Copyright Notice
Copyright (C)The Internet Society (1999). All Rights Reserved.
Abstract
The PKIX working group has created the GeneralName [RFC2459] to support
more name types than just the distinguished name specified by OSI.
GeneralName is encoded in ASN.1. When a GeneralName is communicated
not using a ASN.1 encoded protocol (e.g., in a configuration file), there
is a need to have a string representation of GeneralName. This document
specifies a string format for representing names, which is designed to give
a clean representation of commonly used names, whilst being able to represent
any GeneralName. This specification also recognizes that GeneralName needs
to be communicated to humans, in which case the encoding has to be user friendly
for display purposes, for e.g. on a business card or in an email message.
This is being published as a separate draft for convenience, but
probably will be merged with RFC 2459 [RFC2459].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in [RFC2119].
1. A notation for GeneralName
1.1 Goals
The following goals are laid out:
o To provide an unambiguous representation of a GeneralName
o To be an intuitive format for the majority of GeneralNames
o To be fully general, and able to represent GeneralName with
extension capability
o To give a clear representation of the contents of the
GeneralName
1.2 Informal definition
This notation is designed to be convenient for common forms of name.
Some examples are given. The author's directory distinguished name
would be written:
directory:CN=Amit Kapoor, O=Trustpoint, C=US
Or the author's mail name could be written as:
mail:ronald@trustpoint.com
The IP address for a machine could be written as:
ip:192.168.0.10
The basic structure is to provide the name type tag followed by
the string representation of the name value.
1.3 Formal definition
A formal definition can now be given. The structure is specified using
the [ABNF] grammar:
general-name = name-type ":" name-value
name-type = ALPHA *( ALPHA | DIGIT | "_" | "-" )
name-value = <any character>
The name-type is case-insensitive.
The list of valid name types and the corresponding name values
with both application and display encodings are given below:
GeneralName Name-type Name-value Application Display
---------------------------------------------------------------------
RFC822 "mail" addr-spec [RFC822] [RFC822]
Directory "directory" name [DN1] [DN2]
RegisteredId "registeredID" oid [DN1] [DN1]
DNSName "dns" hostname [URI] [URI]
URI "uri" absoluteURI [URI] [IURI]
X400Address "x400" O/R [O/R] [O/R]
OtherName "other" other-value <specified below>
EDIPartyName "edi" edi-value <specified below>
IPAddress "ip" (IPv4address [IPV6] [IPV6]
| IPv6address)
other-value = <oid [DN1]> ":" <base64 encoded ANY value>
edi-value = [ name-assigner "," ] party-name
name-assigner = "assigner" ":" directory-string
party-name = "name" ":" directory-string
; The "name" and "assigner" are case-insensitive
directory-string = *(stringchar | pair) |
QUOTATION *(quotechar | pair) QUOTATION
stringchar = <any character except one of special, "\" or
QUOTATION >
quotechar = <any character except "\" or QUOTATION >
pair = "\" ( special | "\" | QUOTATION | hexpair )
special = ","
hexpair = hexchar hexchar
hexchar = DIGIT | "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f"
QUOTATION = <ASCII double quotation mark character '"'>
Elements of GeneralName not specified in this specification SHOULD
be encoded in ASN.1 value notation form [X680].
Application encoding MUST be used when communicating the name
between applications, whereas Display encoding SHOULD be used
for human readable purposes like business cards etc. The difference
between the Application and Display encodings (if any) is that the
Application encodings use a UTF-8 encoding step; this step is not
desirable when intending a name for human consumption. Conversion
between Display and Application encoding is an implementation detail
and outside the scope of this specification.
2. Examples
This section gives a few examples of GeneralName's written
using this notation:
1. Distinguished Name
display encoding:
directory:CN=Ronald Tschalr, O=Trustpoint, C=US
application encoding:
directory:CN=Ronald Tschal\C3\A4r, O=Trustpoint, C=US
2. RFC822Mail Name
mail:amit@trustpoint.com
3. URI
uri:http://www.trustpoint.com/
4. DNS
dns:gandalf.trustpoint.com
5. IP Address
ip:191.162.20.10
6. Registered
registeredID:1.22.3456.4.58.60
3. References
[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile",
RFC 2459, January, 1999
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC822] Crocker, D., "Standard of the Format of ARPA-Internet Text
Messages", STD 11, RFC 822, University of Delaware, August, 1982.
[URI] Fielding, R., L. Masinter, T. Berners-Lee, "Uniform
Resource Identifiers: Generic Syntax", RFC 2396, August,
1998.
[IPV6] Hinden, R., S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July, 1998.
[DN1] Kille, S., Wahl, M., Howes, T., "UTF-8 String Representation of
Distinguished Names", RFC 2253, December, 1997
[DN2] Kille, S., "A String Representation of Distinguished Names"
RFC 1779, ISODE Consortium, March 1995
[IURI] Masinter, L., Duerst, M., "Internationalized Uniform Resource
Identifiers (IURI)", draft-masinter-url-i18n-04.txt, June,
1999
[O/R] Alvestrand, H., "Writing X.400 O/R Names", RFC 1685, August,
1994
[X680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", 1994.
4. Acknowledgments
We would like to thank the following individuals for their review and input:
Tom Gindin, IBM;
5. Security Considerations
Security issues are not discussed in this memo.
6. Author's Address
Amit Kapoor
Trustpoint
429 Castro Street
Suite B
Mountain View
CA - 94041
email: amit@trustpoint.com
Ronald Tschalr
Trustpoint
429 Castro Street
Suite B
Mountain View
CA - 94041
email: ronald@trustpoint.com
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.