Sacred Working Group N. Kapidzic-Cicovic Internet Draft Entegrity Solutions Document: draft-ietf-sacred-pkienrollinfo-00.txt Expires: December 2001 June 2001 PKI Enrollment Information Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/lid-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Comments or suggestions for improvement may be made on the "ietf- sacred" mailing list, or directly to the author. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document describes the format of PKI enrollment information, which may be used by an RA/CA to enable automated end entity certification. The PKI enrollment information contains PKI parameters describing RA/CA certification policy requirements put on end entities during their enrollment for a public key certificate. 1. End Entity PKI Enrollment End entities represent all users of PKI (individuals or software processes), who are issued public key certificates. The process of issuing a certificate for an end entity is known as end-entity PKI enrollment. Certificates are issued by a Certification Authority (CA), with or without the interaction of a Registration Authority (RA) [RFC2510]. An end entity PKI enrollment can be initiated at the RA/CA or at the end entity (EE). Kapidzic-Cicovic 1 INTERNET DRAFT PKI Enrollment Information June 2001 When PKI enrollment is initiated at the RA or CA, the end entity eventually gets a token containing a private key and the corresponding certificate as issued by the CA. After receiving the token, the EE is capable of performing authenticated signing operations (e.g., S/MIME or SSL) without any further interaction with the RA/CA. The drawback of this solution is that non- repudiation of signatures cannot be guaranteed since the keys are generated by the RA/CA. Alternatively, PKI enrollment can be initiated by the end entity and the enrollment process can be performed with or without the human interaction. An example of an end entity initiated PKI enrollment is a browser-based enrollment with the RA/CA providing HTML forms, requiring human interaction to populate the fields and complete the enrollment. This draft proposes a solution for performing automated end entity PKI enrollment (without requiring human intervention). The automated end entity PKI enrollment is based on the assumption that the RA/CA configuration information is made available to the end entity prior to the initiation of the enrollment, and that the end entity is in possession of client software capable of interpreting the configuration information. With this solution keys are being generated by the end entity, and non-repudiation is thus provided for. When there is a need for using multiple keys for different key usage (dual keys), with RA/CA generation and optionally backup of encipherment keys, then a mixed model can be used. The RA/CA is creating a token for an end entity with encipherment private key and corresponding certificate, and PKI enrollment information. After receiving the token, the end entity is able to initiate automated PKI enrollment for signature keys. The PKI enrollment information can alternatively be used by the RA/CA to make its PKI parameters publicly available to end entities (and RAs) wishing to communicate with the RA/CA. This communication can involve more than just the initial PKI enrollment e.g., key update, certificate update, certificate revocation, etc. Depending on the type of PKI enrollment information, it can contain only general RA/CA configuration information and be made publicly available to everyone, or it can be tailored with each end entityÆs individual data and thus required to be available only for the particular end entity. In the former case, the PKI enrollment data may be placed at the RAÆs or CAÆs web page, and in the latter case it should be distributed to the EE in a secure way. The PKI enrollment information may be stored on the end entityÆs token in the Personal Security Environment (PSE) and handed to the end entity prior to PKI enrollment. PKCS#15 token format could be extended to define a placeholder for the PKI enrollment information [PKCS#15]. Kapidzic-Cicovic 2 INTERNET DRAFT PKI Enrollment Information June 2001 The format of the end entity token and its location after PKI enrollment (e.g., at a credential server) is not covered by this draft document. 2. PKI Enrollment Information A PKI enrollment structure is composed of general RA/CA parameters and optionally individual end entity parameters: PKI_EnrollmentInfo ::= SEQUENCE { generalParameters PKI_GeneralParameters, eeIndividualParameters PKI_EEIndividualParameters OPTIONAL } The fully automated end entity initiated PKI enrollment can be achieved only if the information required for authentication of the end entity is contained in the PKI enrollment information (eeIndividualParameters). Otherwise, some human intervention is still required during the enrollment in order to achieve authentication. 2.1 PKI Enrollment Information - General Parameters PKI enrollment information general parameters structure contains a version number and several optional RA/CA parameters. Their detailed description is given in sections 2.1.1 to 2.1.7. PKI_GeneralParameters ::= SEQUENCE { Version [0] EXPLICIT Version DEFAULT v1, cAResponderAddress [1] PKI_Entity OPTIONAL, rAResponderAddress [2] PKI_Entity OPTIONAL, -- either rA or parentCA should be present pkiProtocol [3] SEQUENCE OF -- all supported by RA/CA PKI_Protocol OPTIONAL, popMethod [4] SEQUENCE OF -- all supported by RA/CA PKI_POP OPTIONAL, certTemplate [5] CertTemplate OPTIONAL, -- the presence of a part of CertTemplate means that the -- RA/CA accepts this part to be populated by the EE -- (the actual value is not important) keyGenerators [6] SEQUENCE OF -- as required by RA/CA KeyGenerator OPTIONAL, minKeySize [7] SEQUENCE OF -- as required by RA/CA KeySizeRequirement OPTIONAL, maxKeySize [8] SEQUENCE OF -- as required by RA/CA KeySizeRequirement OPTIONAL, keyTypes [9] SEQUENCE OF -- all supported by RA/CA KeyTypeRequirement OPTIONAL } 2.1.1 Responder Address Kapidzic-Cicovic 3 INTERNET DRAFT PKI Enrollment Information June 2001 The responder address parameter specifies the address of the RA/CA responder where certification requests and other PKI messages are to be sent for processing by the RA/CA. The address is to be provided as a uniformResourceIdentifier choice of GeneralName [RFC2459], thus specifying the transport protocol as well as the address of the responder (e.g. "http://www.myCA.com/responder"); PKI_Entity ::= SEQUENCE { name [0] Name OPTIONAL, -- EE, RA or CA DN altNames [1] GeneralNames OPTIONAL -- e.g., e-mail for EE, -- URL or IP of the RA/CA } -- either one of name and altNames or both must be present GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralName ::= CHOICE { otherName [0] OtherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER} 2.1.2 PKI Protocol There are a number of existing standards for PKI enrollment. The most usually used ones are PKCS #10 certification requests [PKCS10] with PKCS #7 certification responses [PKCS7], PKIX CMP [RFC2510] and PKIX CMC [RFC2797]. The RA/CA may use this parameter to express its preferred PKI protocol for end entities to use when enrolling for certificates. PKI_Protocol ::= ENUMERATED { PKIX_CMPv1 (0), -- RFC 2510 PKIX_CMPv2 (1), -- 2510 bis PKCS10_PKCS7 (2), PKIX_CMC (3) -- RFC 2797 } 2.1.3 POP Method There are different ways for an end entity to supply proof of possession of the private key corresponding to the public key contained in the certification request. This parameter specifies the private key proof-of-possession method as required by the CA [RFC2511]. PKI_POP ::= ENUMERATED { ImplicitPOP (0), ExplicitPOP (1) Kapidzic-Cicovic 4 INTERNET DRAFT PKI Enrollment Information June 2001 } 2.1.4 Certificate Template The CA certification policy dictates which fields of the end entity certificate are to be populated. For some certificate fields it is the end entity that should provide the value in the certification request (e.g., key usage, subject alternative name, etc.). The certificate template parameter provides a way for the CA to specify which fields in the certificate request template are required to be populated by the end entity. For example, the certificate template parameter may contain the following fields: - Subject DN (to be present in the request or not), - Subject alternative names (e.g., e-mail), - Key usage, - Extended key usage, - Other extensions (e.g., private). The encoding of the certificate template parameter is as CertTemplate specified in [RFC2511]. The presence of a field in the certificate template means that its value is to be provided by an end entity in the certification request. The actual value that is encoded in the certificate template of the PKI enrollment info is to be ignored. 2.1.5 Key Generators The CA certification policy may require certain type of keys to be generated at the RA or CA, e.g., encipherment keys for backup purposes. Some other types of keys should preferably be generated by the end-entity, e.g., signature keys in order to provide for non- repudiation. Alternatively encipherment keys may be generated at the end entity side and sent to the RA/CA for backup purposes. An RA/CA may use the parameter Key Generators in order to provide this information about its certification policy to end entities. PKI_EntityType ::= ENUMERATED { EE (0), RA (1), CA (2) } KeyGenerator ::= SEQUENCE { keyUsage KeyUsage, -- only one value at a time entityType PKI_EntityType, -- RA, CA or EE backupRequired BOOLEAN DEFAULT FALSE -- if TRUE and keys generated by EE, -- the private key MUST be sent Kapidzic-Cicovic 5 INTERNET DRAFT PKI Enrollment Information June 2001 -- to RA/CA for backup } 2.1.6 Supported Key Sizes The RA/CA may specify the minimal key size that is acceptable for a specific key usage according to the CA certification policy. Furthermore, the RA/CA may have an upper limit on the length of the key it is capable of handling. The KeySizeRequirement structure may be used to provide this information to end entities. KeySizeRequirement ::= SEQUENCE { keyUsage KeyUsage, -- only one value at a time size INTEGER -- bit size of the key } 2.1.7 Supported Key Types The RA/CA may be capable of handling only certain key algorithm types for a specific key usage, e.g. only DSA keys for digital signature and only Diffie-Hellman keys for key agreement (alternatively, only RSA key type for all key usages). The KeyTypeRequirement structure may be used to provide this type of information to end entities. KeyTypeRequirement ::= SEQUENCE { keyUsage KeyUsage, -- only one value at a time keyType OBJECT IDENTIFIER -- algorithm identifier } 2.2 PKI Enrollment Information - End Entity Individual Parameters The individual end entity parameters are to be encoded in PKI_EEIndividualParameters structure. PKI_EEIndividualParameters ::= SEQUENCE { endEntityNamingInfo PKI_Entity, sharedSecret BIT STRING OPTIONAL } The RA/CA policy may be such that it requires end entities to populate certification requests with the same DN and alternative names as registered at the RA/CA. If this is the case, end entity naming info parameter may be used to provide this information to each end entity in the RA/CAÆs domain. In order to provide authenticity of the initial EE certification requests, the RA/CA usually share a secret with each end entity. The shared secret parameter may be used to communicate this information to end entities. 3. Security Considerations Kapidzic-Cicovic 6 INTERNET DRAFT PKI Enrollment Information June 2001 The PKI Enrollment Information needs to be provided to end entities in secure way only if it contains end entity individual data required for authentication of the end entity during certification. In case that these parameters are not included in the PKI Enrollment Information, no extra security measures need to be taken. 4. References [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax v1.5", RFC 2315, October 1997. [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax v1.5", RFC 2314, October 1997. [PKCS15] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS 15)", RSA Data Security Inc., Redwood City, California, June 2000 Release. [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. [RFC2510] Adams, C., Farrell, S., "Internet X.509 Public Key Infrastructure: Certificate Management Protocols", RFC 2510, March 1999 [RFC2511] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet X.509 Certificate Request Message Format", RFC 2511, March 1999. [RFC2797] Myers, M., Liu, X., Schaad, J., Weinstein, J. "Certificate Management Messages over CMS", RFC 2797, April 2000 5. AuthorÆs Address Nada Kapidzic Cicovic Entegrity Solutions 164 74 Kista Sweden Phone: +46 8 477 77 37 EMail: nada@entegrity.com Appendix A: ASN.1 Module using 1988 Syntax PKIEnr??? {iso(1) ... ???} DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS Version, KeyUsage, Name, GeneralNames FROM PKIX1Explicit88 {iso(1) identified-organization(3) Kapidzic-Cicovic 7 INTERNET DRAFT PKI Enrollment Information June 2001 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}} CertTemplate FROM PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}} -- Locally defined OIDs -- PKI_Entity ::= SEQUENCE { name [0] Name OPTIONAL, -- EE, RA or CA DN altNames [1] GeneralNames OPTIONAL -- e.g., e-mail for EE, -- URL or IP of the RA/CA } -- either one of name and altNames or both must be present PKI_EntityType ::= ENUMERATED { EE (0), RA (1), CA (2) } PKI_Protocol ::= ENUMERATED { PKIX_CMPv1 (0), -- RFC 2510 PKIX_CMPv2 (1), -- 2510 bis PKCS10_PKCS7 (2), PKIX_CMC (3) } PKI_POP ::= ENUMERATED { ImplicitPOP (0), ExplicitPOP (1) } KeyGenerator ::= SEQUENCE { keyUsage KeyUsage, -- only one value at a time entityType PKI_EntityType, -- RA, CA or EE backupRequired BOOLEAN DEFAULT FALSE -- if TRUE and keys generated by EE, -- the private key MUST be sent -- to RA/CA for backup } KeySizeRequirement ::= SEQUENCE { keyUsage KeyUsage, -- only one value at a time size INTEGER -- bit size of the key } KeyTypeRequirement ::= SEQUENCE { keyUsage KeyUsage, -- only one value at a time keyType OBJECT IDENTIFIER -- algorithm identifier } Kapidzic-Cicovic 8 INTERNET DRAFT PKI Enrollment Information June 2001 PKI_GeneralParameters ::= SEQUENCE { Version [0] EXPLICIT Version DEFAULT v1, cAResponderAddress [1] PKI_Entity OPTIONAL, rAResponderAddress [2] PKI_Entity OPTIONAL, -- either rA or parentCA should be present pkiProtocol [3] SEQUENCE OF -- all supported by RA/CA PKI_Protocol OPTIONAL, popMethod [4] SEQUENCE OF -- all supported by RA/CA PKI_POP OPTIONAL, certTemplate [5] CertTemplate OPTIONAL, -- the presence of a part of CertTemplate means that the -- RA/CA accepts this part to be populated by the EE -- (the actual value is not important) keyGenerators [6] SEQUENCE OF -- as required by RA/CA KeyGenerator OPTIONAL, minKeySize [7] SEQUENCE OF -- as required by RA/CA KeySizeRequirement OPTIONAL, maxKeySize [8] SEQUENCE OF -- as required by RA/CA KeySizeRequirement OPTIONAL, keyTypes [9] SEQUENCE OF -- all supported by RA/CA KeyTypeRequirement OPTIONAL } PKI_EEIndividualParameters ::= SEQUENCE { endEntityNamingInfo PKI_Entity, sharedSecret BIT STRING OPTIONAL } PKI_EnrollmentInfo ::= SEQUENCE { generalParameters PKI_GeneralParameters, eeIndividualParameters PKI_EEIndividualParameters OPTIONAL } Kapidzic-Cicovic 9