Define a CAA parameter governing CanSignHttpExchanges cert issuance.#377
Define a CAA parameter governing CanSignHttpExchanges cert issuance.#377jyasskin merged 8 commits intoWICG:masterfrom
Conversation
|
still lgtm |
|
As current worded, it's OK for a CA which isn't listed in any issue/issuwild property to issue certificates with the CanSignHttpExchanges extension. Instead, I'd suggest:
|
|
@AGWA Thanks! Done. |
| on the property and is equal to "yes". | ||
|
|
||
| The CA/Browser Forum Baseline Requirements ({{BRs}}) are expected to establish | ||
| requirements around the treatment of this parameter. |
There was a problem hiding this comment.
-
In general, we should avoid SHOULD/SHOULD NOT requirements unless we provide guidance on when there are applicable exceptions. Alternatively, MUST/MUST NOT provides a clearer, unambiguous processing model, modulo what error handling should be (which presumably is MUST NOT issue)
-
The reference to the BRs may end up being circular. The BRs state the rules for which a CA can include arbitrary extensions (7.1.2.4.), so if there are requirements expressed here, they should trigger the rules of 7.1.2.4 (a) (ii) and 7.1.2.4 (b), and thus require following this spec and whatever it describes.
There was a problem hiding this comment.
I've moved this to the definition of the CanSignHttpExchanges extension, where there's no question that we can MUST CAs. Now I don't need to point at the BRs.
|
I'm hoping one of the certificate experts (@AGWA, @sleevi, @clintwilson) will approve this before I merge it. |
| applicable "issue" or "issuewild" CAA property ({{!RFC6844}}) exists for the CA, | ||
| and the "cansignhttpexchanges" parameter ({{caa-cansignhttpexchanges}}) is | ||
| present on the property and is equal to "yes". | ||
|
|
There was a problem hiding this comment.
I just realized that this wording could be interpreted as allowing a CA to include the extension if just one of the dNSNames in the certificate has cansignhttpexchanges=yes. 😬 Obviously, the intent is that this parameter must be present for every dNSName. I'll propose some better wording in a little bit unless someone else beats me to it.
There was a problem hiding this comment.
See, this is why I wait. :)
There was a problem hiding this comment.
How about:
A conforming CA MUST NOT issue certificates with this extension unless, for each dNSName in the subjectAltName extension of the certificate to be issued:
- An "issue" or "issuewild" CAA property ({{!RFC6844}}) exists that authorizes the CA to issue the certificate; and
- The "cansignhttpexchanges" parameter ({{caa-cansignhttpexchanges}}) is present on the property and is equal to "yes"
There was a problem hiding this comment.
Done. RFC6844 manages to avoid saying that a certificate's domains are listed in the dNSName, but if saying it here is a problem, we have plenty of time to revise the wording.
There was a problem hiding this comment.
I cribbed the "each dNSName in the subjectAltName extension" wording from the BR's section on CAA so it should be solid.
This gives a stronger indication that the domain owner has opted into the new security risks than just that a CA issued a certificate with the extension. This only SHOULDs the CAs because CAA parameters are CA-defined per RFC6844. The BRs will need to be updated to actually constrain CAs. As suggested by Andrew Ayer.
…he CanSignHttpExchanges certificate extension. This allows us to MUST CA behavior, and not wait on a BR update.
Thanks AGWA for the wording.
4 participants
This gives a stronger indication that the domain owner has opted into the new
security risks than just that a CA issued a certificate with the extension.
@AGWA, how's this look? https://tools.ietf.org/html/draft-ietf-acme-caa-06#section-3 has a MUST, which I've downgraded to a SHOULD here after reading draft-ietf-acme-caa's IANA considerations.
Preview; Diff