home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pkix-ipki-kea-00.txt < prev    next >
Text File  |  1997-08-06  |  10KB  |  301 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. PKIX Working Group                                   R. Housley (SPYRUS)
  8. Internet Draft                                            W. Polk (NIST)
  9. expires in six months                                       July 30 1997
  10.  
  11.  
  12.                    Internet Public Key Infrastructure
  13.  
  14.          Representation of Key Exchange Algorithm (KEA) Keys in
  15.             Internet Public Key Infrastructure Certificates
  16.  
  17.                    <draft-ietf-pkix-ipki-kea-00.txt>
  18.  
  19.  
  20. Status of this Memo
  21.  
  22.    This document is an Internet-Draft.  Internet-Drafts are working
  23.    documents of the Internet Engineering Task Force (IETF), its areas,
  24.    and its working groups.  Note that other groups may also distribute
  25.    working documents as Internet-Drafts.
  26.  
  27.    Internet-Drafts are draft documents valid for a maximum of six months
  28.    and may be updated, replaced, or obsoleted by other documents at any
  29.    time.  It is inappropriate to use Internet- Drafts as reference
  30.    material or to cite them other than as "work in progress."
  31.  
  32.    To learn the current status of any Internet-Draft, please check the
  33.    "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
  34.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  35.    munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or
  36.    ftp.isi.edu (US West Coast).
  37.  
  38.  
  39. Abstract
  40.  
  41.    This is the initial draft of a profile for specification of Key
  42.    Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure
  43.    X.509 certificates. Please send comments on this document to the
  44.    ietf-pkix@tandem.com mail list.
  45.  
  46.  
  47. 1  Executive Summary
  48.  
  49.    This specification contains guidance on the use of the Internet
  50.    Public Key Infrastructure certificates to convey Key Exchange
  51.    Algorithm (KEA) keys. This specification is an addendum to RFC xxxx,
  52.    "Internet Public Key Infrastructure Using X.509 Certificates:  Part
  53.    1, Certificate and CRL Profile". Implementations of this
  54.    specification must also conform to RFC xxxx. Implementations of this
  55.  
  56.  
  57.  
  58. Housley & Polk                                                  [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. INTERNET DRAFT                                              July 30 1997
  65.  
  66.  
  67.    specification are not required to conform to other parts from that
  68.    series.
  69.  
  70.    The Key Exchange Algorithm (KEA) is a classified algorithm for
  71.    exchanging keys.  This specification profiles the format and
  72.    semantics of fields in X.509 V3 certificates containing KEA keys. The
  73.    specification addresses the subjectPublicKeyInfo field and the
  74.    keyUsage extension.
  75.  
  76. 2  Requirements and Assumptions
  77.  
  78.    The goal is to augment the X.509 certificate profile presented in
  79.    Part 1 to facilitate the management of KEA keys for those communities
  80.    which use this algorithm.
  81.  
  82. 2.1  Communication and Topology
  83.  
  84.    This profile, as presented in Part 1 and augmented by this
  85.    specification, supports users without high bandwidth, real-time IP
  86.    connectivity, or high connection availablity.  In addition, the
  87.    profile allows for the presence of firewall or other filtered
  88.    communication.
  89.  
  90.    This profile does not assume the deployment of an X.500 Directory
  91.    system.  The profile does not prohibit the use of an X.500 Directory,
  92.    but other means of distributing certificates and certificate
  93.    revocation lists (CRLs) are supported.
  94.  
  95. 2.2  Acceptability Criteria
  96.  
  97.    The goal of the Internet Public Key Infrastructure (PKI) is to meet
  98.    the needs of deterministic, automated identification, authentication,
  99.    access control, and authorization functions. Support for these
  100.    services determines the attributes contained in the certificate as
  101.    well as the ancillary control information in the certificate such as
  102.    policy data and certification path constraints.
  103.  
  104.    The goal of this document is to profile KEA certificates, specifying
  105.    the contants and semantics of attributes which were not fully
  106.    specified by Part 1.  If not specifically addressed by this document,
  107.    the contents and semantics of the fields and extensions must be as
  108.    described in Part 1.
  109.  
  110. 2.3  User Expectations
  111.  
  112.    Users of the Internet PKI are people and processes who use client
  113.    software and are the subjects named in certificates.  These uses
  114.    include readers and writers of electronic mail, the clients for WWW
  115.  
  116.  
  117.  
  118. Housley & Polk                                                  [Page 2]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. INTERNET DRAFT                                              July 30 1997
  125.  
  126.  
  127.    browsers, WWW servers, and the key manager for IPSEC within a router.
  128.    This profile recognizes the limitations of the platforms these users
  129.    employ and the sophistication/attentiveness of the users themselves.
  130.    This manifests itself in minimal user configuration responsibility
  131.    (e.g., root keys, rules), explicit platform usage constraints within
  132.    the certificate, certification path constraints which shield the user
  133.    from many malicious actions, and applications which sensibly automate
  134.    validation functions.
  135.  
  136. 2.4  Administrator Expectations
  137.  
  138.    As with users, the Internet PKI profile is structured to support the
  139.    individuals who generally operate Certification Authorities (CAs).
  140.    Providing administrators with unbounded choices increases the chances
  141.    that a subtle CA administrator mistake will result in broad
  142.    compromise or unnecessarily limit interoperability.  This profile
  143.    defines the object identifiers and data formats that must be
  144.    supported to intepret KEA public keys.
  145.  
  146. 3  KEA Algorithm Support
  147.  
  148.    This section describes object identifiers and data formats which may
  149.    be used with PKIX certicate profile to describe X.509 certificates
  150.    containing a KEA public key.  Conforming CAs are required to use the
  151.    object identifiers and data formats when issuing KEA certificates.
  152.    Conforming applications shall recognize the object identifiers and
  153.    process the data formats when processing such certificates.
  154.  
  155. 3.1  Subject Public Key Info
  156.  
  157.    The certificate identifies the KEA algorithm, conveys optional
  158.    parameters, and specifies the KEA public key in the
  159.    subjectPublicKeyInfo field. The subjectPublicKeyInfo field is a
  160.    SEQUENCE of an algorithm identifier and the subjectPublicKey field.
  161.  
  162.    The certificate indicates the algorithm through an algorithm
  163.    identifier.  This algorithm identifier consists of an OID and
  164.    optional associated parameters.  Section 3.1.1 identifies the
  165.    preferred OID and parameters for the KEA algorithm.  Conforming CAs
  166.    shall use the identified OID when issuing certificates containing
  167.    public keys for the KEA algorithm. Conforming applications supporting
  168.    the KEA algorithm shall, at a minimum, recognize the OID identified
  169.    in section 3.1.1.
  170.  
  171.    The certificate conveys the KEA public key through the
  172.    subjectPublicKey field.  This subjectPublicKey field is a BIT STRING.
  173.    Section 3.1.2 specifies the method for encoding a KEA public key as a
  174.    BIT STRING.  Conforming CAs shall encode the KEA public key as
  175.  
  176.  
  177.  
  178. Housley & Polk                                                  [Page 3]
  179.  
  180.  
  181.  
  182.  
  183.  
  184. INTERNET DRAFT                                              July 30 1997
  185.  
  186.  
  187.    described in Section 3.1.2 when issuing certificates containing
  188.    public keys for the KEA algorithm. Conforming applications supporting
  189.    the KEA algorithm shall decode the subjectPublicKey as described in
  190.    section 3.1.2 when the algorithm identifier is the one presented in
  191.    3.1.1.
  192.  
  193. 3.1.1 Algorithm Identifier and Parameters
  194.  
  195.    The Key Exchange Algorithm (KEA) is a classified algorithm for
  196.    exchanging keys.  A KEA "pairwise key" may be generated between two
  197.    users if their KEA public keys were generated with the same KEA
  198.    parameters.  The KEA parameters are not included in a certificate;
  199.    instead a "domain identifier" is supplied in the parameters field.
  200.  
  201.    When the subjectPublicKeyInfo field contains a KEA key, the algorithm
  202.    identifier and parameters shall be as defined in [sdn.701r]:
  203.  
  204.       id-keyEncryptionAlgorithm  OBJECT IDENTIFIER   ::=
  205.              { 2 16 840 1 101 2 1 1 22 }
  206.  
  207.       KEA-Parms-Id     ::= OCTET STRING
  208.  
  209.  
  210.    The Kea-Parms-Id shall always appear when the subjectPublicKeyInfo
  211.    field algorithm identifier is id-keyEncryptionAlgorithm. Kea-Parms-Id
  212.    is the "domain identifier" and is ten octets in length. If the Kea-
  213.    Parms-Id of two KEA keys are equivalent, the subjects possess the
  214.    same KEA parameter values and may exchange keys.
  215.  
  216. 3.1.2 Encoding of KEA Public Keys
  217.  
  218.    A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
  219.    such that the most significant bit (MSB) of y becomes the MSB of the
  220.    BIT STRING value field and the least significant bit (LSB) of y
  221.    becomes the LSB of the BIT STRING value field.  This results in the
  222.    following encoding: BIT STRING tag, BIT STRING length, 0 (indicating
  223.    that there are zero unused bits in the final octet of y), BIT STRING
  224.    value field including y.
  225.  
  226. 3.2 Key Usage Extension in KEA certificates
  227.  
  228. The key usage extension may optionally appear in a KEA certificate.  If
  229. a KEA certificate includes the keyUsage extension, only the following
  230. values may be asserted:
  231.  
  232.       keyAgreement;
  233.       encipherOnly; and
  234.       decipherOnly.
  235.  
  236.  
  237.  
  238. Housley & Polk                                                  [Page 4]
  239.  
  240.  
  241.  
  242.  
  243.  
  244. INTERNET DRAFT                                              July 30 1997
  245.  
  246.  
  247.    The encipherOnly and decipherOnly values may only be asserted if the
  248.    keyAgreement value is also asserted.  At most one of encipherOnly and
  249.    decipherOnly shall be asserted in keyUsage extension.
  250.  
  251.    References
  252.  
  253.  
  254.    [SDN.701R] SDN.701, "Message Security Protocol", Revision 4.0
  255.               1996-06-07 with "Corrections to Message Security Protocol,
  256.               SDN.701, Rev 4.0, 96-06-07." August 30, 1996.
  257.  
  258.  
  259. Patent Statements
  260.  
  261.    This specification references classified public key encryption
  262.    technology for provisioning key exchange services.
  263.  
  264. Security Considerations
  265.  
  266.    This entire memo is about security mechanisms.
  267.  
  268. Author Addresses:
  269.  
  270.    Russell Housley
  271.    SPYRUS
  272.    PO Box 1198
  273.    Herndon, VA 20172
  274.    USA
  275.    housley@spyrus.com
  276.  
  277.    Tim Polk
  278.    NIST
  279.    Building 820, Room 426
  280.    Gaithersburg, MD 20899
  281.    USA
  282.    wpolk@nist.gov
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298. Housley & Polk                                                  [Page 5]
  299.  
  300.  
  301.