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

From: Deb Cooley <[email-masked]>
Date: Sun, 2 May 2021 06:23:24 -0400

Apologies - for not actually reading the CMP drafts.

I have some observations, which you can take or leave (given I haven't
actually read the draft).

1.  EKU and Central Key Gen:  Is this really a big step up from merely
signing a certificate request?  The CA 'can' sign any request - legit or
not.  If it signs an unauthorized request is this much different than
generating a key and signing a request?  If the CA is going to act poorly,
does this help?  Or do you really want to know as a RP whether the key was
locally generated vs. centrally generated?  If a CA does both use cases w/
a single signing key, the EKU will be there despite local generation. [I do
completely agree that any CA that does key generation needs to handle that
EE key appropriately]

2.  CA and RA EKUs:  My opinion is that CAs should have the CA EKU and RAs
should have the RA EKU.  If a CA does both then it can have just the CA EKU
or both.  I'm not sure what the issue was here.

Again, take these or leave them.  It is entirely possible that my lack of
understanding of CMP is an issue (for me, that is).

Deb Cooley
[email-masked] - which is cc'd.

On Wed, Apr 28, 2021 at 12:19 PM Russ Housley <[email-masked]> wrote:

> 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:
>
> 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] <[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
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 3 May 2021 08:15:45 +0200

On 2021-05-02 12:23, Deb Cooley wrote:
> generating a key and signing a request?  If the CA is going to act 
> poorly, does this help?  Or do you really want to know as a RP whether 
> the key was locally generated vs. centrally generated?  If a CA does 
> both use cases w/ a single signing key, the EKU will be there despite 
> local generation. [I do completely agree that any CA that does key 
> generation needs to handle that EE key appropriately]
> 
> 2.  CA and RA EKUs:  My opinion is that CAs should have the CA EKU and 
> RAs should have the RA EKU.  If a CA does both then it can have just the 
> CA EKU or both.  I'm not sure what the issue was here.

The issue I brought up is from an RP point of view. What difference will 
an RP do weather there is an EKU of CMC_CA or CMC_RA?
If it makes a difference to the RP, there must be some rules stipulating 
how the RP must handle these. If it does not make any difference to an 
RP I argue that it should then not be used because it introduced 
additional complexity and code that doesn't really do anything, which we 
have seen many times can lead to confusion, non-interoperability and 
even vulnerabilities.

> 
> Again, take these or leave them.  It is entirely possible that my lack 
> of understanding of CMP is an issue (for me, that is).
> 
> Deb Cooley
> [email-masked] <mailto:[email-masked]> - which is cc'd.
> 
> On Wed, Apr 28, 2021 at 12:19 PM Russ Housley <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     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]
>>     <mailto:[email-masked]>> wrote:
>>
>>     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____
>>     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]
>>     <mailto:[email-masked]>
>>     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____
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/spasm>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/spasm>
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 3 May 2021 09:56:21 +0000

Deb:

> Von: Deb Cooley <[email-masked]> 
>
> 1.  EKU and Central Key Gen:  Is this really a big step up from merely signing a certificate request?  The CA 'can' sign any request - legit or not.  If it signs an unauthorized request is this much different than generating a key and signing a request?  If the CA is going to act poorly, does this help?  Or do you really want to know as a RP whether the key was locally generated vs. centrally generated?  If a CA does both use cases w/ a single signing key, the EKU will be there despite local generation. [I do completely agree that any CA that does key generation needs to handle that EE key appropriately]
>

With central key generation the newly generated key package shall be wrapped in a SignedData object signed by the entity that generated the new keypair on behalf of the end entity that requested central key generation. Then this SignedData object is encrypted using EnvelopedData to send it to the responding entity.
The signature of the KGA is to let the end entity know who has knowledge of its private key. The EKU is a option to tell the end entity that this KGA, if not the CA itself, is authorized to perform central key generation for end entities.

Does this help with understanding the use case?

Hendrik