Hi!
I performed an AD review of draft-ietf-acme-integrations-10. Thanks for this
information document to should the broad applicability of ACME. My feedback is
as follows:
** Section 1. Editorial clarity.
OLD
Optionally, ACME for subdomains [I-D.ietf-acme-subdomains] offers a
useful optimization when ACME is used to issue certificates for large
numbers of devices;
NEW
Optionally, ACME for subdomains [I-D.ietf-acme-subdomains] offers a useful
optimization when ACME is used to issue certificates for large numbers of
devices in the same domain;
** Section 2. Editorial. The definition of subdomain uses explicit quotes
around text from RFC1034. However, label comes verbatim of RFC8499, why not
quotes around it?
** Section 3 - 6. All of the reference flows appear to use dns-01 challenge
types. Are others possible? Even if not, please explicitly say that this
challenge type is being used.
** Section 4. Editorial. Consider introducing the MASA somewhere in the
narrative text prior to the figure as this is a new entity in the typical ACME
flows.
** Section 5.
In the example
illustrated here, the extension to [RFC8366] Vouchers which is
defined in [I-D.ietf-anima-brski-cloud],
-- Editorially, that [RFC8366] doesn't work. Should it be after "Vouchers"?
-- I'm not following the RFC8366 link. The data flow seems consistent with
Section 4.2 of [I-D.ietf-anima-brski-cloud]
** Section 6. I don't have the full history on draft-ietf-eap-teap-brski.
However, it seems unusual to be effectively specifying an applicability
statement for an expired, unadopted draft. Is there significant usage of this
draft in the field? What's the motivation?
** Section 6. Typo. s/STEP 2: Establsh/STEP 2: Establish/
** Section 6. Diagram
Step 2 is "Establish Outer Tunnel". Isn't the last step of it the follow
(i.e., the client responding back with the Result TLV= Success.
| EAP-Response/ | | |
| Type=TEAP, | | |
| {Crypto-Binding TLV, | | |
| Result TLV=Success} | | |
|------------------------>|
However, the following is being shown as the last step:
| EAP-Request/ | | |
| Type=TEAP, | | |
| {Request-Action TLV: | | |
| Status=Failure, | | |
| Action=Process-TLV, | | |
| TLV=CSR-Attributes, | | |
| TLV=PKCS#10} | | |
|<------------------------|
** Section 7.1.
It
is expected that the EST RA or TEAP servers that the client sends
certificate enrollment requests to are operated by the organization
that controls the domains.
Is this the same as saying that this integration architecture _requires_ that
the EST RA/TEAP server be operated by the organization that controls the
domains? The current text seems a ambiguous.
** Section 7.1
If the client sends a certificate enrollment request for an
identifier in a domain that the EST RA or TEAP server does not have
operational control over, the server SHOULD reject the request with a
suitable error immediately, and not send a certificate enrollment
request to the ACME server.
What is the circumstance where the server would honor the request for a domain
it doesn't control (i.e., why not "server MUST reject")?
** Section 7.5. Typo. Wrong case.
-- s/section 6.7/Section 6.7/
-- s/section 4.2.3/Section 4.2.3/
-- s/section 4.2.6/Section 4.2.6/
** Section 7.5.
If a client sends a certificate enrollment request to an EST RA for
an identifier that the RA does not control, the RA SHOULD respond
with a suitable 4xx HTTP [RFC9110] error code, and SHOULD NOT send an
enrollment request to the ACME server.
-- This guidance appears to weaken the guidance given in Section 4.2.3 of
RFC7030:
The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616]
error code when a problem occurs.
-- Under what circumstance would the RA send a request to the ACME server for
an identity it doesn't control? Why isn't this behavior strictly forbidden?
** Section 7.5. Similar line of questions for TEAP as with EST.
If a client sends a certificate enrollment request to a TEAP server
for an identifier that the TEAP server does not control, the TEAP
server SHOULD respond with an Error TLV with error code 1024 Bad
Identity In Certificate Signing Request, and SHOULD NOT send an
enrollment request to the ACME server.
-- Is this behavior suggesting that TEAP server could silently ignore requests
by returning no error? Can the circumstance behind that design choice be
explained?
-- As above. Why propagate a bad required to the ACME server?
** Section 9.1
As many ACME servers have per-day, per-IP and per-subjectAltName
limits, it is prudent not to request identical certificates too
often. This could be due to operator or installer error, with
multiple configuration resets occurring within a short period of
time.
-- Is this commenting on the operational practices of current, public ACME
servers? Would this apply (assuming they are used) private servers? Servers
an organization has a contractual/provisioned/SLA-based relationship?
-- If requests are spaced out, isn't the value of the using the efficiency of
the sub-domain technique less relevant?
** Section 10. There are no normative references in this document despite
RFC2119-style language being made about compliance to those documents. I
appreciate that this is an informational document, but it still needs normative
references to the specs it is building upon. See
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/.
Please do a more deliberate sweep, but minimally, the following need to be
normative: [I-D.ietf-acme-subdomains], [I-D.ietf-anima-brski-cloud],
[I-D.ietf-lamps-rfc7030-csrattrs], [I-D.ietf-uta-use-san],
[I-D.lear-eap-teap-brski], [RFC2119], [RFC8555], [RFC8995], [RFC7170],
[RFC7030], [RFC9110], [RFC8174].
Thanks,
Roman
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
