diff --git a/draft-ietf-acme-onion.xml b/draft-ietf-acme-onion.xml index 67fbf39..fee1b04 100644 --- a/draft-ietf-acme-onion.xml +++ b/draft-ietf-acme-onion.xml @@ -320,9 +320,7 @@ introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3KHCZUZ3C6tX
Alternative in-band presentation of CAA A CA may not be willing to operate the infrastructure required to fetch, decode, and verify Tor hidden service - descriptors in order to check CAA records. Tor directory servers are inherently untrusted entities, and as such - there is no difference in the security model of accepting CAA records directly from the ACME client or fetching - them over Tor. To this end a method to signal CAA policies in-band of ACME is defined. + descriptors in order to check CAA records. To this end a method to signal CAA policies in-band of ACME is defined. If a hidden service does use this method to provide CAA records to a CA it SHOULD still publish CAA records if its CAA record set includes "iodef", "contactemail", or "contactphone" so that this information is still publicly accessible. A hidden service operator MAY also not wish to publish a CAA @@ -553,6 +551,12 @@ Content-Type: application/jose+json secret key of the hidden service could manipulate what is published there. For more information about this process see ยง 2.5.3.
+
+ In-band CAA + Tor directory servers are inherently untrusted entities, and as such there is no difference in the security + model for accepting CAA records directly from the ACME client or fetching them over Tor. CAA records are still + verified against the same hidden service key. +
Access of the Tor network The ACME server MUST make its own connection to the hidden service via the Tor network,