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

[Deb Cooley <[e-mail]>]

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:

“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.

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) <[e-mail]>
wrote:

> Yes Deb, it did get lost in the shuffle.
>
>
>
> See inline.
>
>
>
>
>
> *From:* Acme <[e-mail]> *On Behalf Of *Deb Cooley
> *Sent:* 19 March 2021 18:46
> *To:* [e-mail]
> *Cc:* Cooley, Dorothy E <[e-mail]>
> *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
>