Re: [W3C Web Security IG] Strews report - phase 2

On Mon, May 18, 2015 11:23 am, Jeffrey Walton wrote:
>  On Mon, May 18, 2015 at 2:22 PM, Ryan Sleevi
> > I suspect you may have meant DANE (which is for clients).
>  Actually, NO.
>
>  Its security specific context information. I'm happy to use any
>  security specific context information I can get my hands on.
>
>  Jeff

Then you'd be wrong for using CAA, as everyone who has worked with CAA can
easily tell you, and you'd be causing problems and discouraging deployment
of CAA, making (almost) everyone who has worked with CAA sad. :)

CAA records are bound in time at cert issuance. They cannot be arbitrarily
checked after the fact, as CAA records can and do change. It's rather
quite simple:

T0 = CAA record says "fooca.com"
T1 = Foo CA checks CAA record, sees their name, issues cert.
T5 = CAA record is changed to say "barca.com", because Bar CA is giving
bulk discounts. This is a contract signed for new certs, but the existing,
unexpired certs are kept with foo CA
T6 = Client visits site, sees cert from Foo CA

If clients check the CAA record, they will break, because "Foo CA" !=
barca.com. Further, CAA is intentionally opaque as to the identifiers
embedded in CAA records that it is defined by CA policy as to what they
mean. There isn't some registry that maps "fooca.com" back to the set of
Foo CA's root fingerprints. No, it's simply up to Foo CA to know that
"fooca.com" is them and that "barca.com" is not them. These policies are
disclosed in their CPS.

So again, no, that's what not CAA is for. (Though this group isn't the
best place to explain CAA or how it should work, it was enough to qualify
precisely why CAA has no relevance of bearing for clients, lest someone
think it does)

Received on Monday, 18 May 2015 18:37:52 UTC