yaronf / i-d Goto Github PK

Can we get rid of "DNO" (only used a few times in the text, and more than a few times in examples) in favor of IdO, for consistency?

For example, eliminate mention of "recurrent" attributes.

• s/The IdO must buffer/The IdO MUST buffer/

What does "(only for the supported name formats)" mean in the "Mapping to X.509" of subjectAltName

From: https://datatracker.ietf.org/doc/review-ietf-acme-star-06-opsdir-lc-ersue-2019-07-21/

4.2. Impact on Certificate Transparency (CT) Logs
...
The input received from most members of the CT community when the
issue was raised was that this should not represent a problem for the
CT architecture.

This statement is pretty vague for a standard track document. I assume the
reader will be asking what "most members" mean and why it shouldn't represent a
problem for the CT architecture.

From: https://datatracker.ietf.org/doc/review-ietf-acme-star-06-opsdir-lc-ersue-2019-07-21/

7.1. No revocation
...
More discussion of the security of STAR certificates is available in
[Topalovic].

AFAIU the external paper referred to does not adress security considerations
directly. If you think there are concrete security considerations related to
"No revocations" I would like to suggest to list them here.

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?

Is this entire section normative protocol guidance? Or just informatively describing use cases? If it is informative, please say so.

Since there may be multiple levels of delegation (CDNI), we need to specify the proxy behavior of the protocol as opposed to only the client as server side currently specified.

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.

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.

Are there any constraints to what the delegation URLs could point to?

As SVG, if it works in the text (maybe as a separate appendix) and if the diagram is not overly complex.

Specifically in the text: ACME defines the following values for the order resource's status.

Include a formal definition of the protocol configuration (including the CSR template as well as other things) as a JSON object. This can then be reused by the CDNI draft for their initial exchange.

In the spirit of consistency, consider if the CA should be named the "CA Server" (per figure 1) or "ACME server" (per figure 8).

s/Following is the proposed solution where/The following is a possible mitigation when/

Hello @yaronf . I have a design question: what's the motivation for specifying a mechanism requiring server state rather than allowing clients to drive renewal? What I mean is, why does the server need to do work in absence of a client asking for a renewal? Signing a certificate is easy can can be done inline during a request. Authentication can be accomplished by requiring mTLS on a renewal endpoint. This is, for example, how we handle renewals in step-ca (an ACME compliant CA implementation).

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/

If there isn't a registry, why are they in the IANA section? Should we create a registry?

Apropos remembering, we should add at least the following folks to the ACK section:

• Ryan Sleevi
• Roman Danyliw
• Frédéric Fieau
• Sanjay Mishra
• Emile Stephan

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").

Editorial. s/cert/certificate/

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

Provide an example, as well as a formal JSON Schema schema.

-- 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"/

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)

There is a TBD text here, "TBD bootstrap, see #47"

   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.

In theory, a STAR certificate could be revoked the ACME way (https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.6). This doesn't make much sense in a STAR environment, which relies on expiration of the short-term cert to handle key compromise.
The document should explicitly say whether the revocation interface is available to an ACME STAR client or not.

When in proxy mode we say what the proxy should do with Location but we haven't specified how to deal with the link relations carried by the Link header.

Check that where the requirements in section 2.3.2 do not apply to non-STAR certs, this is duly noted. E.g., the fourth bullet point:

* MUST contain an auto-renewal object and inside it, the fields
  listed in Section 3.1.1 of [RFC8739];

should also say something like with the exception described in Section 2.4 or similar.

Per "The "Location" header must be rewritten", it would be useful to describe the new target.

-- 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.

[Edited to move text on mappings to #94]

Enable cert extensions, e.g. the one we mention explicitly (TNAuthList). Possibly as an extension registry, in the IANA section.

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.

Step 2 of Figure 6. Editorial. Don't use colloquial language "CDNI things" - s/CDNI things/CDNU meta-data/

Unicode in the Ack section.

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?

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?

s/The IdO can delegate multiple names through each NDC/The IdO can delegate multiple names to a NDC/

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

** 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.

@yaronf I'm not sure we addressed all of Ryan's comments?

https://mailarchive.ietf.org/arch/msg/acme/CG3CE5Wo7LjUnvPP2V8er6OL3NQ/

In section "Order Object on the NDC-IdO side" we say:

- MUST contain an "auto-renewal" object and inside it, the fields
  listed in Section 3.1.1 of {{!RFC8739}};

but this is only applicable to STAR-based delegation.

This needs fixing to account for "Delegation of Non-STAR Certificates".

${title}

Thomas: another minutia that I've noticed this morning while scanning the draft is the use of the star-delegation-enabled capability, which should be called "delegation-enabled" instead and go under the new auto-renewal registry.

Fig. 1: specifically, add response messages.

Please expand UA = User Agent and CP = Content Provider prior to their introduction in the figures