rfc9115v2.txt | rfc9115.txt | |||
---|---|---|---|---|
skipping to change at line 279 ¶ | skipping to change at line 279 ¶ | |||
the delegated identifier to the CA. | the delegated identifier to the CA. | |||
* If the ACME STAR protocol fails, Order2 moves to "invalid", and | * If the ACME STAR protocol fails, Order2 moves to "invalid", and | |||
the same state is reflected in Order1 (i.e., the NDC Order). | the same state is reflected in Order1 (i.e., the NDC Order). | |||
* If the ACME STAR run is successful (i.e., Order2 is "valid"), IdO | * If the ACME STAR run is successful (i.e., Order2 is "valid"), IdO | |||
copies the "star-certificate" URL from Order2 to Order1 and | copies the "star-certificate" URL from Order2 to Order1 and | |||
updates the Order1 state to "valid". | updates the Order1 state to "valid". | |||
The NDC can now download, install, and use the short-term certificate | The NDC can now download, install, and use the short-term certificate | |||
bearing the name delegated by the IdO. This can continue until the | bearing the name delegated by the IdO. The STAR certificate can be | |||
STAR certificate expires or the IdO decides to cancel the automatic | used until it expires, at which time the NDC is guaranteed to find a | |||
renewal process with the CA. | new certificate it can download, install, and use. This continues | |||
with subsequent certificates until either Order1 expires or the IdO | ||||
decides to cancel the automatic renewal process with the CA. | ||||
Note that the interactive identifier authorization phase described in | Note that the interactive identifier authorization phase described in | |||
Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because | Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because | |||
the delegated identity contained in the CSR presented to the IdO is | the delegated identity contained in the CSR presented to the IdO is | |||
validated against the configured CSR template (Section 4.1). | validated against the configured CSR template (Section 4.1). | |||
Therefore, the NDC sends the "finalize" request, including the CSR, | Therefore, the NDC sends the "finalize" request, including the CSR, | |||
to the IdO immediately after Order1 has been acknowledged. The IdO | to the IdO immediately after Order1 has been acknowledged. The IdO | |||
SHALL buffer a (valid) CSR until the Validation phase completes | SHALL buffer a (valid) CSR until the Validation phase completes | |||
successfully. | successfully. | |||
skipping to change at line 412 ¶ | skipping to change at line 414 ¶ | |||
{ | { | |||
"delegations": [ | "delegations": [ | |||
"https://acme.ido.example/acme/delegation/ogfr8EcolOT", | "https://acme.ido.example/acme/delegation/ogfr8EcolOT", | |||
"https://acme.ido.example/acme/delegation/wSi5Lbb61E4", | "https://acme.ido.example/acme/delegation/wSi5Lbb61E4", | |||
/* more URLs not shown for example brevity */ | /* more URLs not shown for example brevity */ | |||
"https://acme.ido.example/acme/delegation/gm0wfLYHBen" | "https://acme.ido.example/acme/delegation/gm0wfLYHBen" | |||
] | ] | |||
} | } | |||
Note that, in the figure above, | Note that in the figure above, | |||
https://acme.ido.example/acme/delegations/adFqoz?cursor=2 includes a | https://acme.ido.example/acme/delegations/adFqoz?cursor=2 includes a | |||
line break for the sake of presentation. | line break for the sake of presentation. | |||
2.3.1.3. Delegation Objects | 2.3.1.3. Delegation Objects | |||
This profile extends the ACME resource model with a new read-only | This profile extends the ACME resource model with a new read-only | |||
"delegation" object that represents a delegation configuration that | "delegation" object that represents a delegation configuration that | |||
applies to a given NDC. | applies to a given NDC. | |||
A "delegation" object contains the CSR template (see Section 4) that | A "delegation" object contains the CSR template (see Section 4) that | |||
skipping to change at line 475 ¶ | skipping to change at line 477 ¶ | |||
}, | }, | |||
"cname-map": { | "cname-map": { | |||
"abc.ido.example.": "abc.ndc.example." | "abc.ido.example.": "abc.ndc.example." | |||
} | } | |||
} | } | |||
Figure 3: Example Delegation Configuration Object | Figure 3: Example Delegation Configuration Object | |||
In order to indicate which specific delegation applies to the | In order to indicate which specific delegation applies to the | |||
requested certificate, a new "delegation" attribute is added to the | requested certificate, a new "delegation" attribute is added to the | |||
request object on the NDC-IdO side (see Figures 4 and 7). The value | order object on the NDC-IdO side (see Figures 4 and 7). The value of | |||
of this attribute is the URL pointing to the delegation configuration | this attribute is the URL pointing to the delegation configuration | |||
object that is to be used for this certificate request. If the | object that is to be used for this certificate request. If the | |||
"delegation" attribute in the order object contains a URL that does | "delegation" attribute in the order object contains a URL that does | |||
not correspond to a configuration available to the requesting ACME | not correspond to a configuration available to the requesting ACME | |||
account, the IdO MUST return an error response with status code 403 | account, the IdO MUST return an error response with status code 403 | |||
(Forbidden), providing a problem document [RFC7807] with type | (Forbidden), providing a problem document [RFC7807] with type | |||
"urn:ietf:params:acme:error:unknownDelegation". | "urn:ietf:params:acme:error:unknownDelegation". | |||
2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server | 2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server | |||
(STAR) | (STAR) | |||
skipping to change at line 600 ¶ | skipping to change at line 602 ¶ | |||
* MUST carry a copy of the "auto-renewal" object sent by the NDC. | * MUST carry a copy of the "auto-renewal" object sent by the NDC. | |||
When the identifiers' authorization has been successfully completed | When the identifiers' authorization has been successfully completed | |||
and the certificate has been issued by the CA, the IdO: | and the certificate has been issued by the CA, the IdO: | |||
* MUST move its Order resource status to "valid" and | * MUST move its Order resource status to "valid" and | |||
* MUST copy the "star-certificate" field from the STAR Order | * MUST copy the "star-certificate" field from the STAR Order | |||
returned by the CA into its Order resource. When dereferenced, | returned by the CA into its Order resource. When dereferenced, | |||
the "star-certificate" URL includes (via the "Cert-Not-Before" and | the "star-certificate" URL includes (via the "Cert-Not-Before" and | |||
"Cert-Not-After HTTP" header fields) the renewal timers needed by | "Cert-Not-After" HTTP header fields) the renewal timers needed by | |||
the NDC to inform its certificate reload logic. | the NDC to inform its certificate reload logic. | |||
{ | { | |||
"status": "valid", | "status": "valid", | |||
"expires": "2021-05-01T00:00:00Z", | "expires": "2021-05-01T00:00:00Z", | |||
"identifiers": [ | "identifiers": [ | |||
{ | { | |||
"type": "dns", | "type": "dns", | |||
"value": "abc.ido.example" | "value": "abc.ido.example" | |||
skipping to change at line 634 ¶ | skipping to change at line 636 ¶ | |||
"finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize", | "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize", | |||
"star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" | "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" | |||
} | } | |||
Figure 6: STAR Order Resource Updated on IdO | Figure 6: STAR Order Resource Updated on IdO | |||
This delegation protocol is predicated on the NDC being able to fetch | This delegation protocol is predicated on the NDC being able to fetch | |||
certificates periodically using an unauthenticated HTTP GET, since, | certificates periodically using an unauthenticated HTTP GET, since, | |||
in general, the NDC does not possess an account on the CA; therefore, | in general, the NDC does not possess an account on the CA; as a | |||
it cannot issue the standard POST-as-GET ACME request. Therefore, | consequence, it cannot issue the standard POST-as-GET ACME request. | |||
before forwarding the Order request to the CA, the IdO SHOULD ensure | Therefore, before forwarding the Order request to the CA, the IdO | |||
that the selected CA supports unauthenticated GET by inspecting the | SHOULD ensure that the selected CA supports unauthenticated GET by | |||
relevant settings in the CA's directory object, as per Section 3.4 of | inspecting the relevant settings in the CA's directory object, as per | |||
[RFC8739]. If the CA does not support unauthenticated GET of STAR | Section 3.4 of [RFC8739]. If the CA does not support unauthenticated | |||
certificates, the IdO MUST NOT forward the Order request. Instead, | GET of STAR certificates, the IdO MUST NOT forward the Order request. | |||
it MUST move the Order status to "invalid" and set the "allow- | Instead, it MUST move the Order status to "invalid" and set the | |||
certificate-get" in the "auto-renewal" object to "false". The same | "allow-certificate-get" in the "auto-renewal" object to "false". The | |||
occurs in case the Order request is forwarded and the CA does not | same occurs in case the Order request is forwarded and the CA does | |||
reflect the "allow-certificate-get" setting in its Order resource. | not reflect the "allow-certificate-get" setting in its Order | |||
The combination of "invalid" status and denied "allow-certificate- | resource. The combination of "invalid" status and denied "allow- | |||
get" in the Order resource at the IdO provides an unambiguous | certificate-get" in the Order resource at the IdO provides an | |||
(asynchronous) signal to the NDC about the failure reason. | unambiguous (asynchronous) signal to the NDC about the failure | |||
reason. | ||||
2.3.2.1. CNAME Installation | 2.3.2.1. CNAME Installation | |||
If one of the objects in the 'identifiers' list is of type "dns", the | If one of the objects in the "identifiers" list is of type "dns", the | |||
IdO can add the CNAME records specified in the "delegation" object to | IdO can add the CNAME records specified in the "delegation" object to | |||
its zone, for example: | its zone, for example: | |||
abc.ido.example. CNAME abc.ndc.example. | abc.ido.example. CNAME abc.ndc.example. | |||
2.3.3. Order Object Transmitted from NDC to IdO and to ACME Server | 2.3.3. Order Object Transmitted from NDC to IdO and to ACME Server | |||
(Non-STAR) | (Non-STAR) | |||
If the delegation is for a non-STAR certificate, the request object | If the delegation is for a non-STAR certificate, the request object | |||
created by the NDC: | created by the NDC: | |||
skipping to change at line 1586 ¶ | skipping to change at line 1589 ¶ | |||
only entity authorized to modify the DNS zone. Typically, it | only entity authorized to modify the DNS zone. Typically, it | |||
establishes a CNAME resource record from a subdomain into a CDN- | establishes a CNAME resource record from a subdomain into a CDN- | |||
managed domain. | managed domain. | |||
* The domain holder uses a Certification Authority Authorization | * The domain holder uses a Certification Authority Authorization | |||
(CAA) record [RFC8659] to restrict certificate issuance for the | (CAA) record [RFC8659] to restrict certificate issuance for the | |||
domain to specific CAs that comply with ACME and are known to | domain to specific CAs that comply with ACME and are known to | |||
implement [RFC8657]. | implement [RFC8657]. | |||
* The domain holder uses the ACME-specific CAA mechanism [RFC8657] | * The domain holder uses the ACME-specific CAA mechanism [RFC8657] | |||
to restrict issuance to a specific account key that is controlled | to restrict issuance to a specific CA account that is controlled | |||
by it and MUST require "dns-01" as the sole validation method. | by it and MUST require "dns-01" as the sole validation method. | |||
We note that the above solution may need to be tweaked depending on | We note that the above solution may need to be tweaked depending on | |||
the exact capabilities and authorization flows supported by the | the exact capabilities and authorization flows supported by the | |||
selected CA. In addition, this mitigation may be bypassed if a | selected CA. In addition, this mitigation may be bypassed if a | |||
malicious or misconfigured CA does not comply with CAA restrictions. | malicious or misconfigured CA does not comply with CAA restrictions. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
End of changes. 7 change blocks. | ||||
23 lines changed or deleted | 26 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |