Subject: [lamps] Generalizing the CMP "Get CA certificates" use case

From: David von Oheimb <[email-masked]>
Date: Wed, 17 Nov 2021 12:07:30 +0100

After discussion among the authors of the CMP Updates draft,
we propose a small but critical last-minute extension of the general 
messages supporting "Get CA certificates" use case described in the 
draft, section 2.13.

This general message can be used by an EE to request an arbitrary set of 
CA certificates from an RA and is protected independently of the 
conveyed CA certificates.
So far we restricted this to conveying intermediate CA and issuing CA 
certs, but  we see value add to allow also (to-be-trusted) root CA 
certs, with suitable caveats.
Therefore, we would like to extend the getCaCerts support message to 
enable conveying also root CA certs, for any (also possibly unrelated) 
CA hierarchies.
This can be used, for instance, to provide CA certificate chains 
including their root (in the form of a self-signed certificate)
and to provide end entities, as a kind of configuration update, with 
trust anchors that may be needed to verify certificates of third-party 
peers.

What do think about the following suggested changes?

      *Change in section 2.13 "New Section 5.3.19.14 - CA Certificates":*

        *OLD*

    This MAY be used by the client to get the current CA intermediate 
andissuing CA certificates.

        *NEW*

This MAY be used by the client to obtain CA certificates.

      *Replace section 2.23 as follows:*

        *OLD*

2.23  Add Section 8.6 - Trust anchor provisioning using caPubs

    The following subsection addresses the risk arising from 
provisioning    a new trust anchor in-band in a CMP management 
operation.    Insert this section after new Section 8.5:

    8.6.  Trust anchor provisioning using caPubs

    In case an EE receives a CA certificate in the caPubs field for   
installation as a new trust anchor, it is advised to properly
    authenticate the message and authorize the sender as trusted 
source   of the new trust anchor.  This authorization is typically indicated
    using shared secret information for protecting an initialization   
response (ir) message.  Authorization can also be signature-based
    using a certificate issued by another PKI that is explicitly   
authorized for this purpose.  A certificate received in caPubs MUST
    NOT be accepted as trust anchor if the CMP message was protected   
using a certificate issued by this same CA or one of its subordinate
    CAs.

        *NEW*

2.23  Add Section 8.6 - Trust anchor provisioning using CMP messages

    The following subsection addresses the risk arising from in-band    
provisioning of new trust anchors in a PKI management operation.

    Insert this section after new Section 8.5:

    8.6.  Trust anchor provisioning using CMP messages

    A PKI management entity MUST NOT include to-be-trusted CA 
certificates   unless it can take full responsibility for making the 
client trust them.
    When doing so, 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 of a
    certificate response or in a general response (genp),a CA certificate for use   as a trust anchor, it MUST properly 
authenticate the message sender
     without already trusting any of the CA certificates given in the 
message.   Moreover, it MUST authorize the sender as a source of trust 
anchors.
    This authorization is typically indicated using shared secret 
information   or with a signature-based message protection using a 
certificate
    issued by a PKI that is explicitly authorized for this purpose.

     David

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 17 Nov 2021 14:07:48 +0000

>   8.6.  Trust anchor provisioning using CMP messages

   A PKI management entity MUST NOT include to-be-trusted CA certificates

   unless it can take full responsibility for making the client trust them.

I do not like this generalization.  It is very different to say “here are certificates you need to verify the certificate you are asking for/about” than to say “here are certificates you should trust.”

I am opposed.

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 17 Nov 2021 15:16:50 +0000

Sending trust anchors in caPubs is already something that is done in some use cases (3GPP I know about). I think the ability to do so is important, also in order to support trust anchor roll-over. Typically however I would say that is carried in caPubs in the certResp message at enrollment/renewal.

I don't like the tie-in to the solution though with

"A PKI management entity MUST NOT include to-be-trusted CA certificates

unless it can take full responsibility for making the client trust the"

It seems hard for a CA ( if that is the PKI mgmt entity) to take full responsibility for anything devices does, which may be controlled by other entities.

I think it's good to have the ability to transfer trust anchors, but perhaps:

"A PKI management entity MAY include to-be-trusted CA certificates for enabling clients to trust them"

Quite fuzzy, but this usage will be solution specific I believe.

________________________________
From: Spasm <[email-masked]> on behalf of Salz, Rich <rsalz=[email-masked]>
Sent: Wednesday, November 17, 2021 3:07 PM
To: David von Oheimb <[email-masked]>; [email-masked] <[email-masked]>
Cc: Brockhaus, Hendrik <[email-masked]>; Fries, Steffen <[email-masked]>; John Gray <[email-masked]>
Subject: Re: [lamps] Generalizing the CMP "Get CA certificates" use case

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [email-masked] with any questions.

I am opposed.

---

From: David von Oheimb <[email-masked]>
Date: Wed, 17 Nov 2021 16:18:54 +0100

Thanks Rich for your comment.

It is understood that conveying to-be-trusted certs is much more 
critical than just providing untrusted (intermediate) CA certs.
This is the very reason why we propose to include a carefully stated 
caveat for inclusion in the security considerations:

Note that there are various situations where a device/client needs to 
learn trust anchors, for instance when bootstrapping/updating its 
configuration.
This is why, for instance, also BRSKI (with its voucher mechanism) and 
EST (with /cacerts) support the provisioning of trusted certs.
And when an end entity anyway uses CMP for managing its certs (and 
optionally CRLs), why not also give it the possibility to use CMP also 
for getting new trust anchors?

> trust anchors that may be needed to verify certificates of third-party 

It is not constructive to just write "I am opposed"

  * without considering the motivation
  * without appreciating the caveats provided
  * without suggesting viable alternatives

     David

On 17.11.21 15:07, Salz, Rich wrote:
> I do not like this generalization.  It is very different to say “here 
> are certificates you need to verify the certificate you are asking 
> for/about” than to say “here are certificates you should trust.”
> I am opposed.
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: David von Oheimb <[email-masked]>
Date: Wed, 17 Nov 2021 16:36:38 +0100

On 17.11.21 16:16, Tomas Gustavsson wrote:

> Sending trust anchors in caPubs is already something that is done in 
> some use cases (3GPP I know about).
> I think the ability to do so is important, also in order to support 
> trust anchor roll-over.

Interesting to note this, which underlines the need for conveying 
to-be-trusted certs within CMP.

> Typically however I would say that is carried in caPubs in the 
> certResp message at enrollment/renewal.
Using caPubs makes sense for certs that are related to a cert currently 
being enrolled, but not so much for trust anchors not related to that cert.
Moreover, there can be situations where an end entity needs to get such 
trust anchors already before, or entirely independently of, enrolling 
itself to a PKI.

> It seems hard for a CA ( if that is the PKI mgmt entity) to take full 
> responsibility for anything devices does, which may be controlled by 
> other entities.

Although the suggested text uses the term "PKI management entity" for 
generality simply because this is the term typically used for RAs and CAs,
most likely it will not be a CA answering this type of request, but some 
RA or related service that is also responsible for EE configuration 
management.
This is what we had in mind with the last two sentences (where "it" is 
the EE receiving the message):

    Moreover, it MUST authorize the sender as a source of trust anchors.
    This authorization is typically indicated using shared secret 
information   or with a signature-based message protection using a 
certificate
    issued by a PKI that is explicitly authorized for this purpose.

> Quite fuzzy, but this usage will be solution specific I believe.
Hmm, but then the caveat is lost that the RA must do this in a 
responsible way.

Yet how about the following alternative for the first sentence of the 
paragraph:

    The sender, which typically is an RA that has some configuration 
management duties, MUST NOT include to-be-trusted CA certificates   
unless it can take full responsibility for making the client trust them.

     David

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 17 Nov 2021 15:38:47 +0000

Yes, that may be a better wording. I also like the stipulation that the client must authenticate the message before using any of the certificates in caPubs.
________________________________
From: David von Oheimb <[email-masked]>
Sent: Wednesday, November 17, 2021 4:36 PM
To: Tomas Gustavsson <[email-masked]>; [email-masked] <[email-masked]>
Cc: Brockhaus, Hendrik <[email-masked]>; Fries, Steffen <[email-masked]>; John Gray <[email-masked]>
Subject: Re: [lamps] Generalizing the CMP "Get CA certificates" use case

Sending trust anchors in caPubs is already something that is done in some use cases (3GPP I know about).
I think the ability to do so is important, also in order to support trust anchor roll-over.

Interesting to note this, which underlines the need for conveying to-be-trusted certs within CMP.

Typically however I would say that is carried in caPubs in the certResp message at enrollment/renewal.
Using caPubs makes sense for certs that are related to a cert currently being enrolled, but not so much for trust anchors not related to that cert.
Moreover, there can be situations where an end entity needs to get such trust anchors already before, or entirely independently of, enrolling itself to a PKI.

Although the suggested text uses the term "PKI management entity" for generality simply because this is the term typically used for RAs and CAs,
most likely it will not be a CA answering this type of request, but some RA or related service that is also responsible for EE configuration management.
This is what we had in mind with the last two sentences (where "it" is the EE receiving the message):

   Moreover, it MUST authorize the sender as a source of trust anchors.
   This authorization is typically indicated using shared secret information
   or with a signature-based message protection using a certificate
   issued by a PKI that is explicitly authorized for this purpose.

Quite fuzzy, but this usage will be solution specific I believe.
Hmm, but then the caveat is lost that the RA must do this in a responsible way.

Yet how about the following alternative for the first sentence of the paragraph:

    David

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 17 Nov 2021 16:21:53 +0000

*   It is not constructive to just write "I am opposed"

  *   without considering the motivation
I do understand the motivation.

  *   without appreciating the caveats provided
I do not think the caveats are workable, similar to how Tomas objected.

  *   without suggesting viable alternatives
This is wrong.  It is quite acceptable to say that we should not do this because of security concerns. We are not obligated to solve every use-case; we never do. As you pointed out there are other protocols that already meet this need.
I stand by my message.

---

From: John Gray <[email-masked]>
Date: Wed, 17 Nov 2021 17:08:44 +0000

Thanks for your comments Rich!   It was good to meet you virtually at IETF 112 (I was in the newcomer meetings if you remember).    Your experience is greatly appreciated!

I am not clear what you are opposed to Rich, the proposed new text (with more generalization), or the whole new section 8.6?

Where you okay with the text from draft 13?

OLD

   authenticate the message and authorize the sender as trusted source
   of the new trust anchor.  This authorization is typically indicated

You pointed out issues with the next text:

NEW

   When doing so, 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 of a

   certificate response or in a general response (genp), a CA certificate for use

   as a trust anchor, it MUST properly authenticate the message sender

   without already trusting any of the CA certificates given in the message.

I ask because the generalization in the newer text doesn’t seem all that different (to me) than the text from draft 13 except it allows the CA certs to be retrieved in certificate response or genp messages.   If you are okay with the older text, can you explain what is wrong with the newer text?  Is it because there is a security issue with allowing a root certificate to come down in a genp message?   It looks like the same security caveats are in place for both the older draft and newer draft, so is there another gap we haven’t noticed?

Your input is greatly appreciated.

John Gray
Entrust

From: Salz, Rich <[email-masked]>
Sent: Wednesday, November 17, 2021 11:22 AM
To: David von Oheimb <[email-masked]>; [email-masked]
Cc: Brockhaus, Hendrik <[email-masked]>; Fries, Steffen <[email-masked]>; John Gray <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] Generalizing the CMP "Get CA certificates" use case

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________

  *   without suggesting viable alternatives
This is wrong.  It is quite acceptable to say that we should not do this because of security concerns. We are not obligated to solve every use-case; we never do. As you pointed out there are other protocols that already meet this need.
I stand by my message.
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 17 Nov 2021 17:19:09 +0000

Rich, Tomas

Many thanks for your feedback on our proposal.
I share the concerns and I also believe that we do not have to solve all problems. This is the reason why we believe that we should not specify the bootstrapping of additional root CA certificates outside the enrollment to a new PKI as performed by the initialization request/response using caPubs. Therefore, we do not specify this as part of Lightweight CMP Profile.

This change is only about CMP Updates. Technically it is possible to transport any unrelated root CA certificates using the Get CA Certificates general message. We believe that people will sooner or later make use of this capability. EST /cacerts offers this functionality as well and we know that people use it to also provide further root CA certs. Therefore, we think it is better to clearly state the respective security considerations than ignoring this functionality. This is the reason why we propose this change.

Hendrik

Von: Salz, Rich <[email-masked]>
Gesendet: Mittwoch, 17. November 2021 17:22
An: David von Oheimb <[email-masked]>; [email-masked]
Cc: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; Fries, Steffen (T RDA CST) <[email-masked]>; John Gray <[email-masked]>
Betreff: Re: [lamps] Generalizing the CMP "Get CA certificates" use case

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 17 Nov 2021 17:26:40 +0000

*   Thanks for your comments Rich!   It was good to meet you virtually at IETF 112 (I was in the newcomer meetings if you remember).    Your experience is greatly appreciated!

As is yours from a vendor :)

  *   I am not clear what you are opposed to Rich, the proposed new text (with more generalization), or the whole new section 8.6?

I do not like the generalization. The rest doesn’t thrill me, but I don’t think I’ll object too strongly now.  I reserve the right to change my mind once I have more time to read the drafts.