Subject: [lamps] EKUs reused in draft-ietf-lamps-cmp-updates

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 28 Apr 2021 06:20:13 +0000

David, Steffen, and I sit together last week and discussed the comments from Tomas Gustavsson on the usage of EKUs for CA and RA in CMP Updates.

Tomas questioned if id-kp-cmcCA is required in addition to id-kp-cmcRA. We briefly discussed this also at IETF110. In the meantime we looked closer at RFC 8756 and other RFCs where these EKUs are used.

To sort things out, we considered the following use cases regarding possible use of EKUs in the scope of the Lightweight CMP Profile:

- caPubs

  The sender of the response containing the new root CA certs in caPubs must be properly authenticated and authorized to provide such new root CA certs. The EKUs will not help with this authorization, but an out-of-band authorization independent of the new root CA is needed, protecting the response message using e.g., a signature of a dedicated CA or using MAC protection with some shared secret.

- Central key generation

  The instance generating the new key pair should be properly authenticated, as it knows the private key of the EE. The EKU id-kp-cmKGA is introduced for this purpose.

- RA authorization

  To provide a proof that the sending entity is an RA that performed required checks of the messages, the EKU id-kp-cmcRA could be used.

  This could be useful especially for nested messages, batches or messages with an additional signature, or messages where the RA replaced the original protection with its own signature.

- Authorization of response messages

  CMP response messages do not need specific authorization, as the content of the messages, except when transferring new root CA certs using caPubs, are mainly signed objects that do not need to be trusted directly, e.g., newly issued certs, CA certs, root CA updates. The content that is not self contained signed objects are the CMP message header content and certificate request templates. Theses are additionally protected by the CMP message protection, but we see no additional risk whether the response is protected by the CA or RA. It is  up to the local PKI policy, if this differentiation is required or not, e.g., see NIST Suite B CMC profile in RFC 8756.

Our concluding of this is:

- We specify the new EKU id-kp-cmKGA in Updates CMP. Regarding id-kp-cmcCA and id-kp-cmcRA we only refer to the specification of RFC 6402.

- In Lightweight CMP Profile we specify the use of id-kp-cmKGA for central key generation and id-kp-cmcRA for RA authorization. The usage of these EKUs will be recommended, but the option, like in RFC 8756, to authorize the certificate of a PKI management entity may also be done through the local configuration.

Is there any feedback or change requests from the WG on theses changes?

We plan to implement the changes in the next version of the drafts.

Hendrik

With best regards,
Hendrik Brockhaus

Siemens AG
T RDA CST SEA-DE
Otto-Hahn-Ring 6
81739 Muenchen, Germany
Tel.: +49 89 780522411
Mobile: +49 174 1517765
mailto:[email-masked]
www.siemens.com<https://siemens.com>
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Apr 2021 12:18:50 -0400

Hendrik:

This analysis seems to be sufficient and reasonable.  Does anyone see a case that was not adequately considered?

Russ

> On Apr 28, 2021, at 2:20 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> mailto:[email-masked] <mailto:[email-masked]>
> www.siemens.com <https://siemens.com/>
> _______________________________________________
> Spasm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>