draft-ietf-lamps-cmp-updates-14.txt   draft-ietf-lamps-cmp-updates-15.txt 
LAMPS Working Group H. Brockhaus, Ed. LAMPS Working Group H. Brockhaus, Ed.
Internet-Draft D. von Oheimb Internet-Draft D. von Oheimb
Updates: 4210, 5912, 6712 (if approved) Siemens Updates: 4210, 5912, 6712 (if approved) Siemens
Intended status: Standards Track J. Gray Intended status: Standards Track J. Gray
Expires: 23 May 2022 Entrust Expires: 20 June 2022 Entrust
19 November 2021 17 December 2021
Certificate Management Protocol (CMP) Updates Certificate Management Protocol (CMP) Updates
draft-ietf-lamps-cmp-updates-14 draft-ietf-lamps-cmp-updates-15
Abstract Abstract
This document contains a set of updates to the syntax and transfer of This document contains a set of updates to the syntax and transfer of
Certificate Management Protocol (CMP) version 2. This document Certificate Management Protocol (CMP) version 2. This document
updates RFC 4210, RFC 5912, and RFC 6712. updates RFC 4210, RFC 5912, and RFC 6712.
The aspects of CMP updated in this document are using EnvelopedData The aspects of CMP updated in this document are using EnvelopedData
instead of EncryptedValue, clarifying the handling of p10cr messages, instead of EncryptedValue, clarifying the handling of p10cr messages,
improving the crypto agility, as well as adding new general message improving the crypto agility, as well as adding new general message
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 May 2022. This Internet-Draft will expire on 20 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 44 skipping to change at page 2, line 44
Content . . . . . . . . . . . . . . . . . . . . . . . . 12 Content . . . . . . . . . . . . . . . . . . . . . . . . 12
2.10. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 13 2.10. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 13
2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key 2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key
Pair Types . . . . . . . . . . . . . . . . . . . . . . . 13 Pair Types . . . . . . . . . . . . . . . . . . . . . . . 13
2.12. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 13 2.12. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 13
2.13. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 14 2.13. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 14
2.14. New Section 5.3.19.15 - Root CA Certificate Update . . . 14 2.14. New Section 5.3.19.15 - Root CA Certificate Update . . . 14
2.15. New Section 5.3.19.16 - Certificate Request Template . . 15 2.15. New Section 5.3.19.16 - Certificate Request Template . . 15
2.16. New Section 5.3.19.17 - CRL update retrieval . . . . . . 16 2.16. New Section 5.3.19.17 - CRL update retrieval . . . . . . 16
2.17. Update Section 5.3.21 - Error Message Content . . . . . . 17 2.17. Update Section 5.3.21 - Error Message Content . . . . . . 17
2.18. Replace Section 5.3.22 - Polling Request and Response . . 17 2.18. Replace Section 5.3.22 - Polling Request and Response . . 18
2.19. Update Section 7 - Version Negotiation . . . . . . . . . 22 2.19. Update Section 7 - Version Negotiation . . . . . . . . . 22
2.20. Update Section 7.1.1. - Clients Talking to RFC 2510 2.20. Update Section 7.1.1. - Clients Talking to RFC 2510
Servers . . . . . . . . . . . . . . . . . . . . . . . . 24 Servers . . . . . . . . . . . . . . . . . . . . . . . . 24
2.21. Add Section 8.4 - Private keys for certificate signing and 2.21. Add Section 8.4 - Private keys for certificate signing and
CMP message protection . . . . . . . . . . . . . . . . . 24 CMP message protection . . . . . . . . . . . . . . . . . 24
2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and 2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and
shared secret information . . . . . . . . . . . . . . . 24 shared secret information . . . . . . . . . . . . . . . 24
2.23. Add Section 8.6 - Trust anchor provisioning using CMP 2.23. Add Section 8.6 - Trust anchor provisioning using CMP
messages . . . . . . . . . . . . . . . . . . . . . . . . 25 messages . . . . . . . . . . . . . . . . . . . . . . . . 25
2.24. Update Section 9 - IANA Considerations . . . . . . . . . 26 2.24. Update Section 9 - IANA Considerations . . . . . . . . . 26
2.25. Update Appendix B - The Use of Revocation Passphrase . . 27 2.25. Update Appendix B - The Use of Revocation Passphrase . . 28
2.26. Update Appendix C - Request Message Behavioral 2.26. Update Appendix C - Request Message Behavioral
Clarifications . . . . . . . . . . . . . . . . . . . . . 28 Clarifications . . . . . . . . . . . . . . . . . . . . . 28
2.27. Update Appendix D.1. - General Rules for Interpretation of 2.27. Update Appendix D.1. - General Rules for Interpretation of
These Profiles . . . . . . . . . . . . . . . . . . . . . 29 These Profiles . . . . . . . . . . . . . . . . . . . . . 29
2.28. Update Appendix D.2. - Algorithm Use Profile . . . . . . 29 2.28. Update Appendix D.2. - Algorithm Use Profile . . . . . . 30
2.29. Update Appendix D.4. - Initial Registration/Certification 2.29. Update Appendix D.4. - Initial Registration/Certification
(Basic Authenticated Scheme) . . . . . . . . . . . . . . 30 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 30
3. Updates to RFC 6712 - HTTP Transfer for the Certificate 3. Updates to RFC 6712 - HTTP Transfer for the Certificate
Management Protocol (CMP) . . . . . . . . . . . . . . . . 30 Management Protocol (CMP) . . . . . . . . . . . . . . . . 30
3.1. Update Section 1. - Introduction . . . . . . . . . . . . 30 3.1. Update Section 1. - Introduction . . . . . . . . . . . . 30
3.2. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 30 3.2. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 31
3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31 3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31
3.4. Update Section 6. - IANA Considerations . . . . . . . . . 31 3.4. Update Section 6. - IANA Considerations . . . . . . . . . 32
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . 33 7.1. Normative References . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . 35 7.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 35 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 36
A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 35 A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 36
A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 49 A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 50
Appendix B. History of changes . . . . . . . . . . . . . . . . . 62 Appendix B. History of changes . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
While using CMP [RFC4210] in industrial and IoT environments and While using CMP [RFC4210] in industrial and IoT environments and
developing the Lightweight CMP Profile developing the Lightweight CMP Profile
[I-D.ietf-lamps-lightweight-cmp-profile] some limitations were [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were
identified in the original CMP specification. This document updates identified in the original CMP specification. This document updates
RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these
limitations. limitations.
skipping to change at page 16, line 51 skipping to change at page 16, line 51
Lightweight CMP Profile Section 4.3 Lightweight CMP Profile Section 4.3
[I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after [I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after
new Section 5.3.19.16: new Section 5.3.19.16:
5.3.19.17. CRL update retrieval 5.3.19.17. CRL update retrieval
This MAY be used by the client to get new CRLs, specifying the source This MAY be used by the client to get new CRLs, specifying the source
of the CRLs and the thisUpdate value of the latest CRL it already of the CRLs and the thisUpdate value of the latest CRL it already
has, if available. A CRL source is given either by a has, if available. A CRL source is given either by a
DistributionPointName or the GeneralNames of the issuing CA. The DistributionPointName or the GeneralNames of the issuing CA. The
server shall provide only those CRLs that are more recent than the DistributionPointName should be treated as an internal pointer to
ones indicated by the client. identify a CRL that the server already has and not as a way to ask
the server to fetch CRLs from external locations. The server shall
provide only those CRLs that are more recent than the ones indicated
by the client.
GenMsg: {id-it TBD1}, SEQUENCE SIZE (1..MAX) OF CRLStatus GenMsg: {id-it TBD1}, SEQUENCE SIZE (1..MAX) OF CRLStatus
GenRep: {id-it TBD2}, SEQUENCE SIZE (1..MAX) OF GenRep: {id-it TBD2}, SEQUENCE SIZE (1..MAX) OF
CertificateList | < absent > CertificateList | < absent >
CRLSource ::= CHOICE { CRLSource ::= CHOICE {
dpn [0] DistributionPointName, dpn [0] DistributionPointName,
issuer [1] GeneralNames } issuer [1] GeneralNames }
CRLStatus ::= SEQUENCE { CRLStatus ::= SEQUENCE {
skipping to change at page 24, line 48 skipping to change at page 24, line 48
2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and 2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and
shared secret information shared secret information
The following subsection addresses the risk arising from low entropy The following subsection addresses the risk arising from low entropy
of random numbers, asymmetric keys, and shared secret information. of random numbers, asymmetric keys, and shared secret information.
8.5. Entropy of random numbers, key pairs, and shared secret 8.5. Entropy of random numbers, key pairs, and shared secret
information information
For requirements regarding proper random number and key generation Implementations must generate nonces and private keys from random
please refer to [RFC4086]. input. The use of inadequate pseudo-random number generators (PRNGs)
to generate cryptographic keys can result in little or no security.
An attacker may find it much easier to reproduce the PRNG environment
that produced the keys and to search the resulting small set of
possibilities than brute-force searching the whole key space. As an
example of predictable random numbers see CVE-2008-0166
[CVE-2008-0166]; consequences of low-entropy random numbers are
discussed in Mining Your Ps and Qs [MiningPsQs]. The generation of
quality random numbers is difficult. ISO/IEC 20543:2019
[ISO.20543-2019], NIST SP 800-90A Rev.1 [NIST.SP.800-90Ar1], BSI AIS
31 V2.0 [AIS31], and others offer valuable guidance in this area.
For the case of centrally generated key pairs, the entropy of the If shared secret information is generated by a cryptographically
shared secret information SHALL NOT be less than the security secure random-number generator (CSRNG) it is safe to assume that the
strength of the centrally generated key pair; if the shared secret entropy of the shared secret information equals its bit length. If
information is re-used for different key pairs, the entropy and the no CSRNG is used, the entropy of a shared secret information depends
security of the underlying cryptographic mechanisms SHOULD exceed the on the details of the generation process and cannot be measure
security strength of the key pairs. securely after it has been generated. If user-generated passwords
are used as shared secret information, their entropy cannot be
measured and are typically insufficient for protected delivery of
centrally generated keys or trust anchors.
If the entropy of a shared secret information protecting the delivery
of a centrally generated key pair is known, it should not be less
than the security strength of that key pair; if the shared secret
information is re-used for different key pairs, the security of the
shared secret information should exceed the security strength of each
key pair.
For the case of a PKI management operation that delivers a new trust For the case of a PKI management operation that delivers a new trust
anchor (e.g., a root CA certificate) using caPubs, (a) that is not anchor (e.g., a root CA certificate) using caPubs or genm (a) that is
concluded in a timely manner or (b) where the shared secret not concluded in a timely manner or (b) where the shared secret
information is re-used for several key management operations, the information is re-used for several key management operations, the
entropy of the shared secret information SHALL NOT be less than the entropy of the shared secret information, if known, should not be
less than the security strength of the trust anchor being managed by
the operation. For other cases it is recommended to (a) use a shared
secret information of possibly low security strength (e.g., a
password) only for a single PKI management operation or (b) use a
shared secret information with an entropy that at least matches the
security strength of the key material being managed by the operation. security strength of the key material being managed by the operation.
For other cases it is recommended to (a) either use a shared secret
information of possibly low entropy (e.g., a password) only for a
single PKI management operation or (b) use a shared secret
information with an entropy that matches the security strength of the
key material being managed by the operation.
2.23. Add Section 8.6 - Trust anchor provisioning using CMP messages 2.23. Add Section 8.6 - Trust anchor provisioning using CMP messages
The following subsection addresses the risk arising from in-band The following subsection addresses the risk arising from in-band
provisioning of new trust anchors in a PKI management operation. provisioning of new trust anchors in a PKI management operation.
Insert this section after new Section 8.5: Insert this section after new Section 8.5:
8.6. Trust anchor provisioning using CMP messages 8.6. Trust anchor provisioning using CMP messages
The provider of trust anchors, which typically will be an RA involved The provider of trust anchors, which typically will be an RA involved
in configuration management of its clients, MUST NOT include to-be- in configuration management of its clients, MUST NOT include to-be-
trusted CA certificates in a CMP message unless it can take trusted CA certificates in a CMP message unless it can take
responsibility for making the recipient trust them. When doing so, responsibility for making the recipient trust them. When doing so,
it MUST exert the same due diligence as for its own trust anchors. it MUST exert the same due diligence as for its own trust anchors.
Whenever an EE receives in a CMP message, e.g., in the caPubs field Whenever an EE receives in a CMP message, e.g., in the caPubs field
of a certificate response or in a general response (genp), a CA of a certificate response or in a general response (genp), a CA
certificate for use as a trust anchor, it MUST properly authenticate certificate for use as a trust anchor, it MUST properly authenticate
the message sender without already trusting any of the CA the message sender without already trusting any of the CA
skipping to change at page 26, line 35 skipping to change at page 27, line 8
| 32 | id-kp-cmKGA | [thisRFC] | | 32 | id-kp-cmKGA | [thisRFC] |
+---------+-------------+------------+ +---------+-------------+------------+
Table 1: Addition to the PKIX Table 1: Addition to the PKIX
Extended Key Purpose Identifiers Extended Key Purpose Identifiers
registry registry
In the SMI-numbers registry "SMI Security for PKIX CMP Information In the SMI-numbers registry "SMI Security for PKIX CMP Information
Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi-
numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in
RFC 7299 [RFC7299] fife additions have been performed. RFC 7299 [RFC7299] seven additions have been performed.
Fife new entries have been added: Seven new entries have been added:
+=========+=======================+============+ +=========+=======================+============+
| Decimal | Description | References | | Decimal | Description | References |
+=========+=======================+============+ +=========+=======================+============+
| 17 | id-it-caCerts | [thisRFC] | | 17 | id-it-caCerts | [thisRFC] |
+---------+-----------------------+------------+ +---------+-----------------------+------------+
| 18 | id-it-rootCaKeyUpdate | [thisRFC] | | 18 | id-it-rootCaKeyUpdate | [thisRFC] |
+---------+-----------------------+------------+ +---------+-----------------------+------------+
| 19 | id-it-certReqTemplate | [thisRFC] | | 19 | id-it-certReqTemplate | [thisRFC] |
+---------+-----------------------+------------+ +---------+-----------------------+------------+
skipping to change at page 33, line 34 skipping to change at page 34, line 5
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, Classes and Attribute Types Version 2.0", RFC 2985,
DOI 10.17487/RFC2985, November 2000, DOI 10.17487/RFC2985, November 2000,
<https://www.rfc-editor.org/info/rfc2985>. <https://www.rfc-editor.org/info/rfc2985>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate "Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005, DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>. <https://www.rfc-editor.org/info/rfc4210>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211, Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005, DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>. <https://www.rfc-editor.org/info/rfc4211>.
skipping to change at page 35, line 18 skipping to change at page 35, line 26
<https://www.rfc-editor.org/info/rfc8933>. <https://www.rfc-editor.org/info/rfc8933>.
[RFC9045] Housley, R., "Algorithm Requirements Update to the [RFC9045] Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", RFC 9045, Request Message Format (CRMF)", RFC 9045,
DOI 10.17487/RFC9045, June 2021, DOI 10.17487/RFC9045, June 2021,
<https://www.rfc-editor.org/info/rfc9045>. <https://www.rfc-editor.org/info/rfc9045>.
7.2. Informative References 7.2. Informative References
[AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI),
Killmann, W., and W. Schindler, "A proposal for:
Functionality classes for random number generators,
version 2.0", 18 September 2011,
<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/
Zertifizierung/Interpretationen/AIS_31_Functionality_class
es_for_random_number_generators_e.pdf>.
[CVE-2008-0166]
National Institute of Science and Technology (NIST),
"National Vulnerability Database - CVE-2008-0166", 13 May
2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>.
[I-D.ietf-lamps-lightweight-cmp-profile] [I-D.ietf-lamps-lightweight-cmp-profile]
Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", Work in Certificate Management Protocol (CMP) Profile", Work in
Progress, Internet-Draft, draft-ietf-lamps-lightweight- Progress, Internet-Draft, draft-ietf-lamps-lightweight-
cmp-profile-07, 25 October 2021, cmp-profile-08, 19 November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
lightweight-cmp-profile-07>. lightweight-cmp-profile-08>.
[IEEE.802.1AR_2018] [IEEE.802.1AR_2018]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks - Secure Device Identity", IEEE 802.1AR-2018, networks - Secure Device Identity", IEEE 802.1AR-2018,
DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018,
<https://ieeexplore.ieee.org/document/8423794>. <https://ieeexplore.ieee.org/document/8423794>.
[ISO.20543-2019]
International Organization for Standardization (ISO),
"Information technology -- Security techniques -- Test and
analysis methods for random bit generators within ISO/IEC
19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019,
October 2019.
[MiningPsQs]
Security'12: Proceedings of the 21st USENIX conference on
Security symposium, Heninger, N., Durumeric, Z., Wustrow,
E., and J. A. Halderman, "Mining Your Ps and Qs: Detection
of Widespread Weak Keys in Network Devices", August 2012,
<https://www.usenix.org/conference/usenixsecurity12/
technical-sessions/presentation/heninger>.
[NIST.SP.800-90Ar1]
Barker, Elaine B. and John M. Kelsey, "Recommendation for
Random Number Generation Using Deterministic Random Bit
Generators", NIST NIST SP 800-90Ar1,
DOI 10.6028/NIST.SP.800-90Ar1, June 2015,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90Ar1.pdf>.
Appendix A. ASN.1 Modules Appendix A. ASN.1 Modules
A.1. 1988 ASN.1 Module A.1. 1988 ASN.1 Module
This section contains the updated ASN.1 module for [RFC4210]. This This section contains the updated ASN.1 module for [RFC4210]. This
module replaces the module in Appendix F of that document. Although module replaces the module in Appendix F of that document. Although
a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the
normative module as per the policy of the PKIX working group. normative module as per the policy of the PKIX working group.
PKIXCMP {iso(1) identified-organization(3) PKIXCMP {iso(1) identified-organization(3)
skipping to change at page 62, line 46 skipping to change at page 63, line 43
-- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 }
END END
Appendix B. History of changes Appendix B. History of changes
Note: This appendix will be deleted in the final version of the Note: This appendix will be deleted in the final version of the
document. document.
From version 14 -> 15:
* Updated Section 2.16 clarifying the usage of CRLSource (see thread
"CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp-
updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")
* Updated Section 2.22 adding further references regarding random
number generation (see thread "CMP draft WGLC: measuring entropy,
CA certificates")
* Fixed some nits
From version 13 -> 14: From version 13 -> 14:
* Extended id-it-caCerts support message to allow transporting to- * Extended id-it-caCerts support message to allow transporting to-
be-trusted root CA certificates; added respective security be-trusted root CA certificates; added respective security
consideration (see thread "Generalizing the CMP "Get CA consideration (see thread "Generalizing the CMP "Get CA
certificates" use case") certificates" use case")
* Rolled back changes made in previous version regarding root CA * Rolled back changes made in previous version regarding root CA
update to avoid registration of new OIDs. Yet we sticked to using update to avoid registration of new OIDs. Yet we sticked to using
id-it-rootCaCert in the genm body instead its headers' generalInfo id-it-rootCaCert in the genm body instead its headers' generalInfo
field and removed the ToDos and TBDs on re-arranging id-it OIDs field and removed the ToDos and TBDs on re-arranging id-it OIDs
(see thread "Allocation of OIDs for CRL update retrieval (draft- (see thread "Allocation of OIDs for CRL update retrieval (draft-
ietf-lamps-cmp-updates-13)") ietf-lamps-cmp-updates-13)")
From version 12 -> 13: From version 12 -> 13:
* Added John Gray to the list of authors due to fruitful discussion * Added John Gray to the list of authors due to fruitful discussion
 End of changes. 27 change blocks. 
47 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/