Hi Martin, Thomas,
Hi Martin,
Thanks for your review.
On 19/06/2017, 23:34, "Acme on behalf of Martin Thomson" <[email protected] on
behalf of [email protected]> wrote:
A few brief comments on this draft.
[snip]
I don't understand Section 3.3 at all. I'd recommend removing this
section. The DNO will decide what authorizations it requests amply
without this level of proscription in standards.
Yaron: thoughts on this?
This is yet another LURK leftover, where we make assumptions about the
capabilities of the NDC. Prescription makes sense in some particular
cases, but I agree this should be folded into the security
considerations (specifically Sec. 5.1) instead of the protocol's body.
In Section 3.4, the use of the Expires header field is a common
mistake. This is an HTTP caching directive. It should probably be
shorter than the expiration time of the certificate (half in fact),
but not for the reasons that you might think. The purpose of a
recommendation on Expires is to ensure that the certificate is not
cached beyond the point where a newer certificate will be issued. You
should remove this text.
OK
Is there some other common header to denote that the value of a URL is
only good for X time?
[snip]
Don't mention time-sensitive policy actions by the CA/B Forum.
Makes sense.
I disagree. CA/B forum decisions (unlike IETF standards) are mandatory
for some parties to follow and so can be relied upon by the DNO.
Can't you simply ensure that the CDN can't modify the CAA record?
This is the minimum we could say. At this point, I think we are trying
to explore a bit what other mitigations can be put in place.
Unfortunately this is insufficient, because in the case of CDN's, some
of the authorization methods are subject to spoofing.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
