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 auseful
optimization when ACME is used to issue certificates for largenumbers 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 retur
