--- 1/draft-ietf-lamps-cmp-updates-04.txt 2020-09-22 08:13:43.017756492 -0700 +++ 2/draft-ietf-lamps-cmp-updates-05.txt 2020-09-22 08:13:43.109758806 -0700 @@ -1,99 +1,105 @@ LAMPS Working Group H. Brockhaus Internet-Draft Siemens -Updates: 4210, 6712 (if approved) September 8, 2020 +Updates: 4210, 6712 (if approved) September 22, 2020 Intended status: Standards Track -Expires: March 12, 2021 +Expires: March 26, 2021 CMP Updates - draft-ietf-lamps-cmp-updates-04 + draft-ietf-lamps-cmp-updates-05 Abstract This document contains a set of updates to the base syntax and transport of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210 and RFC 6712. Specifically, the CMP services updated in this document comprise the - enabling of using EnvelopedData instead of EncryptedValue, the - definition of extended key usages to identify certificates of CMP - endpoints on certification and registration authorities, and adds an - HTTP URI discovery mechanism and extend the URI structure. + enabling of using EnvelopedData instead of EncryptedValue, adding new + general message types, the definition of extended key usages to + identify certificates of CMP endpoints on certification and + registration authorities, and adds an HTTP URI discovery mechanism + and extend the URI structure. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on March 12, 2021. + This Internet-Draft will expire on March 26, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Convention and Terminology . . . . . . . . . . . . . . . 3 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) . 3 - 2.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 3 + 2.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 4 2.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 4 2.3. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 6 2.4. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 7 2.5. Update Section 5.3.4. - Certification Response . . . . . 9 - 2.6. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 9 - 2.7. Update Section 5.3.19. - PKI General Message Content . . 10 - 2.8. Update Section 5.3.22 - Polling Request and Response . . 11 - 2.9. Update Section 9 - IANA Considerations . . . . . . . . . 12 - 2.10. Update Appendix B - The Use of Revocation Passphrase . . 13 - 2.11. Update Appendix C - Request Message Behavioral - Clarifications . . . . . . . . . . . . . . . . . . . . . 13 - 2.12. Update Appendix D.4. - Initial Registration/Certification - (Basic Authenticated Scheme) . . . . . . . . . . . . . . 14 + 2.6. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 9 + 2.7. Update Section 5.3.19.3. - Encryption/Key Agreement Key + Pair Types . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.8. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 10 + 2.9. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 10 + 2.10. New Section 5.3.19.15 - Root CA Certificates Update . . . 11 + 2.11. New Section 5.3.19.16 - Certificate Request Template . . 11 + 2.12. Update Section 5.3.22 - Polling Request and Response . . 12 + 2.13. Update Section 9 - IANA Considerations . . . . . . . . . 13 + 2.14. Update Appendix B - The Use of Revocation Passphrase . . 14 + 2.15. Update Appendix C - Request Message Behavioral + Clarifications . . . . . . . . . . . . . . . . . . . . . 15 + 2.16. Update Appendix D.4. - Initial Registration/Certification + (Basic Authenticated Scheme) . . . . . . . . . . . . . . 16 3. Updates to RFC 6712 - HTTP Transfer for the Certificate - Management Protocol (CMP) . . . . . . . . . . . . . . . . . . 14 - 3.1. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 14 - 3.2. New Section 3.6. - HTTP Request-URI . . . . . . . . . . . 15 - 3.3. Update Section 6. - IANA Considerations . . . . . . . . . 16 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 7.2. Informative References . . . . . . . . . . . . . . . . . 18 - Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 19 - A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 19 - A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 31 - Appendix B. History of changes . . . . . . . . . . . . . . . . . 43 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 + Management Protocol (CMP) . . . . . . . . . . . . . . . . . . 16 + 3.1. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 16 + 3.2. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 16 + 3.3. Update Section 6. - IANA Considerations . . . . . . . . . 18 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 7.2. Informative References . . . . . . . . . . . . . . . . . 20 + Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 20 + A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20 + A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 33 + Appendix B. History of changes . . . . . . . . . . . . . . . . . 45 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction While using CMP [RFC4210] in industrial and IoT environments and developing the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were identified in the original CMP specification. This document updates RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these limitations. @@ -158,20 +164,23 @@ according to RFC 4211 [RFC4211] section 2.1.9 the use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure. RFC 4211 [RFC4211] offers the EncryptedKey structure, a choice of EncryptedValue and EnvelopedData for migration to EnvelopedData. For reasons of completeness and consistency the exchange of EncryptedValue is performed for all usages in RFC 4210 [RFC4210]. This includes the protection of centrally generated private keys, encryption of certificates, and revocation passphrases. + o Adding new general message types to request CA certificates, a + root CA update, or a certificate request template. + o Extend the usage of polling also to p10cr messages. < TBD: The specification of algorithm profiles seed to be moved to a separate document. > 2.2. New Section 4.5 - Extended Key Usage The following subsection describes new extended key usages for different CMP server types specified in RFC 4210 [RFC4210]. @@ -404,86 +412,144 @@ CertOrEncCert ::= CHOICE { certificate [0] Certificate, encryptedCert [1] EncryptedKey } Add the following paragraphs to the end of the section. The use of EncryptedKey is described in section 5.2.2. -2.6. Replace Section 5.3.19.9. - Revocation Passphrase +2.6. Update Section 5.3.19.2. - Signing Key Pair Types + + The following section clarifies the usage of the Signing Key Pair + Types PKI general message on referencing EC curves. + + Insert this note at the end of Section 5.3.19.2. + + Note: In case you wish to offer several EC curves, you need to put + several id-ecPublicKey elements, one each per named curve. + +2.7. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair Types + + The following section clarifies the usage of the Encryption/Key + Agreement Key Pair Types PKI general message on referencing EC + curves. + + Insert this note at the end of Section 5.3.19.3. + + Note: In case you wish to offer several EC curves, you need to put + several id-ecPublicKey elements, one each per named curve. + +2.8. Replace Section 5.3.19.9. - Revocation Passphrase Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of a revocation passphrase for authenticating a later revocation request. This document updates the handling by using the parent structure EncryptedKey instead of EncryptedValue to transport this information as described in Section 2.1 above. Replace the text of the section with the following text. This MAY be used by the EE to send a passphrase to a CA/RA for the purpose of authenticating a later revocation request (in the case that the appropriate signing private key is no longer available to authenticate the request). See Appendix B for further details on the use of this mechanism. GenMsg: {id-it 12}, EncryptedKey GenRep: {id-it 12}, < absent > The use of EncryptedKey is described in section 5.2.2. -2.7. Update Section 5.3.19. - PKI General Message Content - - The following subsections describes IDs for new examples - InfoTypeAndValue to be used in general messages content specified in - RFC 4210 [RFC4210]. +2.9. New Section 5.3.19.14 - CA Certificates - Section 5.3.19 of RFC 4210 [RFC4210] describes various PKI general - messages and the respective OIDs. This document adds three - additional subsection to introduce the new IDs id-it-caCerts, id-it- - rootCaKeyUpdate, and id-it-certReqTemplate to the support messages as - defined in Lightweight CMP Profile - [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. + The following subsection describes the PKI general messages using id- + it-caCerts. The use is specified in in Lightweight CMP Profile [I- + D.ietf-lamps-lightweight-cmp-profile] Section 4.4. - Add these new subsections at the end of this section with the - following text. + Insert this section after Section 5.3.19.13. 2.3.19.14 CA Certificates - This MAY be used by the client to get the latest CA intermediate and issuing CA certificates. GenMsg: {id-it 17}, < absent > - GenRep: {id-it 17}, CaCertsValue | < absent > + GenRep: {id-it 17}, SEQUENCE OF CMPCertificate | < absent > + +2.10. New Section 5.3.19.15 - Root CA Certificates Update + + The following subsection describes the PKI general messages using id- + it-rootCaKeyUpdate. The use is specified in in Lightweight CMP + Profile [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. + + Insert this section after new Section 5.3.19.14. 5.3.19.15. Root CA Certificates Update This MAY be used by the client to get an update of an existing root CA Certificate. GenMsg: {id-it 18}, < absent > - GenRep: {id-it 18}, RootCaKeyUpdateValue | < absent > + GenRep: {id-it 18}, RootCaKeyUpdateContent | < absent > + + RootCaKeyUpdateContent ::= SEQUENCE { + newWithNew CMPCertificate + newWithOld [0] CMPCertificate OPTIONAL, + oldWithNew [1] CMPCertificate OPTIONAL + } Note: In contrast to CAKeyUpdAnnContent, this type offers omitting newWithOld and oldWithNew in the GenRep message, depending on the needs of the EE. +2.11. New Section 5.3.19.16 - Certificate Request Template + + The following subsection describes the PKI general messages using id- + it-certReqTemplate. The use is specified in in Lightweight CMP + Profile [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. + + Insert this section after new Section 5.3.19.15. + 5.3.19.16. Certificate Request Template This MAY be used by the client to get a template with parameters for a future certificate request operation. GenMsg: {id-it 19}, < absent > - GenRep: {id-it 19}, CertReqTemplateValue | < absent > + GenRep: {id-it 19}, CertReqTemplateContent | < absent > -2.8. Update Section 5.3.22 - Polling Request and Response + CertReqTemplateContent ::= SEQUENCE { + certTemplate CertTemplate, + controls Controls OPTIONAL + } + + Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue + + id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } + AlgIdCtrl ::= AlgorithmIdentifier + + id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } + RsaKeyLenCtrl ::= Integer + + < TBD: The OIDs TBD3 and TBD4 have to be registered at IANA. > + + CertReqTemplateValue contains a prefilled certTemplate to be used for + the future certificate request. The SubjectPublicKeyInfo field in + the certTemplate MUST NOT be used. In case the PKI management entity + wishes to specify supported algorithms, the controls field MUST be + used. One AttributeTypeAndValue per supported algorithm MUST be + used. + + Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] + +2.12. Update Section 5.3.22 - Polling Request and Response Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling messages are used. This document adds the polling mechanism also to outstanding p10cr transactions. Replace all paragraphs in front of the state machine diagram with the following text. This pair of messages is intended to handle scenarios in which the client needs to poll the server in order to determine the status of @@ -516,21 +582,21 @@ the checkAfter value before sending another pollReq. 4 If an ip, cp, or kup is received in response to a pollReq, then it will be treated in the same way as the initial response. Note: A p10cr message contains exactly one CertificationRequestInfo data structure as specified in PKCS#10 [RFC2986] but no certificate request number. Therefore, the certReqId MUST be set to 0 in all following messages of this transaction. -2.9. Update Section 9 - IANA Considerations +2.13. Update Section 9 - IANA Considerations Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of that document. As this document defines a new and updates two existing Extended Key Usages, the IANA Considerations need to be updated accordingly. Add the following paragraphs between the first and second paragraph of the section. Within the SMI-numbers registry "SMI Security for PKIX Extended Key @@ -560,21 +625,34 @@ changes have been performed. Three new entry have been added: Decimal Description References ------- --------------------- ---------- 17 id-it-caCerts [thisRFC] 18 id-it-rootCaKeyUpdate [thisRFC] 19 id-it-certReqTemplate [thisRFC] -2.10. Update Appendix B - The Use of Revocation Passphrase + WWithin the SMI-numbers registry " SMI Security for PKIX CRMF + Registration Controls (1.3.6.1.5.5.7.5.1)" (see + https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- + numbers-1.3.6.1.5.5.7.5.1) as defined in RFC 7299 [RFC7299] two + changes have been performed. + + Two new entry have been added: + + Decimal Description References + ------- -------------------- ---------- + TBD3 id-regCtrl-algId [thisRFC] + TBD4 id-regCtrl-rsaKeyLen [thisRFC] + +2.14. Update Appendix B - The Use of Revocation Passphrase Appendix B of RFC 4210 [RFC4210] describes the usage of the revocation passphrase. As this document updates RFC 4210 [RFC4210] to utilize the parent structure EncryptedKey instead of EncryptedValue as described in Section 2.1 above, the description is updated accordingly. Replace the first bullet point of this section with the following text. @@ -595,21 +673,21 @@ Replace the third bullet point of this section with the following text. o When using EnvelopedData the localKeyId attribute as specified in RFC 2985 [RFC2985] and when using EncryptedValue the valueHint field MAY contain a key identifier (chosen by the entity, along with the passphrase itself) to assist in later retrieval of the correct passphrase (e.g., when the revocation request is constructed by the entity and received by the CA/RA). -2.11. Update Appendix C - Request Message Behavioral Clarifications +2.15. Update Appendix C - Request Message Behavioral Clarifications Appendix C of RFC 4210 [RFC4210] provides clarifications to the request message behavior. As this document updates RFC 4210 [RFC4210] to utilize the parent structure EncryptedKey instead of EncryptedValue as described in Section 2.1 above, the description is updated accordingly. Replace the note coming after the ASN.1 syntax of POPOPrivKey of this section with the following text. @@ -619,21 +697,21 @@ -- * Section 5.2.2 of this specification). Therefore, this document -- * makes the behavioral clarification of specifying that the -- * contents of "thisMessage" MUST be encoded either as -- * "EnvelopedData" or "EncryptedValue" (only for backward -- * compatibility) and then wrapped in a BIT STRING. This allows -- * the necessary conveyance and protection of the private key -- * while maintaining bits-on-the-wire compatibility with RFC 4211 -- * [RFC4211]. -- ********** -2.12. Update Appendix D.4. - Initial Registration/Certification (Basic +2.16. Update Appendix D.4. - Initial Registration/Certification (Basic Authenticated Scheme) Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ certification scheme. This scheme shall continue to use EncryptedValue for backward compatibility reasons. Replace the comment after the privateKey field of crc[1].certifiedKeyPair in the syntax of the Initialization Response message with the following text. @@ -651,21 +729,21 @@ whenever possible. Insert this section at the end of the current Section 1. 1.1 Changes since RFC 6712 The following updates are made in draft-ietf-lamps-cmp-updates: o Add an HTTP URI discovery mechanism and extend the URI structure. -3.2. New Section 3.6. - HTTP Request-URI +3.2. Replace Section 3.6. - HTTP Request-URI Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This document adds a discovery mechanism and extends the URIs. Replace the text of the section with the following text. Each CMP server on a PKI management entity supporting HTTP or HTTPS transport MUST support the use of the path-prefix of '/.well-known/' as defined in RFC 8515 [RFC8515] and the registered name of 'cmp' to ease interworking in a multi-vendor environment. @@ -740,20 +819,24 @@ URI suffix Change controller ----------- ----------------- cmp IETF 4. IANA Considerations This document contains an update to the IANA Consideration sections to be added to [RFC4210] and [RFC6712]. + < TBD: This document updates the ASN.1 modules of RFC 4210 Appendix F + [RFC4210] and RFC 5912 Section 9 [RFC5912]. New OIDs TBD1 and TBD2 + need to be registered to identify the updates ASN.1 modules. > + < TBD: The existing description and information of id-kp-cmcRA and id-kp-cmcCA need to be updated to reflect their extended usage. > 5. Security Considerations No changes are made to the existing security considerations of RFC 4210 [RFC4210] and RFC 6712 [RFC6712]. 6. Acknowledgements @@ -849,28 +932,27 @@ A.1. 1988 ASN.1 Module This section contains the updated ASN.1 module for [RFC4210]. This module replaces the module in Appendix F of that document. Although a 2002 ASN.1 module is provided, this remains the normative module as per the policy of the PKIX working group. PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) - id-mod(0) id-mod-cmp2000(16)} + id-mod(0) id-mod-cmp2020-88(TBD1)} DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- - IMPORTS Certificate, CertificateList, Extensions, AlgorithmIdentifier, UTF8String, id-kp -- if required; otherwise, comment out FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} GeneralName, KeyIdentifier FROM PKIX1Implicit88 {iso(1) identified-organization(3) @@ -870,27 +952,28 @@ UTF8String, id-kp -- if required; otherwise, comment out FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} GeneralName, KeyIdentifier FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} - CertTemplate, PKIPublicationInfo, EncryptedKey, EncryptedValue, - CertId, CertReqMessages + CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, + CertReqMessages, Controls, id-regCtrl FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)} -- The import of EncryptedKey is added due to the updates made - -- in CMP Updates [thisRFC] + -- in CMP Updates [thisRFC]]. EncryptedValue does not need to + -- be imported anymore and is therefore removed here. -- see also the behavioral clarifications to CRMF codified in -- Appendix C of this specification CertificationRequest FROM PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)} -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT -- tags). Alternatively, implementers may directly include -- the [PKCS10] syntax in this module @@ -1159,27 +1244,32 @@ -- MUST be present in the first Challenge; MAY be omitted in -- any subsequent Challenge in POPODecKeyChallContent (if -- omitted, then the owf used in the immediately preceding -- Challenge is to be used). witness OCTET STRING, -- the result of applying the one-way function (owf) to a -- randomly-generated INTEGER, A. [Note that a different -- INTEGER MUST be used for each Challenge.] challenge OCTET STRING -- the encryption (under the public key for which the cert. - -- request is being made) of Rand, where Rand is specified as - -- Rand ::= SEQUENCE { - -- int INTEGER, - -- - the randomly-generated INTEGER A (above) - -- sender GeneralName - -- - the sender's name (as included in PKIHeader) - -- } + -- request is being made) of Rand. + } + + -- Added in CMP Updates [thisRFC] + + Rand ::= SEQUENCE { + -- Rand is encrypted under the public key to form the challenge + -- in POPODecKeyChallContent + int INTEGER, + -- the randomly-generated INTEGER A (above) + sender GeneralName + -- the sender's name (as included in PKIHeader) } POPODecKeyRespContent ::= SEQUENCE OF INTEGER -- One INTEGER per encryption key certification request (in the -- same order as these requests appear in CertReqMessages). The -- retrieved INTEGER A (above) is returned to the sender of the -- corresponding Challenge. CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate @@ -1279,41 +1370,52 @@ -- the hash of the certificate, using the same hash algorithm -- as is used to create and verify the certificate signature certReqId INTEGER, -- to match this confirmation with the corresponding req/rep statusInfo PKIStatusInfo OPTIONAL } PKIConfirmContent ::= NULL -- Added in CMP Updates [thisRFC] - RootCaKeyUpdateContent ::= SEQUENCE { newWithNew CMPCertificate -- new root CA certificate newWithOld [0] CMPCertificate OPTIONAL, -- X.509 certificate containing the new public root CA key -- signed with the old private root CA key oldWithNew [1] CMPCertificate OPTIONAL - -- old root CA key certificate + -- X.509 certificate containing the old public root CA key + -- signed with the new private root CA key } -- Added in CMP Updates [thisRFC] CertReqTemplateContent ::= SEQUENCE { certTemplate CertTemplate, -- prefilled certTemplate structure elements - rsaKeyLen INTEGER OPTIONAL - -- Any reasonable RSA key length, if subjectPublicKeyInfo - -- of the certTemplate has the OID rsaEncryption. + -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT + -- be used. + controls Controls OPTIONAL + -- MAY be used to specify supported algorithms. + -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue + -- as specified in CRMF (RFC4211) } + id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } + AlgIdCtrl ::= AlgorithmIdentifier + -- SHALL be used to specify suported algorithms other than RSA + + id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } + RsaKeyLenCtrl ::= Integer + -- SHALL be used to specify suported RSA key lengths + InfoTypeAndValue ::= SEQUENCE { infoType OBJECT IDENTIFIER, infoValue ANY DEFINED BY infoType OPTIONAL } -- Example InfoTypeAndValue contents include, but are not limited -- to, the following (un-comment in this ASN.1 module and use as -- appropriate for a given environment): -- -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} -- CAProtEncCertValue ::= CMPCertificate @@ -1420,27 +1522,25 @@ A.2. 2002 ASN.1 Module This section contains the updated 2002 ASN.1 module for [RFC5912]. This module replaces the module in Section 9 of that document. The module contains those changes that were done to update to 2002 ASN.1 standard done in [RFC5912] as well as changes made for this document. < TBD: Dose this document then also updates [RFC5912]? > - < In case the working group sees a need to provide this ASN.1 module - in 2015 syntax, please let me know. > - PKIXCMP-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) - id-mod-cmp2000-02(50) } DEFINITIONS EXPLICIT TAGS ::= + id-mod-cmp2020-02(TBD2) } + DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS AttributeSet{}, Extensions{}, EXTENSION, ATTRIBUTE FROM PKIX-CommonTypes-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, DIGEST-ALGORITHM, MAC-ALGORITHM @@ -1452,26 +1552,30 @@ Certificate, CertificateList, id-kp FROM PKIX1Explicit-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} GeneralName, KeyIdentifier FROM PKIX1Implicit-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} - CertTemplate, PKIPublicationInfo, EncryptedKey, EncryptedValue, - CertId,CertReqMessages + CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, + CertReqMessages, Controls, id-regCtrl FROM PKIXCRMF-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005-02(55) } + -- The import of EncryptedKey is added due to the updates made + -- in CMP Updates [thisRFC]. EncryptedValue does not need to + -- be imported anymore and is therefore removed here. + -- see also the behavioral clarifications to CRMF codified in -- Appendix C of this specification CertificationRequest FROM PKCS-10 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT -- tags). Alternatively, implementers may directly include -- the [PKCS10] syntax in this module @@ -1741,27 +1845,31 @@ -- MUST be present in the first Challenge; MAY be omitted in -- any subsequent Challenge in POPODecKeyChallContent (if -- omitted, then the owf used in the immediately preceding -- Challenge is to be used). witness OCTET STRING, -- the result of applying the one-way function (owf) to a -- randomly-generated INTEGER, A. [Note that a different -- INTEGER MUST be used for each Challenge.] challenge OCTET STRING -- the encryption (under the public key for which the cert. - -- request is being made) of Rand, where Rand is specified as - -- Rand ::= SEQUENCE { - -- int INTEGER, - -- - the randomly-generated INTEGER A (above) - -- sender GeneralName - -- - the sender's name (as included in PKIHeader) - -- } + -- request is being made) of Rand. + } + + -- Added in CMP Updates [thisRFC] + Rand ::= SEQUENCE { + -- Rand is encrypted under the public key to form the challenge + -- in POPODecKeyChallContent + int INTEGER, + -- the randomly-generated INTEGER A (above) + sender GeneralName + -- the sender's name (as included in PKIHeader) } POPODecKeyRespContent ::= SEQUENCE OF INTEGER -- One INTEGER per encryption key certification request (in the -- same order as these requests appear in CertReqMessages). The -- retrieved INTEGER A (above) is returned to the sender of the -- corresponding Challenge. CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate @@ -1853,39 +1962,52 @@ -- Added in CMP Updates [thisRFC] RootCaKeyUpdateContent ::= SEQUENCE { newWithNew CMPCertificate -- new root CA certificate newWithOld [0] CMPCertificate OPTIONAL, -- X.509 certificate containing the new public root CA key -- signed with the old private root CA key oldWithNew [1] CMPCertificate OPTIONAL - -- old root CA key certificate + -- X.509 certificate containing the old public root CA key + -- signed with the new private root CA key } -- Added in CMP Updates [thisRFC] CertReqTemplateContent ::= SEQUENCE { certTemplate CertTemplate, -- prefilled certTemplate structure elements - rsaKeyLen INTEGER OPTIONAL - -- Any reasonable RSA key length, if subjectPublicKeyInfo - -- of the certTemplate has the OID rsaEncryption. + -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT + -- be used. + controls Controls OPTIONAL + -- MAY be used to specify supported algorithms. + -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue + -- as specified in CRMF (RFC4211) } + id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } + AlgIdCtrl ::= AlgorithmIdentifier + -- SHALL be used to specify suported algorithms other than RSA + + id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } + RsaKeyLenCtrl ::= Integer + -- SHALL be used to specify suported RSA key lengths + INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER InfoTypeAndValue ::= SEQUENCE { infoType INFO-TYPE-AND-VALUE. &id({SupportedInfoSet}), infoValue INFO-TYPE-AND-VALUE. + &Type({SupportedInfoSet}{@infoType}) } SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } -- Example InfoTypeAndValue contents include, but are not limited -- to, the following (uncomment in this ASN.1 module and use as -- appropriate for a given environment): -- -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} -- CAProtEncCertValue ::= CMPCertificate @@ -1997,47 +2120,80 @@ -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } END Appendix B. History of changes Note: This appendix will be deleted in the final version of the document. + From version 04 -> 05: + + o Added Section 2.6 and Section 2.7 to clarify the usage of these + general messages types with EC curves (see thread + "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue + in CMP headers") + + o Split former section 2.7 on adding 'CA Certificates', 'Root CA + Certificates Update', and 'Certificate Request Template' in three + separate sections for easier readability + + o Changed in Section 2.10 the ASN.1 syntax of CertReqTemplateValue + from using reaKeyLen to usage of controls as specified in CRMF + Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and + rsaKeyLen") + + o Updated the IANA considerations in Section 2.13 to introduce new + OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread + "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") + + o Updated the IANA Considerations in and the Appendixes to introduce + new OID for the updates ASN.1 modules (see thread "I-D Action: + draft-ietf-lamps-cmp-updates-04.txt") + + o Removed EncryptedValue from and added Controls to the list of + types imported from CRMF [RFC4211] in ASN.1 modules (see thread + "draft-ietf-lamps-cmp-updates and the ASN.1 modules") + + o Moved declaration of Rand out of the comment in ASN.1 modules (see + thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") + + o Minor changes and corrections + From version 03 -> 04: o Added Section 2.7 to introduce three new id-it IDs for uses in general messages as discussed (see thread "draft-ietf-lamps-cmp- updates add section to introduce id-it-caCerts, id-it- rootCaKeyUpdate, and id-it-certReqTemplate") o Added the new id-it IDs and the /.well-known/cmp to the IANA Considerations of [RFC4210] in Section 2.9 - o Updated the IANA Considerations of [RFC4210] in Section 2.10 + o Updated the IANA Considerations of [RFC4210] in Section 2.14 o Some changes in wording on Section 3 due to review comments from Martin Peylo From version 02 -> 03: o Added a ToDo on aligning with the CMP Algorithms draft that will be set up as decided in IETF 108 o Updated section on Encrypted Values in Section 2.4 to add the AsymmetricKey Package structure to transport a newly generated private key as decided in IETF 108 - o Updated the IANA Considerations of [RFC4210] in Section 2.10 + o Updated the IANA Considerations of [RFC4210] in Section 2.14 - o Added the pre-registered OID in Section 2.10 and the ASN.1 module + o Added the pre-registered OID in Section 2.14 and the ASN.1 module o Added Section 3 to document the changes to RFC 6712 [RFC6712] regarding URI discovery and using the path-prefix of '/.well- known/' as discussed in IETF 108 o Updated the IANA Considerations section o Added a complete updated ASN.1 module in 1988 syntax to update Appendix F of [RFC4210] and a complete updated ASN.1 module in 2002 syntax to update Section 9 of [RFC5912] @@ -2046,21 +2202,21 @@ From version 01 -> 02: o Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 o Changed from symmetric key-encryption to password-based key management technique in Section 2.4 as discussed with Russ and Jim on the mailing list o Defined the attribute containing the key identifier for the - revocation passphrase in Section 2.10 + revocation passphrase in Section 2.14 o Moved the change history to the Appendix From version 00 -> 01: o Minor changes in wording From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- updates-00: