Hi!
I did an AD review of draft-ietf-acme-star-delegation-04. Thanks for this work
to apply the STAR profile (rfc8739). Below are my comments. There are a
number of editorial clarifications proposed below. The item that likely needs
some discussion is the syntax of the CSR template.
** Idnit:
** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659)
== Outdated reference: A later version (-04) exists of
draft-ietf-cdni-interfaces-https-delegation-03
-- Unexpected draft version: The latest known version of
draft-ietf-stir-cert-delegation is -02, but you're referring to -03.
** Section 1. Editorial. Missing preposition.
OLD
This document describes a profile of the ACME protocol [RFC8555] that
allows the NDC to request the IdO, acting as a profiled ACME server,
a certificate for a delegated identity
NEW
This document describes a profile of the ACME protocol [RFC8555] that
allows the NDC to request from the IdO, acting as a profiled ACME server,
a certificate for a delegated identity
** Section 2.2. Editorial. Recommend symmetry in naming of the orders and
being explicit on the order in question.
-- second from last bullet. s/reflected in the NDC order/reflected in Order 1
(i.e., the NDC Order)/
-- last bullet. s/moves its state to "valid"/moves the Order 1 state to
"valid"/
** Section 2.2. Should the buffering requirement for the CSR be normative -
s/The IdO must buffer/The IdO MUST buffer/
** Section 2.2. Per "[No identify validation]", what is meant by that?
** Section 2.3.1. Editorial. s/The IdO can delegate multiple names through
each NDC/The IdO can delegate multiple names to a NDC/
** Section 2.3.1. Are there any constraints to what the delegation URLs could
point to?
** Section 2.3.1. Per "The value of this attribute is the URL pointing to the
delegation configuration object that is to be used for this certificate
request", what is the error handling if the delegation attribute doesn't point
to a URL found in the delegations URL list?
** Section 2.3.2. It might be worth pointing out the obvious when clarifying
the properties of the Order objects such as:
-- That the value field will be the delegated name
-- The expected symmetry in field values between NDC-generated order object and
the one made by the IdO
** Section 2.3.2. Per "When the validation of the identifiers has been
successfully completed ...", it would be useful to clarify who is doing the
validation and when. Figure 1 suggests that there is only a validation process
between IdO client and CA server. However, wouldn't the IdO server be checking
the identifiers submitted by the NDC client too (prior to passing them to the
CA server too?
** Section 2.3.2 and 2.3.3. I didn't understand the titles used to organize
of content -- "Order Object on the NDC-IdO side" vs. "IdO-CA side". They
didn't follow the clear convention introduced by Figure 1 of NDC client, IdO
client, IdO server and CA server. Additionally, Section 2.3.2 discusses
behavior which seems to be IdO client-to-CA Server (which doesn't seem like
"NDC IdO side"). Additionally, Section 2.3.3. seems to be describing the
requirements that correspond to construction of the order sent to the CA which
is also covered at the end of Section 2.3.2.
** Section 2.4. Per "The authors believe that this is a very minor security
risk", it would be worth explicitly explaining that position (and not framed as
the belief of the authors)
** Section 2.5. This section introduces a new architectural element, ACME
Delegation server, but doesn't define it. Simply referencing the use cases in
Section 4.1.2 isn't enough as this section doesn't even use those words
("Delegation server").
** Section 2.5. Per "The "Location" header must be rewritten", it would be
useful to describe the new target.
** Section 3.1. There are some challenges with the template syntax.
-- Where is the normative format for the syntax? Section 3.1 points to
Appendix B which lists JSON schema whose format is specified "draft 7 of JSON
Schema, which may not be the latest version of the corresponding Internet Draft
[I-D.handrews-json-schema] at the time of publication". As far as I can tell
"draft 7 of JSON Schema" seems to resolve to
https://json-schema.org/specification-links.html which points back to
draft-handrews-json-schema. This draft appears to be an expired, individual
draft codifying. This ambiguity and lack of stable reference is problematic.
-- Accepting the Json schema as is, there is no annotation on the fields. The
field names very much look like X.509 fields but the text provides no guidance
on how they should be interpreted to create a CSR beyond explaining "**", "*"
and what is mandatory. I would have expected a field mapping but the text
explicitly says "The mapping between X.509 CSR fields and the template will be
defined in a future revision of this document.".
** Section 3.1.
The NDC MUST NOT include in the CSR any fields that are not specified
in the template, and in particular MUST NOT add any extensions unless
those were previously negotiated out of band with the IdO.
These two normative clauses seem to conflict. The first clause says that the
CSR can only have fields listed in the template (and nothing else). How would
one include extensions not in the template based on out of band negotiation?
It seems like it is either in the template or not.
** Section 4. Is this entire section normative protocol guidance? Or just
informatively describing use cases? If it is informative, please say so.
** Section 4.1.* Please expand UA = User Agent and CP = Content Provider prior
to their introduction in the figures
** Section 4.1.2.1. Please expand SAN.
** Section 4.1.2.1. There is a TBD text here, "TBD bootstrap, see
https://github.com/yaronf/I-D/issues/47";
** Section 4.1.2.1 Step 2 of Figure 6. Editorial. Don't use colloquial
language "CDNI things" - s/CDNI things/CDNU meta-data/
** Section 5.*. Add "registry" to the name of the registry in question. For
example, in Section 5.1.: s/ACME Directory Metadata Fields/ACME Directory
Metadata Registry/
** Section 5.4. If there isn't a registry, why are they in the IANA section?
Should we create a registry?
** Section 5.5. Editorial. To make the bulleted list explaining the fields
symmetric with the registry columns:
NEW:
An extension name
An extension type (the syntax, as a JSON Schema snippet)
The mapping to an X.509 certificate extension.
** Section 5.5. Per the definition of the "type" column:
-- Formally, what is a JSON Schema snippet? In particular, the three
pre-loaded values reference seem to reference "Appendix B" which doesn't seem
like a "snippet" (it containing a fully valid and well-formed XML file).
-- The registration policy is "expert review" so in theory a document is not
needed. Is the thinking that the registry row could contain a bare JSON
snippet?
** Section 5.5. What does "(only for the supported name formats)" mean in the
"Mapping to X.509" of subjectAltName
** Section 6.2. Editorial. s/cert/certificate/
** Section 6.2. Per the enumeration of the "two separate parts" of the
delegation process, isn't there also:
-- serving the certificate back to the NDC
-- a process for handling revocation of the delegation and the certificate
itself
Both of these seem to be discussed in Section 6.3 in some form.
** Figure 1 and 8. In the spirit of consistency, consider if the CA should be
named the "CA Server" (per figure 1) or "ACME server" (per figure 8).
** Section 6.4. s/Following is the proposed solution where/The following is a
possible mitigation when/
Regards,
Roman
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
