Internet DRAFT - draft-moreau-pkix-aixcm
draft-moreau-pkix-aixcm
INTERNET DRAFT Thierry Moreau
Document: draft-moreau-pkix-aixcm-00.txt CONNOTECH
Category: Informational 6 August 2008
Expires: 7 February, 2009
Auto Issued X.509 Certificate Mechanism (AIXCM)
Status of this Memo
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The IETF Trust (2008).
IPR Disclosure Acknowledgment
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Abstract
The Transport Layer Security (TLS) protocol does not support the use
of client public key pairs without X.509 security certificates. This
document circumvents this limitation: an end-entity has access to
the public domain private key of a dummy (or "explicitly
meaningless") Certification Authority (CA), and can thus freely
issue an X.509 security certificate for interoperability purposes.
Given these workaround requirement and solution approach, the
document limits itself to the strict minimal set of standardization
provisions. This supports the orderly cohabitation of auto issued
certificates and normal TLS traffic relying on the full Public Key
Infrastructure (PKI) model.
Moreau Informational [Page 1]
Internet Draft AIXCM 6 August 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . 2
2. Rationale . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . 4
4. Normative Provisions . . . . . . . . . . . . . . . . 6
4.1 Explicit Meaningless CA Signature Key Pair . . . . . . . 6
4.1.1 Public Domain Private Key . . . . . . . . . . . 6
4.1.2 CA Distinguished Name . . . . . . . . . . . . 7
4.2 Explicit Meaningless End Entity Certificates . . . . . . 9
4.2.1 Certificate Issuance with Explicit Meaningless CA
Signature Key . . . . . . . . . . . . . . . . 10
4.2.2 Authority Key Identifier Certificate Extension . . . 10
4.2.3 No Human Readable Elements to Rely Upon . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . 12
7.1 Normative References . . . . . . . . . . . . . 12
7.2 Informative References . . . . . . . . . . . . . 12
Annex A - Prevailing Representation for Public Domain Private Key . 13
Author's Address . . . . . . . . . . . . . . . . . 13
IPR Notices . . . . . . . . . . . . . . . . . . . 13
Intellectual Property . . . . . . . . . . . . . . 13
Copyright Notice . . . . . . . . . . . . . . . . 14
Disclaimer . . . . . . . . . . . . . . . . . . 14
1. Introduction
This document pertains to a fairly simple concept, i.e. computer
application security schemes based on public key cryptography but
not using security certificates. Nowadays, public key cryptography
is mainly deployed on the Internet using the X.509 Public Key
Infrastructure (PKI) model, notably with the common web browser
support for the Transport Layer Security (TLS) protocol. As it often
arises when a seemingly simple change is envisioned for Internet
protocols, the simple idea fits the installed base only after many
adjustments for backwards compatibility with existing protocols and
interoperability with communications components not directly
impacted by the small change. There is thus an important
interoperability perspective on the subject area, while the security
perspective is unavoidable.
This document organization adheres to neither the interoperability
perspective nor the security perspective, and the coverage of the
Moreau Informational [Page 2]
Internet Draft AIXCM 6 August 2008
subject area is limited in both of them. The purpose of the present
document is to allow certificate-less (or functional substitute)
security schemes to exist in the context of IETF protocols, so the
document organization follows the editorial practice of IETF
standardization documents.
The rationale section is written to make a point, i.e. there is some
defined need for the auto issued X.509 certificate mechanism given
technical details of the TLS Internet security protocol. The
applicability statement section attempts a generic explanation of
how the proposed mechanism may be applied in security schemes
functionally equivalent to certificate-less public key cryptography.
Turning this generic explanation into a concrete scheme description
requires the replacement of generic terms with specific reference to
system components, such as determining what is an "end entity" and
what is the "relying party".
The section 4 contains a limited number of core standardization
provisions, i.e. the minimal set required for the document purpose.
The security perspective is present at varying degrees in every
sections, and a few issues not fully covered elsewhere are grouped
in the security consideration section.
The X.509 PKI technology makes use of the Abstract Syntax Notation
One (ASN.1) for structured data representation. When encoded in a
computer storage media or in a protocol frame in transit, the
Distinguished Encoding Rules (DER) often apply. The document Annex A
refers to yet another conventional data representation, Privacy
Enhanced Mail (PEM).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
2. Rationale
The TLS protocol provides no direct support for end entity public
keys that are not conveyed in X.509 security certificates. In
theory, this is not a rationale for any type of public domain
private key, including the one used for the auto issued X.509
certificate mechanism. That is, if a need arises for a
certificate-less TLS variant, such a protocol can theoretically be
designed, implemented, and deployed. Thus, the rationale for the
present document is essentially a matter of compatibility with the
TLS protocol installed base.
In this document section, specific provisions of the TLS protocol
handshake are described as an instance where the the auto issued
X.509 certificate mechanism is justified. For sake of simplicity in
this demonstration by example, we take the case where a TLS client
entity has a public key pair but no genuinely issued X.509 security
certificate, and we assume a server certificate is available and
recognized by the client.
Moreau Informational [Page 3]
Internet Draft AIXCM 6 August 2008
The TLS protocol handshake allows the client to use a public key
pair only if a) the public key counterpart it is part of a client
certificate (i.e. an X.509 end entity security certificate), and b)
a chain of digital signatures ("certification chain") can be
validated iteratively from the client certificate up to a CA public
key. Looking at the on-the-wire protocol, this limitation is found
in the two protocol handshake messages "Certificate Request" and
"Client Certificate". The former one allows the server entity to
announce either a list of trusted CAs or an indication that the
server welcomes any CA. It is thus impossible for the server to
announce at once a list of preferred CAs, if available, plus an
indication of willingness to accept a "bare public key" from the
client. A binary flag is missing in the Certificate Request message
to indicate the server willingness to accept a bare client public
key in the Client Certificate message from the client.
It has been proposed that a bare client public key might be
implemented as a client self-signed certificate, and such a solution
may be attractive if any server is dedicated to either know trusted
CAs, or client self-signed certificates, but not both. However,
self-signed certificates are traditionally associated with CA public
keys, not client public keys. The confusion that may arise extends
to the TLS server operations, where the CA public keys (in the form
of self-signed certificates) are typically grouped in a trusted
store: client self-signed certificates might mistakenly be added to
this trusted store with undesirable security and operational
impacts.
The present document defines a CA key pair to be used by client
entities for auto issuance of X.509 certificate, as a substitute to
bare public key transmission in TLS Client Certificate massages. The
defined CA name allows a TLS server to selectively invite clients to
do so, e.g. as the last entry in the list of "trusted" CAs in the
Certificate Request message (the TLS protocol prioritizes a client
certificate issued by a genuine CA occurring earlier in the list).
3. Applicability Statement
Almost since the inception of public key cryptography, secure
client-server applications could be envisioned such that client
public key pairs are validated by servers through direct access to a
trusted online database, i.e without reliance on trust information
distribution by the mechanism of PKI security certificates. It is
outside of the scope of the present document to further describe
application schemes of this type; it is sufficient to state that
such schemes may exist, e.g. in a proprietary trust arrangement
where application clients are directly registered to an
Internet-enabled e-commerce operator or an affiliate organization
having a privileged trust relationship.
In essence, the public domain private key specified in this document
allows totally unrestricted issuance of X.509 security certificates.
Moreau Informational [Page 4]
Internet Draft AIXCM 6 August 2008
Such certificates should obviously not be trusted by any relying
party - they are useful merely to achieve operational
interoperability with remote protocol implementations expecting a
properly formatted X.509 certificate. Thus there are two contributed
functionality elements: the unrestricted certificate issuance
functionality and the bare private key carrying functionality in
X.509 PKI protocols. In addition, the third party trust
dissemination functionality of genuine certificates is lost with
auto issued certificates.
The explanation for the present document applicability rests mainly
on the functionality elements mentioned in the preceding paragraph,
and much less on the specific standardization provisions. The
overall field of application is distributed application security
schemes based on public key cryptography. The emphasis on
interoperability with the installed base of protocols suggests a
reduced field of application in which public key cryptography
provides authentication services including notably session key
material authentication (i.e. leaving out of scope the stored data
confidentiality through public key encryption).
Unrestricted Certificate Issuance Functionality
An end entity (as known in the PKI model) may conveniently issue
an X.509 security certificate for a public key under its
control. There are no security restrictions or conditions for
doing so, thus the issuance operation may be embedded in any
software function, perhaps even totally transparently for the
end-user. It should be easily understood that this leaves the
end entity's private key at the focal point of operational
security concerns, form the end entity perspective (the
certificate contents becomes irrelevelant). The incompatibility
minefield of X.509 security certificate extensions is removed
from the end-entity security management hindrance (admittedly
remaining as a plain software compatibility issue). Simply
stated, if an auto issued security certificate fails to
interoperate with a given service, a fix may be sought from any
source without security concern because the certificate contents
is not relied upon in any case.
Bare Private Key Carrying Functionality
The bare public key carrying functionality may be used in lieu
of genuine X.509 security in PKI protocols, notably TLS.
Irrespective of which type of X.509 certificate is used, and
independently in each direction of transmission, an end entity
sends a certificate (with the end entity public key) to the
"relying party" at the remote end. In the case of an auto issued
certificate, the remote end merely accepts the certificate as
complying with the protocol rules but does not "rely" on the
certificate in a trust management perspective. Thus, security
considerations make the CA public key specified in the present
document special when handling successful PKI protocol
handshake. This special status is indicative of an a-priori
Moreau Informational [Page 5]
Internet Draft AIXCM 6 August 2008
untrusted end entity public key. Accordingly, local arrangements
should be made for proper signaling to the local higher layer
software that uses the PKI protocol services. E.g. the higher
layer software might inspect the certificate and independently
validate the end entity public key and access rights upon
encountering the distinguished name specified in 4.1.2 as the
issuer name in the certificate. In doing so, the end entity
public key may be used as the index value for to retrieve the
end entity identification.
Loss of Third Party Trust Dissemination Functionality
This document does not address how an application security
scheme may make up for the loss of trust evidencing
functionality afforded by genuine X.509 security certificates.
Furthermore, the security requirements of an application scheme
applying the present document should not be defined from a
reference to the PKI model. This is because the auto issued
certificate mechanism supports application security models that
are certificate-less. In these, the relying party should use
trusted services, typically online services, that provide
integrity-protected data about the public key received from the
remote entity during a protocol handshake instance.
4. Normative Provisions
This document section contains the minimal standardization
provisions deemed necessary for orderly cohabitation of network
traffic induced by the deployment of auto issued security
certificates and other network traffic, notably normal TLS protocol
traffic.
4.1 Explicit Meaningless CA Signature Key Pair
The essential parameters of an X.509 trust anchor are specified in
section 6.1.1 of [RFC5280] and sections 3.3.60 and 10.1 of [X509].
According to these, it is sufficient to define a) the trust anchor
public key, b) a digital signature algorithm indication, and c) the
exact CA name by which the public key may be referenced.
In the present context, the notion of trust anchor refers to the
public key corresponding to the public domain private key that
allows unrestricted generation of security certificates by any party
in any computing environment. Thus, the trust anchor qualification
is as meaningless as the security certificates generated in this
context; it refers only to the use of the public key for
interoperability purposes in the same role as a genuine X.509 trust
anchor public key, also known as a root or trusted CA public key.
The definition of a public domain private key in 4.1.1 implies the
required public key definition. The definition of a CA name in 4.1.2
allows referencing for interoperability purposes.
4.1.1 Public Domain Private Key
Moreau Informational [Page 6]
Internet Draft AIXCM 6 August 2008
The public domain private key specification requires the selection
of a public key cryptography algorithm. With interoperability as the
single most desirable property, a commonly supported algorithm
variant is a natural choice: the Rivest Shamir Adleman (RSA) with
the Secure Hash Algorithm (SHA-1) for signature data fingerprint
operation. Note that the specifics given below for the explicitly
meaningless CA digital signatures do not apply to end entity key
pairs, which may use any public key algorithm allowed by the present
or future X.509 PKI specifications set.
o The signature scheme with appendix specified in section 8.2 and
9.2 of [RFC3447], using the SHA-1 as the hash function selection,
SHALL apply to digital signature generation (respectively
validation) using the public domain private key (respectively the
corresponding trust anchor public key).
o The public domain private key modulus SHALL be the product of the
prime numbers
1222376585451153076906411599050410636248259576202372062268431831
9518890588681296098916306768274640829057555114121191787424630659
71878408733800761470052087
and
1148180864398197740589511601897591851836860526399786233176188891
2299732662162482850576030071809594512796078977328354967203013489
62528923420692710452088083
o The corresponding trust anchor public key SHALL have the public
exponent value 65537.
See also the Annex A giving a more convenient data representation
for the private key material.
4.1.2 CA Distinguished Name
The leftmost column in the following table defines the ASN.1 encoded
distinguished name by which the above meaningless PKI trust anchor
key may be referred. The two other columns are explanations of the
ASN.1 syntax and semantic that might be inferred from the relevant
PKI standard documents, notably [X501] for the definition of a
distinguished name and [X520] for the four components in the defined
name.
+-------------------------------+-------------+------------------------+
| Hexadecimal representation of | ASN.1 | ASN.1 prefix explana- |
| ASN.1 DER encoding | prefix | tion or textual repre- |
| | indentation | sentation of ASN.1 |
| | level | data value |
|-------------------------------|-------------|------------------------|
| 30 81 AB | 1 | SEQUENCE OF |
| | | (length=171) |
Moreau Informational [Page 7]
Internet Draft AIXCM 6 August 2008
|-------------------------------|-------------|------------------------|
| 31 0B | 2 | SET (length=11) |
|-------------------------------|-------------|------------------------|
| 30 09 | 3 | SEQUENCE OF (length=9) |
|-------------------------------|-------------|------------------------|
| 06 03 | 4 | OBJECT IDENTIFIER |
| | | (length=3) |
|-------------------------------|-------------|------------------------|
| 55 04 06 | | {2 5 4 6}, i.e. |
| | | countryName |
|-------------------------------|-------------|------------------------|
| 13 02 | 4 | PrintableString |
| | | (length=2) |
|-------------------------------|-------------|------------------------|
| 41 41 | | "AA" |
|-------------------------------|-------------|------------------------|
| 31 46 | 2 | SET (length=70) |
|-------------------------------|-------------|------------------------|
| 30 44 | 3 | SEQUENCE OF |
| | | (length=68) |
|-------------------------------|-------------|------------------------|
| 06 03 | 3 | OBJECT IDENTIFIER |
| | | (length=3) |
|-------------------------------|-------------|------------------------|
| 55 04 0A | | {2 5 4 10}, i.e. |
| | | organizationName |
|-------------------------------|-------------|------------------------|
| 13 3D | 4 | PrintableString |
| | | (length=61) |
|-------------------------------|-------------|------------------------|
| 54 68 65 20 64 75 6d 6d 79 20 | | "The dummy " |
| 6e 61 6d 65 20 58 20 72 65 66 | | "name X ref" |
| 65 72 73 20 74 6f 20 74 68 65 | | "ers to the" |
| 20 6f 70 65 6e 6c 79 20 69 6e | | " openly in" |
| 73 65 63 75 72 65 20 70 75 62 | | "secure pub" |
| 6c 69 63 20 6b 65 79 20 2e 2e | | "lic key .." |
| 2e | | "." |
|-------------------------------|-------------|------------------------|
| 31 48 | 2 | SET (length=72) |
|-------------------------------|-------------|------------------------|
| 30 46 | 3 | SEQUENCE OF |
| | | (length=70) |
|-------------------------------|-------------|------------------------|
| 06 03 | 4 | OBJECT IDENTIFIER |
| | | (length=3) |
|-------------------------------|-------------|------------------------|
| 55 04 0B | | {2 5 4 11}, i.e. |
| | | organizationalUnitName |
|-------------------------------|-------------|------------------------|
| 13 3F | 4 | PrintableString |
| | | (length=63) |
|-------------------------------|-------------|------------------------|
| 2e 2e 2e 20 6f 66 20 61 20 6e | | "... of a n" |
| 6f 6d 69 6e 61 6c 20 43 41 20 | | "ominal CA " |
Moreau Informational [Page 8]
Internet Draft AIXCM 6 August 2008
| 64 65 76 6f 69 64 20 6f 66 20 | | "devoid of " |
| 6f 62 6a 65 63 74 69 76 65 20 | | "objective " |
| 50 4b 49 20 43 41 20 63 68 61 | | "PKI CA cha" |
| 72 61 63 74 65 72 69 73 74 69 | | "racteristi" |
| 63 73 2e | | "cs." |
|-------------------------------|-------------|------------------------|
| 31 0A | 2 | SET (length=10) |
|-------------------------------|-------------|------------------------|
| 30 08 | 3 | SEQUENCE OF (length=8) |
|-------------------------------|-------------|------------------------|
| 06 03 | 4 | OBJECT IDENTIFIER |
| | | (length=3) |
|-------------------------------|-------------|------------------------|
| 55 04 03 | | {2 5 4 3}, i.e. |
| | | commonName |
|-------------------------------|-------------|------------------------|
| 13 01 | 4 | PrintableString |
| | | (length=1) |
|-------------------------------|-------------|------------------------|
| 58 | | "X" |
+-------------------------------+-------------+------------------------+
The ASN.1 encoded definition of a name is unambiguous and
representative of the protocol packet contents. However, PKI
distinguished names are often communicated in textual form more or
less compliant to the LDAP standard documents. The latter repeat and
expand the PKI technological base: distinguished names are
introduced in section 2.3.2 of [RFC4512], name components are
covered in [RFC4519] and the textual representation is introduced in
[RFC4514]. With these conventions, the distinguished name is
specified as
CN=X,OU=... of a nominal CA devoid of objective PKI CA characteristics.,
O=The dummy name X refers to the openly insecure public key ...,C=AA
Formally, this is an incomplete specification because the name
component string values might validly be encoded with ASN.1 types
other than PrintableString. Moreover, the formal listing order for
the name components is reversed from the maybe more natural top down
approach that is often used in various publications and operator
display in software products.
The presence of the nonexistent country code "AA" (freely user
assigned according to [ISO3166TABLE]) serves a dual purpose: a) to
make more explicit which of the bottom up or top down listing order
is in use, and b) to isolate the public domain private key from the
nationality of any specific organization.
4.2 Explicit Meaningless End Entity Certificates
The foremost role of a CA is to issue end entity certificates. With
the availability of a public domain CA private key, the end-entity
certificate issuance turns into a mere data formatting operation
which must comply with applicable X.509 rules. There are thus very
Moreau Informational [Page 9]
Internet Draft AIXCM 6 August 2008
few additional standardization provisions in the subsections below.
4.2.1 Certificate Issuance with Explicit Meaningless CA Signature Key
Implementations claiming compliance to the present specification
MUST NOT issue security certificates having the root CA
distinguished name specified in 4.1.2 as the issuer name and a
digital signature using a private key other than the one specified
in 4.1.1.
Conversely, implementations claiming compliance to the present
specification MUST NOT issue security certificates digitally signed
using the private key specified in 4.1.1 and not having the root CA
distinguished name specified in 4.1.2 as the issuer name.
4.2.2 Authority Key Identifier Certificate Extension
Security certificates digitally signed using the private key
specified in 4.1.1 and having the root CA distinguished name
specified in 4.1.2 as the issuer name MUST include the authority key
identifier certificate extension value using the first method
indicated in section 4.2.1.2 of [RFC5280] (the authority key
identifier extension itself is defined in section 4.2.1.1.in the
same reference). This establishes the key identifier value shown in
the leftmost column in the table below from the SHA-1 hash
fingerprint of the ASN.1 encoded RSA public key.
+-------------------------------+-------------+------------------------+
| Hexadecimal representation of | ASN.1 | ASN.1 prefix expla- |
| ASN.1 DER encoding | prefix | nation or explana- |
| | indentation | tion of ASN.1 data |
| | level | value |
|-------------------------------|-------------|------------------------|
| 30 16 | 1 | SEQUENCE OF |
| | | (length=22) |
|-------------------------------|-------------|------------------------|
| 80 14 | 2 | CONTEXT defined type 0 |
| | | (length=20) |
|-------------------------------|-------------|------------------------|
| b0 05 f3 b7 e4 34 9e e6 b3 8a | | <public key |
| 85 80 a2 60 c6 56 94 1c 6b 93 | | fingerprint> |
+-------------------------------+-------------+------------------------+
4.2.3 No Human Readable Elements to Rely Upon
Implementations claiming compliance to the present specification
SHOULD NOT put specific human readable information on which users
are expected to rely, or could rely according to the information
face value, in data elements of security certificates digitally
signed using the private key specified in 4.1.1.
5. Security Considerations
Moreau Informational [Page 10]
Internet Draft AIXCM 6 August 2008
The very idea of using auto issued X.509 security certificates
signed with a public domain private key implies a certificate-less
security model in a distributed application environment based on PKI
protocols, and the security implications should be carefully
weighted. A main area of care should be the relying party processes
that handle session data received from remote end entities having
used an auto issued certificate for session authentication purposes.
In server sites where multiple client authentication schemes may be
supported, a scheme based on auto issued certificates needs specific
processing according to local rules for client public key
validation.
Privacy protection is not a design goal for the auto issued
certificate mechanism. Nonetheless, the client data privacy aspects
include pitfalls and opportunities which should be thoroughly
studied for the deployment of any specific security scheme. For
instance, a software utility that generates an auto issued
certificate might query the local environment, maybe by requesting
input from the user, for client identification data, which can only
be detrimental to client data privacy. To the contrary, privacy
protection is slightly enhanced if the the end entity identification
is deduced from the public key value used as an index in a server's
client database. This is not a cryptography-based anonymity scheme,
but it is at least a small improvement over cleartext transmission
of a full featured X.509 security certificate.
In a sense, the PKI technology is centered on name management, i.e.
its basic function is to ascertain the link between a public key and
an entity name. The foremost X.509 entity name construction and
encoding rules are those of "distinguished names" defined in [X501].
As further detailed in the informative annex J of the reference
[X501], distinguished names are intended to be human readable and
preferably user friendly. The distinguished names of explicit
meaningless security certificates specified herein are required
mainly for interoperability purposes, but can not be hidden from
humans when the normal certificate handling process exposes names in
human readable form. This creates subtle interactions with social
engineering vulnerabilities. It has been determined that the
distinguished names should not carry any user warning messages which
might be misread as originating from an accountable organization.
Specifically:
- the distinguished names should not refer to any organization or
entity,
- the distinguished names should not refer to any specific
application use of the present scheme,
- the distinguished names should not convey any guidance to the
user for to avoid misleading use of digital signatures using a
public domain private key, and
- the distinguished names should not refer to the possible
misleading use of digital signatures using a public domain
private key.
These principles are reflected in this document subsections 4.1.2
and 4.2.3.
Moreau Informational [Page 11]
Internet Draft AIXCM 6 August 2008
6. IANA Considerations
This document has no actions for IANA.
7. References
7.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", IETF Network Working Group, RFC 2119, March 1997
[RFC3447] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography, Specifications Version 2.1", IETF
Network Working Group, RFC 3447, February 2003
[RFC5280] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W.
Polk, "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", IETF Network
Working Group, RFC 5280, May 2008
[X501] International Telecommunication Union, "Information technology -
Open Systems Interconnection - The Directory: Models", ITU-T
Recommendation X.501, August 2005
[X509] International Telecommunication Union, "Information technology -
Open Systems Interconnection - The Directory: Public-key and
attribute certificate frameworks", ITU-T Recommendation X.509,
August 2005
[X520] International Telecommunication Union, "Information technology -
Open Systems Interconnection - The Directory: Selected attribute
types", ITU-T Recommendation X.520, August 2005
7.2 Informative References
[ISO3166TABLE] ISO 3166 Maintenance agency (ISO 3166/MA), "ISO 3166-1
decoding table",
http://www.iso.org/iso/iso-3166-1_decoding_table, visited
on June 18, 2008
[RFC4512] K. Zeilenga, "Lightweight Directory Access Protocol (LDAP):
Directory Information Models", IETF Network Working Group, RFC
4512, June 2006
[RFC4514] K. Zeilenga, editor, "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", IETF
Network Working Group, RFC 4514, June 2006
[RFC4519] A. Sciberras, editor, "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", IETF Network Working
Group, RFC 4519, June 2006
Moreau Informational [Page 12]
Internet Draft AIXCM 6 August 2008
Annex A - Prevailing Representation for Public Domain Private Key
The reference [RFC3447] (notably section A.1 in Appendix A)
specifies data representations for RSA private and public keys. The
installed base of PKI software recognizes the "PEM encoded" format
for public key material and security certificates, which facilitates
data interchange through ASCII representation of DER encoded ASN.1
data. The PEM encoding for the private key is provided below.
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDH3cqnjWsH1/LFe5tf1n+d4hdGc/kCqc0IPOZV8qUrzFJjHe31
dAnSyIgOARpG5kKSfYiV6eniMY1xiNGJ3tOdjheYjws+00dTFiAUMt77CkqfZzTQ
/L257TiPN82eoFcbCg89/H2EtwdRdIeKCoWnavfijPsEoSNbChYftm9vVQIDAQAB
AoGAeZsOCcI2xA/1a4jYsYguH58HsFsxwBgWYxPCxbqcGrj3y8zTEwwmSfSvK24q
UccZ7E2rBCPNpU2nFNQ9QditAdWk/au8rdHkPCUuTdhWnz9v4aMbLKcqenq/NTnv
reT1bz15NkSQGdsogogM50xsndT+xxrgHPQPvMBh5bixLuUCQQDpZIXcSXroqgG6
+lOmigyRXDPHB1IEgBJcxhiNEQ7oIP+j5SrhH0SYTf4ECTTnuhGChsPyjtqAvIgd
3YwmdWb3AkEA2znpXh50X+ihnfOmWaYXF3yeLwtp1SkoVh9zyjILEGvAdaCcI18i
PUf0vw82PY+ggOoZO1pTBXB7G7z2v6PNEwJBAIxFGh6XGwOSiY+yu2uwNHV4kLXh
tG13+5E+jarawbbJflsmdGrwu+09kpkiX2WV8sgb7tBtAu20YapxaLYEgWkCQAFN
+OuMdtjTQ5LzDjxeVqjXHwHcqYaRNiI9Ea1UWuiAG6cXi5ZSTJvcv8IbTxFSt3vM
6NWHlhLkNndVyoodaW0CQQCmMnn5UOhQ6SvvXvPUUjDY1bcqs5S8WvZqPO+VUQoX
1Zjc7TkTkphjuTMO3dMahX2B++xn7TfX1u2nvGy9OVEe
-----END RSA PRIVATE KEY-----
Author's Address
Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel: +1-514-385-5691
e-mail: thierry.moreau@connotech.com
IPR Notices
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
Moreau Informational [Page 13]
Internet Draft AIXCM 6 August 2008
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Copyright Notice
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Disclaimer
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Moreau Informational [Page 14]
