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

[Deb Cooley <[e-mail]>]

Did anyone see this?  Or did it get lost in the shuffle?

Deb Cooley

On Fri, Mar 19, 2021 at 6:46 AM Deb Cooley <[e-mail]> wrote:

> 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]
>
> 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]
>
> 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.]
>
> 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?
>
>
> Deb Cooley, NSA
>