Hi Yaron and Thomas! > -----Original Message----- > From: Yaron Sheffer <[email protected]> > Sent: Wednesday, February 24, 2021 9:08 AM > To: Roman Danyliw <[email protected]>; IETF ACME <[email protected]> > Subject: Re: [Acme] AD Review: draft-ietf-acme-star-delegation-04 > > Hi Roman, > > (1) In fact the existing language is more accurate. The CSR template is sent > to > the NDC in order to constrain what the NDC puts in the CSR. So the text that > describes the mapping *from* the CSR template *to* the CSR is correct. Also, > SPKI is freshly generated by the NDC, guided by the constraint on which key > types it may use. So maybe: > > The subject field and its subfields are mapped into the subject field of the > CSR, > as per [RFC5280], Sec. 4.1.2.6. Other extension fields of the CSR template are > mapped into the CSR according to the table in Section 5.6. The Subject Public > Key Info field of the CSR is generated by the NDC according to the constraints > defined by the "keyTypes" object of the template. > > (2) It turns out that my coauthor Thomas is a native CDDL speaker. So we will > include a CDDL schema in addition to the JSON Schema. I concur that > developers are much more likely to use the latter.
Great. Thanks for adding this unexpected element. Roman > Thanks, > Yaron > > On 2/23/21, 18:31, "Roman Danyliw" <[email protected]> wrote: > > Hi Yaron! > > Thanks for all of the work that went into -05. It addresses all of my > concerns > but the following: > > (1) Section 3.1. The updated language is helpful, but I recommend a bit > more > precision to cover all of the fields. > > OLD > The subject field and its subfields are mapped into the subject field of > the > CSR, as per [RFC5280], Sec. 4.1.2.6. Other extension fields of the CSR > template > are mapped into the CSR according to the table in Section 5.6. > > NEW > The "Subject" field and its subfields per Section 4.1.2.6 of [RFC5280] are > mapped into the "subject" field of the CSR template. The "Subject Public Key > Info" field and its subfields per Section 4.1.2.7 of [RFC5280] are mapped into > the "keyTypes" field of the CSR template. Other extension fields are mapped > as > subfields of the "extensions" field in the CSR template according to the > table in > Section 5.6. > > (2) The more thorny issue is how to handle a normative dependence on the > JSON schema. Short of it being in the document, whatever is the formal > language used to define the CSR template needs an appropriate normative > reference describing it. Currently, [json-schema-07] in Appendix B would need > to be normative (not informative). I confirmed my concern with the ART ADs, > and there is agreement that neither draft-handrews-json-schema-validation or > http://json-schema.org will be an adequate normative references (i.e., [json- > schema-07]). > > IMO, JSON still seems like the right architectural pattern here. I also > don't > see an issue with the Schema that was specified. > > A possible compromise (vetted with the ART ADs) is to follow the pattern > of > RFC8727 which also tried to use JSON Schema but couldn't find a usable > normative reference -- full disclosure, I was a co-author. This RFC > normatively > specified the "schema" via CDDL but also informatively provided the same > schema via [json-schema-07]. Practically, implementers ignore the CDDL and > use the more assessible JSON. I appreciate this approach is additional work > and > pulls in another "technology" that isn't a natural fit in the ACME ecosystem. > > Do you see any alternatives? > > Regards, > Roman > > > -----Original Message----- > > From: Yaron Sheffer <[email protected]> > > Sent: Friday, February 5, 2021 5:45 PM > > To: Roman Danyliw <[email protected]>; IETF ACME <[email protected]> > > Subject: Re: [Acme] AD Review: draft-ietf-acme-star-delegation-04 > > > > Hi Roman, > > > > Thank you for the detailed review. We will go through your comments and > will > > rev the document accordingly, but in the meantime, let me respond > specifically > > to the issue of the CSR template syntax. > > > > The CSR template is potentially a long/complicated JSON document > (example: > > [1]), and we felt that rather than including an informal definition > which is > easy > > to get wrong or a long sequence of examples, our audience would be > better > > served by a formal definition. > > > > To the best of my knowledge, by far the most common way to specify a > JSON > > document format is with JSON Schema documents. Granted this spec is > still > a > > moving target, but it's already widely implemented. Also, there are > discussions > > between the leaders of the JSON Schema effort and people on the HTTP- > API > > working group, with the goal of standardizing it there. > > > > JSON Schema draft-7 is defined by draft-handrews-json-schema-validation- > 01 > > (and a few companion document), and not (as we incorrectly noted) by the > > latest version of that draft. Clearly it's not ideal to refer to a > specific, > expired > > version of an I-D. The situation is mitigated to a certain degree by the > schema > > document [2] mentioning explicitly the supported version: > > > > "$schema": "http://json-schema.org/draft-07/schema#"; > > > > I hope this clarifies things. Regarding your two related comments: > > > > - Yes, we should have specified the mapping of fields into X.509, and > will > do > > that when we address your comments. > > - The notion of "snippet" is actually well defined when we say, "a JSON > Schema > > snippet that defines a type". Formally this is a valid JSON object with > a > "type" > > attribute, per draft-handrews-json-schema-validation-01 Sec. 6.1.1. > > > > Thanks, > > Yaron > > > > > > [1] https://raw.githubusercontent.com/yaronf/I-D/master/STAR- > > Delegation/CSR-template/example-template.json > > [2] https://raw.githubusercontent.com/yaronf/I-D/master/STAR- > > Delegation/CSR-template/template-schema.json > > > > > > On 2/5/21, 00:50, "Roman Danyliw" <[email protected]> wrote: > > > > 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
