Skip to content

AUTH48 edits #68

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ounsworth wants to merge 1 commit into
base: main
Choose a base branch
from
Open

AUTH48 edits #68

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 44 additions & 38 deletions draft-ietf-lamps-rfc4210bis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -213,14 +213,6 @@ This document adds support for management of certificates containing a Key Encap
EnvelopedData instead of EncryptedValue. This document also includes the
updates specified in Section 2 and Appendix A.2 of RFC 9480.

The updates maintain backward compatibility with CMP version 2 wherever
possible. Updates to CMP version 2 are improving crypto agility, extending the
polling mechanism, adding new general message types, and adding extended
key usages to identify special CMP server authorizations. CMP version 3 is
introduced for changes to the ASN.1 syntax, which are support of
EnvelopedData, certConf with hashAlg, POPOPrivKey with agreeMAC, and
RootCaKeyUpdateContent in ckuann messages.

This document obsoletes RFC 4210 and together with I-D.ietf-lamps-rfc6712bis
and it also obsoletes RFC 9480. Appendix F of this document updates the
Section 9 of RFC 5912.
Expand Down Expand Up @@ -256,9 +248,17 @@ Please perform the following substitution.
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocol (CMP). Protocol messages are
defined for certificate creation and management. The term
"certificate" in this document refers to an X.509v3 Certificate as
"certificate" in this document refers to an X.509v3 certificate as
defined in {{RFC5280}}.

The updates maintain backward compatibility with CMP version 2 wherever
possible. Updates to CMP version 2 are improving crypto agility, extending the
polling mechanism, adding new general message types, and adding extended
key usages to identify special CMP server authorizations. CMP version 3 is
introduced for changes to the ASN.1 syntax, which are support of
EnvelopedData, certConf with hashAlg, POPOPrivKey with agreeMAC, and
RootCaKeyUpdateContent in ckuann messages.

## Changes Made by RFC 4210
{: id="sect-1.1"}

Expand Down Expand Up @@ -315,10 +315,11 @@ Profile {{RFC9483}}, in the following areas:



* Offer an optional hashAlg field in CertStatus supporting cases that a certificate
needs to be confirmed that has a signature algorithm that does not indicate
a specific hash algorithm to use for computing the certHash. This is also in
preparation for upcoming post-quantum algorithms.
* Offer an optional hashAlg field in CertStatus to support cases where a hash function
is required in order to compute the certHash as part of confirming the
certificate, but the certificate's signature algorithm
does not specify a hash algorithm, so one needs to be specified in the CMP message instead.
This is also in preparation for upcoming post-quantum algorithms.

* Added new general message types to request CA certificates, a root CA update,
a certificate request template, or Certificate Revocation List (CRL) updates.
Expand All @@ -333,7 +334,7 @@ Profile {{RFC9483}}, in the following areas:
## Changes Made by This Document
{: id="sect-1.3"}

This document obsoletes {{RFC4210}} and {{RFC9480}}. It includes the changes specified by Section 2 and Appendix C.2 of {{RFC9480}} as described in {{sect-1.2}}. Additionally this document updates the content of {{RFC4210}} in the following areas:
This document obsoletes {{RFC4210}} and {{RFC9480}}. It includes the changes specified by Section 2 and Appendix A of {{RFC9480}} as described in {{sect-1.2}}. Additionally this document updates the content of {{RFC4210}} in the following areas:

* Added {{sect-3.1.1.4}} introducing the Key Generation Authority.

Expand Down Expand Up @@ -570,7 +571,7 @@ management


1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509
standards.
standards, in particular {{X509.2019}}.

1. It must be possible to regularly update any key pair without
affecting any other key pair.
Expand Down Expand Up @@ -603,9 +604,10 @@ management
attacks, which are possible, are not made simpler.

1. PKI management protocols must be usable over a variety of
"transport" mechanisms, specifically including mail, Hypertext
"transport" mechanisms, specifically including email, Hypertext
Transfer Protocol (HTTP), Message Queuing Telemetry Transport (MQTT),
Constrained Application Protocol (CoAP), and off-line file-based.
Constrained Application Protocol (CoAP), and various off-line and non-networked
file transfer methods.

1. Final authority for certification creation rests with the CA.
No RA or end entity equipment can assume that any certificate
Expand Down Expand Up @@ -896,8 +898,9 @@ different environments is available, e.g., in {{sect-c}} and
as well as in the Lightweight CMP Profile {{RFC9483}} on fully
automating certificate management in a machine-to-machine and IoT
environment. Also industry standards like {{ETSI-3GPP.33.310}} for
mobile networks and {{UNISIG.Subset-137}} for Rail Automation adopted
CMP and have specified a set of mandatory schemes for their use case.
mobile networks and {{UNISIG.Subset-137}} for Rail Automation have adopted
CMP as their certificate management protocol, and have specified
mandatory profiles for their use case.

We will now describe the classification of initial
registration/certification schemes.
Expand Down Expand Up @@ -1209,13 +1212,13 @@ the new CA public key, it must load the new trust anchor information
into its trusted store.

The data structure used to protect the new and old CA public keys is
typically a standard X.509 v3 certificate (which may also
typically a standard X.509v3 certificate (which may also
contain extensions). There are no new data structures required.

Note: Sometimes self-signed root CA certificates do not make use of
X.509 v3 extensions and may be X.509 v1 certificates. Therefore, a
X.509v3 extensions and may be X.509v1 certificates. Therefore, a
root CA key update must be able to work for version 1 certificates.
The use of the X.509 v3 KeyIdentifier extension is recommended for
The use of the X.509v3 KeyIdentifier extension is recommended for
easier path building.

Note: While the scheme could be generalized to cover cases where
Expand Down Expand Up @@ -3919,9 +3922,9 @@ generator (CSRNG), it is safe to assume that the entropy of the shared secret
information equals its bit length. If no CSRNG is used, the entropy of
shared secret information depends on the details of the generation process
and cannot be measured 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.
passwords are used as shared secret information, their entropy cannot be measured.
Passwords generated from user generated entropy are typically insufficient
for protected delivery of centrally generated keys or trust anchors.

If the entropy of shared secret information protecting the delivery of
a centrally generated key pair is known, it should not be less than the security
Expand Down Expand Up @@ -4026,7 +4029,7 @@ One new entry has been added:

Reference: [RFCXXXX]

The new OID 1.2.840.113533.7.66.16 was registered by Entrust for id-KemBasedMac in the arch 1.2.840.113533.7.66. Entrust registered also the OIDs for id-PasswordBasedMac and id-DHBasedMac there.
Note that the new OID 1.2.840.113533.7.66.16 was registered by Entrust, and not by IANA, for id-KemBasedMac in the arch 1.2.840.113533.7.66. This was done to match the previous registrations for id-PasswordBasedMac and id-DHBasedMac which are also on the Entrust private arch.

All existing references to {{RFC2510}}, {{RFC4210}}, and {{RFC9480}} at https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml except those in the "SMI Security for PKIX Module Identifier" registry should be replaced with references to this document.

Expand Down Expand Up @@ -4264,7 +4267,7 @@ conforming implementations, please refer to Section 7.1 of CMP Algorithms {{RFC9
## Proof-of-Possession Profile
{: id="sect-c.3"}

POP fields for use (in signature field of pop field of
The table below describes the POP fields for use (in signature field of pop field of
ProofOfPossession structure) when proving possession of a private
signing key that corresponds to a public verification key for which a
certificate has been requested.
Expand Down Expand Up @@ -4348,8 +4351,8 @@ For simplicity, we also mandate that this message MUST be the final
one (i.e., no use of "waiting" status value).

The end entity has an out-of-band interaction with the CA/RA. This
transaction established the shared secret, the referenceNumber and
OPTIONALLY the distinguished name used for both sender and subject
transaction established the shared secret, the referenceNumber and an
OPTIONAL distinguished name used for both sender and subject
name in the certificate template. See {{sect-8.7}} for security
considerations on quality of shared secret information.

Expand Down Expand Up @@ -4624,26 +4627,26 @@ The profile for this exchange is identical to that given in {{sect-c.4}},
with the following exceptions:


1. sender name SHOULD be present
* sender name SHOULD be present

1. protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY
* protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY
also be supported) in request, response, certConfirm, and
PKIConfirm messages;

1. senderKID and recipKID are only present if required for message
* senderKID and recipKID are only present if required for message
verification;

1. body is kur or kup;
* body is kur or kup;

1. body may contain one or two CertReqMsg structures, but either
* body may contain one or two CertReqMsg structures, but either
CertReqMsg may be used to request certification of a locally-generated
public key or a centrally-generated public key (i.e.,the
position-dependence requirement of {{sect-c.4}} is removed);

1. protection bits are calculated according to the protectionAlg
* protection bits are calculated according to the protectionAlg
field;

1. regCtrl OldCertId SHOULD be used (unless it is clear to both
* regCtrl OldCertId SHOULD be used (unless it is clear to both
sender and receiver -- by means not specified in this document --
that it is not needed).

Expand Down Expand Up @@ -4692,7 +4695,7 @@ Identical to {{sect-c.2}}.
## Self-Signed Certificates
{: id="sect-d.3"}

Profile of how a certificate structure may be "self-signed". These
The table below provides a profile of how a certificate structure may be "self-signed". These
structures are used for distribution of new root CA public keys. This can
occur in one of three ways (see {{sect-4.4}} above for a description
of the use of these structures):
Expand Down Expand Up @@ -4825,7 +4828,7 @@ extraCerts optionally present
## Cross Certification Request/Response (1-way)
{: id="sect-d.6"}

Creation of a single cross-certificate (i.e., not two at once). The
This section describes the creation of a single cross-certificate (i.e., not two at once). The
requesting CA MAY choose who is responsible for publication of the
cross-certificate created by the responding CA through use of the
PKIPublicationInfo control.
Expand Down Expand Up @@ -5151,6 +5154,9 @@ The module contains those changes to the normative ASN.1 module from
Appendix F of {{RFC4210}} that were specified in {{RFC9480}},
as well as changes made in this document.

This module makes reference to ASN.1 structures defined in {{RFC6268}},
as well as the UTF-8 encoding defined in {{RFC3629}}.

~~~~ asn.1
PKIXCMP-2023
{ iso(1) identified-organization(3) dod(6) internet(1)
Expand Down