Subject: Re: [lamps] RFC8994/8995 requirements for CSRattr

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Sep 2021 13:29:55 -0400

I started a github/kramdown for this work and invited Toerless and Dan.

I think that having a 6-10 examples would be helpful for the document.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: David von Oheimb <[email-masked]>
Date: Wed, 1 Sep 2021 15:20:01 +0200

In my view, the idea recently brought up here (namely, to open a further
channel between RA(s) and CA(s)
besides the regular enrollment protocol just to be able to convey some
extra data to insert in the certificate)
is not good at all. It would be needlessly cumbersome and most likely
would not become generally accepted.

Instead, the extra data should be communicated as part of the (possibly
corrected/extended) existing enrollment protocol.
As far as EST is concerned, I'm glad to see that it has been decided to
update/correct the CSRattrs mechanism of RFC 7030.

    David

On 30.08.21 09:40, Eliot Lear wrote:
>
> I would suggest that it helps in these cases to back up to the
> scenarios we care to address, and the likelihood of success.  In some
> cases, it will be possible to coordinate development with the
> endpoints and sometimes with the CAs.  The CAs may not be strongly
> motivated to standardize an out-of-band/underlay RA/CA interface- some
> already have proprietary versions, and may like that with the hope of
> locking in the endpoints along the way.
>
> Eliot
>

On 30.08.21 01:31, Dan Harkins wrote:
>
>   Hi Michael,
>
>   Why can't the RA signal to the CA whatever things it things should
> be included in the CA, in addition to the goo provided in the client's
> CSR? If the Registrar knows the name then why can't it provide it to
> the CA. It will be providing the CSR to the CA, on behalf of the client,
> so why can't it say "oh by the way, add this name for the pledge...."
>
>   Why don't you want to define _that_ signalling instead of overloading
> a different protocol?
>
>   Dan.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 1 Sep 2021 15:29:35 +0200

David,

I mention that point because we already done this in one case with a CA, 
and my concern is that our code will bloat as we have to customize to 
other CAs.  It's a matter of whether you think you can influence the end 
devices or the CAs, and there are a lot more of the former than the 
latter.  I really don't have a crystal ball here.  If we can get code 
implemented on clients, keeping this to the RAs and endpoints would be 
great.  But that means that the client interfaces all need the code.  
And today, it's simply not there for many of them.  They have either 
ruby or python or go and a bit of devkit to match.

Eliot

On 01.09.21 15:20, David von Oheimb wrote:
>
> In my view, the idea recently brought up here (namely, to open a 
> further channel between RA(s) and CA(s)
> Instead, the extra data should be communicated as part of the 
> (possibly corrected/extended) existing enrollment protocol.
> As far as EST is concerned, I'm glad to see that it has been decided 
> to update/correct the CSRattrs mechanism of RFC 7030.
>
>     David
>
>> motivated to standardize an out-of-band/underlay RA/CA interface- 
>> some already have proprietary versions, and may like that with the 
>> hope of locking in the endpoints along the way.
>>
>> Eliot
>>
>

---

From: David von Oheimb <[email-masked]>
Date: Wed, 1 Sep 2021 15:47:58 +0200

Elliot,

good point that modifying things on the RA-CA channel affects fewer
implementations/devices than updates on the EE-RA channel.

A further way to avoid opening a second channel between the RA and CA is
not to augment the EE-RA channel
is to improve the existing RA-CA channel in a way that is already
covered by standards.

For instance, when using CMP or CMS in this channel, the RA can inject
new CSR fields  (or modify anything in the CSR) as follows.
The RA (Registrar) verifies the proof-of-origin and proof-of-possession
of the CSR received from the EE (Pledge).
The RA builds up a new CSR with all the contents it wishes to take over
and adds/modifies whatever it wishes.
The RA signs this CSR (which is on behalf of the EE) with its own key
material, asserting that it verified the PoP etc.

Sure in this way the original PoP is broken up, but if required the
original CSR could be sent along with the modified one.
Anyway, the RA needs to be an entity trusted by the CA, so it should not
be a problem that it re-builds the CSR.,

    David

---

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Sep 2021 10:17:24 +0200

Hi David,

Good way to have described the situation, and the one comment you added 
about e2e validation of EE<->CA to me is something that seems worthy of 
discussion.

Eliot

On 01.09.21 15:47, David von Oheimb wrote:
> A further way to avoid opening a second channel between the RA and CA 
> is not to augment the EE-RA channel
> The RA (Registrar) verifies the proof-of-origin and 
> proof-of-possession of the CSR received from the EE (Pledge).
> The RA builds up a new CSR with all the contents it wishes to take 
> over and adds/modifies whatever it wishes.
> Anyway, the RA needs to be an entity trusted by the CA, so it should 
> not be a problem that it re-builds the CSR.,
>
>     David
>
>
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2021 13:00:19 -0400

I'm unclear if CMP allows for a standardized way to override the CSR
contents, or if it simply provides more authority for the RA to create a new
CSR of its own.

While I would also prefer to enhance the RA/CA protocol, I'm not entirely
keen on mechanisms that break the original PoP.

Anyway, we are going to enhance the CSRattr description to support all the requirements.

---

From: Dan Harkins <[email-masked]>
Date: Fri, 03 Sep 2021 10:35:30 -0700

Hello,

> contents, or if it simply provides more authority for the RA to create a new

   Well not really override, more like augment. As I understand it, the 
device
in this case does not know the subjectAltName that the RA wants to be 
included
in the CSR so it's unlikely that the CSR would have a subjectAltName 
(assuming
the RA didn't ask for one in the CSRAttrs) that would need to be 
overridden.

   But I'm not clear about what CMP allows either so there's that.

> keen on mechanisms that break the original PoP.

   Agreed, but keep in mind that the CA has no idea whether the 
challengePassword
field is correct or not so the assurance that the CA has that it is 
really this
device that produced the CSR is through the RA vouching for it. The RA 
does the
due diligence that the CA requires to issue a certificate. That being 
the case,
how much is lost through the RA vouching for the entire thing?

> Anyway, we are going to enhance the CSRattr description to support all the requirements.

   Indeed. So it's probably moot anyway.

   I really think the more elegant solution would be the RA augmenting 
the CSR with
a little bit of goo. But that requires CAs to understand augmented CSRs 
that have
goo and there are practical considerations to rolling out a solution 
here that compel
the use of CSRAttrs.

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2021 16:08:33 -0400

{Trimming massive CC to just lists}

Dan Harkins <[email-masked]> wrote:
    >> While I would also prefer to enhance the RA/CA protocol, I'm not
    >> entirely keen on mechanisms that break the original PoP.

    > challengePassword field is correct or not so the assurance that the CA
    > has that it is really this device that produced the CSR is through the
    > RA vouching for it. The RA does the due diligence that the CA requires
    > to issue a certificate. That being the case, how much is lost through
    > the RA vouching for the entire thing?

In the ACME/RFC8555 case, it seems to me that the CA could provide a challengePassword.
I don't believe that this occurs today, but it seems like we ought to
anticipate this as a future event.

    > the CSR with a little bit of goo. But that requires CAs to understand
    > augmented CSRs that have goo and there are practical considerations to
    > rolling out a solution here that compel the use of CSRAttrs.

I agree.  I'd like to see a RA->CA protocol that augments rather than replaces.
I agree that this takes time, but

---

From: David von Oheimb <[email-masked]>
Date: Sun, 5 Sep 2021 15:09:11 +0200

> contents, or if it simply provides more authority for the RA to create a new
CMP does not offer a direct/explicit "override" mechanism for CSRs, but
it is foreseen that an RA checks a CSR and then modifies it, using the
RAVerified option instead of the typical signature-based PoP.
This is one of the use cases we describe in more detail in our new
Lightweight CMP profile - see
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-5.2.3.2
BTW, CMP also offers a variety of further forms of PoP, for keys that do
not have the capability for signing - see
https://datatracker.ietf.org/doc/html/rfc4210#section-5.2.8.4
<https://datatracker.ietf.org/doc/html/rfc4210#section-5.1.3.4>

With EST this is not possible simply because it uses the rather limited
PKCS#10 format, which requires self-signature, which is not possible at
the RA (even for keys that can be used for signing) because it does not
have the needed private key. In other words, PKCS#10 and thus EST does
not support on-behalf CSRs.

> While I would also prefer to enhance the RA/CA protocol, I'm not entirely keen on mechanisms that break the original PoP.
Yeah, I also prefer avoiding this - as long as the overhead to the EEs
is bearable.

For cases where the PoP is broken by an intermediate entity, CMP cert
request message may contain the original (unmodified) CSR for reference
purposes - see https://datatracker.ietf.org/doc/html/rfc4210#section-5.1.3.4

> Anyway, we are going to enhance the CSRattr description to support all the requirements.

Good to have this option then in the future.

    David

---

From: David von Oheimb <[email-masked]>
Date: Sun, 5 Sep 2021 15:41:51 +0200

On 03.09.21 19:35, Dan Harkins wrote:
>    Well not really override, more like augment. As I understand it, the device
> in this case does not know the subjectAltName that the RA wants to be included
> in the CSR so it's unlikely that the CSR would have a subjectAltName (assuming
> the RA didn't ask for one in the CSRAttrs) that would need to be overridden.
I'd say it does not matter whether one calls this 'override' or 'augment'.
The point is that the contents of the cert template in the CSR are
modified (regardless in which way, by changing or adding values).

> But I'm not clear about what CMP allows either so there's that.

I answered this point in the email just sent.

>    Agreed, but keep in mind that the CA has no idea whether the challengePassword
> field is correct or not so the assurance that the CA has that it is really this
> device that produced the CSR is through the RA vouching for it.

Right.

BTW, the use of the challengePassword in EST (and SCEP) is another
weakness - this way the proof-of-orgin crucially depends on its value
not leaking.
The design would have been much more robust if MAC-based protection had
been used instead, as offered, among others, by CMP.

> The RA does the due diligence that the CA requires to issue a certificate. That being the case,
I agree there is not much lost - as I wrote before, the RA needs to be
trusted by the CA anyway.

Yet note that using PKCS#10 (as done by EST and SCEP), an on-behalf CSR
is not possible simply because the CSR is required to be self-signed,
which cannot be done by the RA not having the private key of the EE.

>    Indeed. So it's probably moot anyway.

Yep.

> I really think the more elegant solution would be the RA augmenting the CSR with
> a little bit of goo. But that requires CAs to understand augmented CSRs that have
> goo and there are practical considerations to rolling out a solution here that compel
> the use of CSRAttrs.
I don't agree this is elegant. It requires a secondary protocol between
RA and CA just because EST (at least in its current form) is too limited.
In my view it is more straightforward and future-proof to correct the
EST CSRattrs mechanism and/or to use an existing more capable protocol
between RA and CA.

Regards,

    David

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 6 Sep 2021 07:18:12 +0000

The most popular options that I encounter in the wild right now, and for the last 10 years or so, for augmenting RA->CA:

  *   CMP CRMF requests using raVerified POP (used quite a lot)
  *   REST or SOAP API transporting the original PKCS#10, augmenting outside of the CSR (used even more)

The drive today is clearly towards using some sort of REST API. There is no standard for this of course, perhaps ACME is the closest to a standardized REST API you get today?

Regards,
Tomas

________________________________
From: Spasm <[email-masked]> on behalf of David von Oheimb <[email-masked]>
Sent: Sunday, September 5, 2021 3:09 PM
To: Michael Richardson <[email-masked]>; Eliot Lear <[email-masked]>; Dan Harkins <[email-masked]>; Owen Friel <[email-masked]>; Peter van der Stok <[email-masked]>; max pritikin <[email-masked]>; Toerless Eckert <[email-masked]>; Esko Dijk <[email-masked]>; [email-masked] <[email-masked]>; Thomas Werner <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [lamps] [Anima] RFC8994/8995 requirements for CSRattr

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

CMP does not offer a direct/explicit "override" mechanism for CSRs, but it is foreseen that an RA checks a CSR and then modifies it, using the RAVerified option instead of the typical signature-based PoP.
This is one of the use cases we describe in more detail in our new Lightweight CMP profile - see https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-5.2.3.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile%23section-5.2.3.2&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472820632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fkIbEPvkQxAsRhNmOORlU7btYOJz0l1kpArTpQp8KZQ%3D&reserved=0>
BTW, CMP also offers a variety of further forms of PoP, for keys that do not have the capability for signing - see https://datatracker.ietf.org/doc/html/rfc4210#section-5.2.8.4
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-5.2.8.4&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472820632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iVEmOILg4eP%2Btz0gY%2FkHJ1WSml9Q2%2B45eEKANCoLxug%3D&reserved=0><https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-5.1.3.4&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472830590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lOtKL1bozHRud9CSGiP5nbyj9X%2FefeTx4eGYeXWDkgo%3D&reserved=0>

With EST this is not possible simply because it uses the rather limited PKCS#10 format, which requires self-signature, which is not possible at the RA (even for keys that can be used for signing) because it does not have the needed private key. In other words, PKCS#10 and thus EST does not support on-behalf CSRs.

Yeah, I also prefer avoiding this - as long as the overhead to the EEs is bearable.

For cases where the PoP is broken by an intermediate entity, CMP cert request message may contain the original (unmodified) CSR for reference purposes - see https://datatracker.ietf.org/doc/html/rfc4210#section-5.1.3.4<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-5.1.3.4&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472830590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lOtKL1bozHRud9CSGiP5nbyj9X%2FefeTx4eGYeXWDkgo%3D&reserved=0>

    David

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Sep 2021 08:39:55 -0400

Tomas Gustavsson <tomas.gustavsson=[email-masked]> wrote:
    > The most popular options that I encounter in the wild right now, and
    > for the last 10 years or so, for augmenting RA->CA:

    >   * CMP CRMF requests using raVerified POP (used quite a lot)

understood.

    > The drive today is clearly towards using some sort of REST API. There
    > is no standard for this of course, perhaps ACME is the closest to a
    > standardized REST API you get today?

Yes, I'd say so.