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 | | | +-------------------------------+-------------+------------------------+ 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]