+1
Plus, this is for TLS, and in TLS, the server is required to present a cert
chain. So the situation cited in the erratum can't happen.
On Tuesday, April 16, 2013, John Gilmore wrote:
> > This errata is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party (IESG)
> > can log in to change the status and edit the report, if necessary.
>
> I think it should be rejected.
>
> There are numerous ways to make any protocol fail, by selecting
> mutually incompatible options. The draft does not have to require
> that users of DANE-TLS configure their servers to work; they are free
> to configure them to fail. Similarly, there are often numerous ways
> to make any protocol work, by selecting different combinations of
> compatible options. The RFC does not have to require ("MUST") a
> particular combination, nor should it do so.
>
> The issue is certificate usage "2", defining a new trust anchor.
>
> To make a system interoperate with DANE-TLS clients when publishing
> TLSA records that specify usage 2, a server operator and domain
> administrator must:
>
> * Supply the entire trust anchor certificate in their TLSA record,
> specifying selector 0 (full certificate) and matching type 0
> (exact match); or
>
> * Configure their TLS server to supply the relevant trust anchor
> certificate in the certificate list that it sends [the option
> that Mr. Dukhovni suggests]; or
>
> * Supply the public key of the trust anchor in their TLSA record,
> specifying selector 1 (Subject Public Key Info) and matching type 0
> (exact match), allowing any certificate(s) signed by the trust anchor
> to be validated; or
>
> * Only interact with clients who already have a copy of the trust
> anchor certificate or public key. Some applications may be
> designed or configured to work only with a restricted set of
> clients.
>
> Any or all of these options are valid and will result in DANE-TLS
> interoperability. The erratum should be rejected.
>
> John
> _______________________________________________
> dane mailing list
> [email protected] <javascript:;>
> https://www.ietf.org/mailman/listinfo/dane
>
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
