> The safe version of the reverse change looks like:
[I believe he's referring to upgrading a site from a TA-certified key to an
end-entity-certified key.]
>
> Initial:
>
> IN TLSA 2 0 1 {legacy TA blob}
>
> Intermediate:
>
> IN TLSA 3 1 1 {EE association for legacy TA issued chain}
> IN TLSA 3 1 1 {future EE blob}
>
> [switch keys]
>
> Final:
>
> IN TLSA 3 1 1 {new EE blob}
>
> Had the intermediate listed the original "2 0 1" for the legacy
> chain, "oob" clients would lose.
I don't understand this assertion. Viktor, why would "oob" (RPK)
clients lose (fail?) if the domain name also included a TLSA 2 0 1
record? My belief is that the RPK client would ignore that 2 0 1
record, either because the client doesn't implement PKIX, or because
the client is in the middle of an RPK TLS transaction and that record
is not relevant to that transaction.
This seems to be the central puzzle in trying to understand your
concerns with mixing RPK and PKIX TLSA records, so if you could
clearly explain why you think this case fails, it would help.
John
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
