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

[Deb Cooley <[e-mail]>]

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