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]
