Subject: Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 8 Jun 2021 16:05:58 +0000

Yes Deb, it did get lost in the shuffle.

See inline.

From: Acme <[email-masked]> On Behalf Of Deb Cooley
Sent: 19 March 2021 18:46
To: [email-masked]
Cc: Cooley, Dorothy E <[email-masked]>
Subject: [Acme] comments on: draft-ietf-acme-integrations-03.txt

I thought this draft was pretty easy to follow, and I just have a few minor comments.  Note:  I am probably reviewing this from the point of view of an integrator (maybe?) definitely not as a device developer, and not as a CA developer.
Section 1, sentence after bullets and Section 4, paragraph 1:  Section 1 used “enrolment” while Section 4 used “enrollment”.  Pick one.  Use it everywhere.
[ofriel] Sure, will fixup.
Section 3, 4 and 5 call flow:  both cases show the ACME CA returning a PEM, while the EST RA returns a PKCS#7 to the device.  Is this intentional?  Are you expecting the EST Server to convert the certificate from PEM to PKCS 7, and is the PKCS7 a .p7b or .p7c.  [note:  these are trivial conversions, but they are also very confusing to most people]
[ofriel] That’s a fair point. We could reference https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 and state that EST server may request ACME certs using "application/pkcs7-mime" and that would avoid a transcoding operation when the EST downloads the cert from ACME.
From an architecture point of view, do you expect the EST Server to be run by the requesting organization?  Or by the CA owner – or is this not even possible?  [from a ‘domain control’ point of view]
[ofriel] We think this should be run by the organization that owns the domain, and then the EST RA can request certs from the ACME CA which could be run by a different org.
Again architecture:  If the EST Server sits in front of a large organization, then domain validation is more interesting, and the Get /csrattrs may or may not be able to recommend a SAN, right?  I can see that policy oids could be provided, if that is a thing in these systems.  [we use policy oids in US DOD, but that is possibly uncommon elsewhere.]
[ofriel] That is also a fair point, for complex deployments its not clear what policy the EST server may want to apply before assigning a SAN. The text in section 3 currently states:
“EST servers could use this mechanism to tell the client  what fields to include in the CSR Subject and Subject Alternative  Name fields”
We could beef up that statement and explicitly state that the policy by which the EST determines the SAN to specify is explicitly out of scope. And also note that policy OIDs could be provided.

Section 8.1, para 3:  What does ‘The cache should be keyed by the complete contents of the CSR’ mean?  The word ‘keyed’, I think, is the problem.  Maybe ‘indexed’?  Unless the cache is encrypted?
[ofriel] Yes “indexed” is better and less confusing.

Deb Cooley, NSA

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Jun 2021 16:15:33 -0400

Owen Friel \(ofriel\) <ofriel=[email-masked]> wrote:
    deb> Again architecture:  If the EST Server sits in front of a large
    deb> organization, then domain validation is more interesting, and the
    deb> Get /csrattrs may or may not be able to recommend a SAN, right?  I
    deb> can see that policy oids could be provided, if that is a thing in
    deb> these systems.  [we use policy oids in US DOD, but that is possibly
    deb> uncommon elsewhere.]

    ofriel> That is also a fair point, for complex deployments its not clear
    ofriel> what policy the EST server may want to apply before assigning a
    ofriel> SAN. The text in section 3 currently states:

    “EST servers could use this mechanism to tell the client  what fields to
    include in the CSR Subject and Subject Alternative  Name fields”

    ofriel> We could beef up that statement and explicitly state that the
    ofriel> policy by which the EST determines the SAN to specify is
    ofriel> explicitly out of scope. And also note that policy OIDs could be
    ofriel> provided.

I would love to hear from operators and designers of CAs about how a
RA can communicate to the CA about things it doesn't like, or wishes to add,
to a certificate request.

The CSR is immutable, being signed by the EE requesting.
ACME doesn't provide any out-of-CSR mechanism, nor does CMC or CMP (correct
me if I'm wrong here!)...  Max and I talked a lot about this when design RFC8995,
and we had to conclude that it was simply non-standard.

In the case of ACP (RFC8994) use of BRSKI, like the Ford Model-T, the CSR may
contain anything the Pledge wants to put in, it will get an otherName
containing the encoded ACP IPv6 ULA.

In implementing, I also realized that the GET /csrattrs is pseudo-idempotent.
When first called, it needs to allocate an IPv6 ULA for that node, and it
needs to store it, such that whenever the same IDevID does the GET, it gets
the same answer.  It's uncomfortable having to change database state on a
GET, but at least the result is cachable!

In the ACME integrations, we haven't said how the RA will decide what dNSName
SAN will be returned, but the same property will apply.  The RA needs to
collect a CSR that it can pass along up ACME, and for which is can do dns-01
challenges.

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

---

From: Deb Cooley <[email-masked]>
Date: Thu, 10 Jun 2021 05:43:53 -0400

I've just picked the parts that I want to respond to, hopefully this isn't
confusing:

snip.......

Section 3, 4 and 5 call flow:  both cases show the ACME CA returning a PEM,
while the EST RA returns a PKCS#7 to the device.  Is this intentional?  Are
you expecting the EST Server to convert the certificate from PEM to PKCS 7,
and is the PKCS7 a .p7b or .p7c.  [note:  these are trivial conversions,
but they are also very confusing to most people]

[ofriel] That’s a fair point. We could reference
https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 and state that
EST server may request ACME certs using "application/pkcs7-mime" and that
would avoid a transcoding operation when the EST downloads the cert from
ACME.

snip......

Deb:  you can't just use PEM everywhere?    RFC8555 pretty much says that
PEM is the default anyway?

snip.......

Again architecture:  If the EST Server sits in front of a large
organization, then domain validation is more interesting, and the Get
/csrattrs may or may not be able to recommend a SAN, right?  I can see that
policy oids could be provided, if that is a thing in these systems.  [we
use policy oids in US DOD, but that is possibly uncommon elsewhere.]

[ofriel] That is also a fair point, for complex deployments its not clear
what policy the EST server may want to apply before assigning a SAN. The
text in section 3 currently states:

We could beef up that statement and explicitly state that the policy by
which the EST determines the SAN to specify is explicitly out of scope. And
also note that policy OIDs could be provided.

snip.....

Deb:  don't go too crazy here.  You are pretty soft on the language 'could
use' isn't exactly requiring it, but merely allowing it.

Deb Cooley, NSA

On Tue, Jun 8, 2021 at 12:06 PM Owen Friel (ofriel) <[email-masked]>
wrote:

> *From:* Acme <[email-masked]> *On Behalf Of *Deb Cooley
> *Sent:* 19 March 2021 18:46
> *To:* [email-masked]
> *Cc:* Cooley, Dorothy E <[email-masked]>
> *Subject:* [Acme] comments on: draft-ietf-acme-integrations-03.txt
>
>
>
> I thought this draft was pretty easy to follow, and I just have a few
> minor comments.  Note:  I am probably reviewing this from the point of view
> of an integrator (maybe?) definitely not as a device developer, and not as
> a CA developer.
>
> Section 1, sentence after bullets and Section 4, paragraph 1:  Section 1
> used “enrolment” while Section 4 used “enrollment”.  Pick one.  Use it
> everywhere.
>
> Section 3, 4 and 5 call flow:  both cases show the ACME CA returning a
> PEM, while the EST RA returns a PKCS#7 to the device.  Is this
> intentional?  Are you expecting the EST Server to convert the certificate
> from PEM to PKCS 7, and is the PKCS7 a .p7b or .p7c.  [note:  these are
> trivial conversions, but they are also very confusing to most people]
>
> [ofriel] That’s a fair point. We could reference
> https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 and state
> that EST server may request ACME certs using "application/pkcs7-mime" and
> that would avoid a transcoding operation when the EST downloads the cert
> from ACME.
>
> From an architecture point of view, do you expect the EST Server to be run
> by the requesting organization?  Or by the CA owner – or is this not even
> possible?  [from a ‘domain control’ point of view]
>
> [ofriel] We think this should be run by the organization that owns the
> domain, and then the EST RA can request certs from the ACME CA which could
> be run by a different org.
>
> Again architecture:  If the EST Server sits in front of a large
> organization, then domain validation is more interesting, and the Get
> /csrattrs may or may not be able to recommend a SAN, right?  I can see that
> policy oids could be provided, if that is a thing in these systems.  [we
> use policy oids in US DOD, but that is possibly uncommon elsewhere.]
>
> [ofriel] That is also a fair point, for complex deployments its not clear
> what policy the EST server may want to apply before assigning a SAN. The
> text in section 3 currently states:
>
> We could beef up that statement and explicitly state that the policy by
> which the EST determines the SAN to specify is explicitly out of scope. And
> also note that policy OIDs could be provided.
>
>
>
> Section 8.1, para 3:  What does ‘The cache should be keyed by the complete
> contents of the CSR’ mean?  The word ‘keyed’, I think, is the problem.
> Maybe ‘indexed’?  Unless the cache is encrypted?
>

---

From: Deb Cooley <[email-masked]>
Date: Thu, 10 Jun 2021 05:52:09 -0400

Michael,

In my world (government PKI systems), the RA doesn't get to do that.
Either the CSR is accepted or it is rejected.  The CA has a profile it
follows, if the CSR is missing things, the CA adds them before the
certificate is signed.  The RA can do none of that.  In our case, most RAs
are actually people, so there can be a back channel to the requestor which
can be used to sort it all out.

How this all happens in the case of 'little things', I don't know.  We do
have a 'portal' for devices, but it would probably be quite 'heavy' for
your use cases.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Jun 2021 11:27:28 -0400

Deb Cooley <[email-masked]> wrote:
    > certificate is signed.  The RA can do none of that.
    
I suspected this was the case: that the override by RA was all theoretical.
However, in another thread, I was pointed to:

https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/acm-pca.html#ACMPCA.Client.issue_certificate

as an example of an RA->CA API.  But, upon reading it, it seems to really
just be a way to invoke the CA signing action via RPC.  Maybe that's a
quibble RPC vs protocol-level API.

    > In our case, most RAs

hah.  "civil serpents" ... which slither through the back channels of government.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 15 Jun 2021 06:50:55 +0000

Deb in your govt PKI world then, would the flow be something like:

There is no CSR Attributes exchange that allows the RA to tell the Pledge to use a particular CN/SAN.

Pledge sends CSR with, say, SAN=serialnumberx

RA sends newOrder with identifier= serialnumberx

ACME CA decides that the identity should be “serialnumberx.devices.some-gov-dept.example.org” (e.g. based on the RA identity)

ACME returns an authorization challenge for “serialnumberx.devices. some-gov-dept.example.org” to the RA.

The RA must then prove ownership of that DNS domain before the ACME CA will issue the cert.

This is how we envisaged the enterprise/civilian workflow:

RA owns the domain e.g. devices.ra.example.org

Pledge connects to RA using its IDevID and sends CSR Attributes request

RA extracts serial#=abc123 (or whatever) from IDevID and appends domain to it

RA tells pledge in CSR Attributes response to include e.g. SAN=abc123.devices.ra.example.org in CSR

Pledge sends CSR with SAN= abc123.devices.ra.example.org

RA sends newOrder with identifier= abc123.devices.ra.example.org

ACME returns an authorization challenge for abc123.devices.ra.example.org

RA proves ownership of abc123.devices.ra.example.org and ACME issues cert.

(or using acme-subdomains, proves ownership of devices.ra.example.org)

From: Deb Cooley <[email-masked]>
Sent: 10 June 2021 17:52
To: Michael Richardson <[email-masked]>
Cc: Owen Friel (ofriel) <[email-masked]>; [email-masked]; Cooley, Dorothy E <[email-masked]>
Subject: Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt

Michael,

In my world (government PKI systems), the RA doesn't get to do that.  Either the CSR is accepted or it is rejected.  The CA has a profile it follows, if the CSR is missing things, the CA adds them before the certificate is signed.  The RA can do none of that.  In our case, most RAs are actually people, so there can be a back channel to the requestor which can be used to sort it all out.

How this all happens in the case of 'little things', I don't know.  We do have a 'portal' for devices, but it would probably be quite 'heavy' for your use cases.

On Tue, Jun 8, 2021 at 4:15 PM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Owen Friel \(ofriel\) <ofriel=[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Sean Turner <[email-masked]>
Date: Mon, 21 Jun 2021 13:34:49 -0400

Sorry about getting to this 

> On Jun 8, 2021, at 16:15, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

CMC does define a Modify Certification Request Control (see https://datatracker.ietf.org/doc/html/rfc5272#section-6.5.1). Whether that is implemented is another story.