On 25/06/17 03:52, Martin Thomson wrote:
On 24 June 2017 at 02:24, Yaron Sheffer <[email protected]> wrote:
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?
Isn't enough to rely on the server echoing your parameters? (Another
reason to use absolute values for the end of the recurring interval.)
I'm not following you. In Sec. 3.4 we're saying that the (periodically
rolling) certificate is always available on the same URL, the
"certificate endpoint". Since the content available at that URL changes
from time to time, we wanted to indicate its end-of-validity with an
HTTP header. If "Expires" is not the right header, is there a better way
to do it?
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.
This is a protocol. What CABF do with it is entirely up to them.
They aren't the only ones creating policy that might affect someone
using this protocol.
But people are not obligated to implement IETF protocols. OTOH some
organizations *are* bound by CA/B Forum rules. And this section is
predicated on the assumption at all "reasonable" CAs do honor CAA
records, otherwise a rogue CDN employee can create a certificate for the
domain on a non-ACME CA, if they only require a proof of ownership of
the web server.
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.
If the CAA record exists, then spoofing won't result in the
certificate being issued, so what is the problem?
Basic CAA, prior to Hugo's draft, only says which CA you are trusting.
But that CA can still choose the spoofable http-01 authorization -
spoofable if you are the CDN and so you control the web pages.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme