> 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]
https://www.ietf.org/mailman/listinfo/dane
