Hi Alexey, Thank you very much for your comments.
On 29/09/2019, 17:29, "Alexey Melnikov via Datatracker" <[email protected]> wrote: > I have one small issue that I would like to discuss before recommending > approval of this document: > > Section 6.4 and 6.6 don’t seem to specify IANA registration procedure for new > subregistries. Are you saying we should say explicitly what the contents of the new sub-registries are? If so, something like the following would work for you: Section 6.4., paragraph 4: OLD: +-----------------------+------------+--------------+-----------+ | Field Name | Field Type | Configurable | Reference | +-----------------------+------------+--------------+-----------+ | start-date | string | true | RFC XXXX | | ... NEW: Initial contents: The fields and descriptions defined in Section 3.1.1. +-----------------------+------------+--------------+-----------+ | Field Name | Field Type | Configurable | Reference | +-----------------------+------------+--------------+-----------+ | start-date | string | true | RFC XXXX | | ... Section 6.6., paragraph 4: OLD: +-----------------------+------------+-----------+ | Field Name | Field Type | Reference | +-----------------------+------------+-----------+ | min-lifetime | integer | RFC XXXX | | ... NEW: Initial contents: The fields and descriptions defined in Section 3.2. +-----------------------+------------+-----------+ | Field Name | Field Type | Reference | +-----------------------+------------+-----------+ | min-lifetime | integer | RFC XXXX | | ... If this is not what you want, please guide me as I'm slightly lost :-) > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1.1. Name Delegation Use Case > > The proposed mechanism can be used as a building block of an efficient > name-delegation protocol, for example one that exists between a CDN or a cloud > provider and its customers [I-D.ietf-acme-star-delegation]. At any time, the > service customer (i.e., the IdO) can terminate the delegation by simply > instructing the CA to stop the automatic renewal and letting the currently > active certificate expire shortly thereafter. Note that in this case the > delegated entity needs to access the auto-renewed certificate without being in > possession of the ACME account key that was used for initiating the STAR > issuance. > > Can you explain the last sentence? I am reading “in this case” as the > delegated > entity needs access to renewed certificate once delegation is cancelled, which > doesn’t make sense. Please let me know if I misunderstood. "in this case" refers to "name delegation", sorry for the confusion. When using the default POST-as-GET method to retrieve the cert, the delegated entity should be in possession of the account key to sign the request. However, sharing key material between the delegating and the delegated party is not ideal -- in fact, it's what we want to avoid in the first place here. What about: Section 1.1., paragraph 1: OLD: [...] certificate expire shortly thereafter. Note that in this case the delegated entity needs to access the auto-renewed certificate without being in possession of the ACME account key that was used for initiating the STAR issuance. NEW: [...] certificate expire shortly thereafter. Note that in the name delegation use case the delegated entity needs to access the auto-renewed certificate without being in possession of the ACME account key that was used for initiating the STAR issuance. Cheers, thanks! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
