On Wed, Jun 04, 2014 at 10:22:33AM -0400, Paul Wouters wrote:
> >(skip oob when somewhat likely to fail and the client implements use of PKIX
> >certs).
>
> It's not "likely to fail" when there is an exising "3 1 x" TLSA record
> published!
Sure it is, those record might match only a future or past server
key when other RR parameter combinations are also present. Unless
we define such transitions as invalid, and publish server-operator
guidelines that place the burden on the server to avoid such states.
Is that the WG's preference? I can strengthen the key rotation
guidelines in the OPs draft (looks like it is about to morph into
a standards track 6698 update) to require server operators to avoid
transition states in which any of the published C/U/M combinations
match only future or only past keys. This requires some attention
to detail when updating TLSA RRs, and a tricky process when
switching from "311" to "201":
1. 311 old self-signed leaf
2. 311 old leaf + 311 new DANE-TA issued leaf (wait for 1 to age out
then deploy new cert chain).
3. 201 new DANE-TA issued chain (previously published as 311 in step 2).
at each stage there are now C/U/M combinations that don't match
any "active" key.
> Leaves me puzzled even more about what you _are_ trying to convey as
> the requirement for not mixing "3 1 x" and other types.
Consider the above transition from a 311 self-signed cert to a
DANE-TA(2) issued cert, in which the server operator is in a hurry,
and we've not yet mandated the above process:
1. 311 old self-signed leaf
2. 311 old (still active) leaf + 201 planned TA
(wait for 1 to age out, then activate new chain).
3. Drop 311 leaving only 201.
This this, "oob" clients lose at step 2 when the new chain is
activated, but the RRset has "311" only for obsolete keys and a
"201" for the active keys. Note, this is not a "misconfiguration"
in any sense with respect to 6698, and is not a problem prior to
the introduction of "oob" negotiation.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
