> [ I don't know why you would choose to argue this point, let's not
confuse TLS with the CA/B forum WebPKI in browsers. My post was
about TLS.
I am not. You say TLS is CA/B WebPKI. I say TLS favors X509 CA-trust model,
and in fact has it as its default. For example, in TLS 1.3 page 44 (text
format):
"The signatures on certificates that are self-signed or certificates
that are trust anchors are not validated, since they begin a
certification path (see [RFC5280], Section 3.2)."
Section D.3, implementation notes in SSLv3 RFC 6101
"Certificates should always be verified to ensure proper
signing by a trusted certificate authority (CA). The selection and
addition of trusted CAs should be done very carefully. Users should
be able to view information about the certificate and root CA."
The glossary says this about certificates:
"As part of the X.509 protocol (a.k.a. ISO
Authentication framework),"
> However, since bashing
DNSSEC is a popular sport, I may for the record, now and then
post corrections to messages that mischaracterize DNSSEC. ]
I said nothing about DNSSEC, certainly nothing that could remotely be taken as
bashing.
> The X.509 trust-anchors are NOT specified in TLS, and need not be
used.
They are specified, and if provided, how they are used is also specified and
has been from the beginning, through and including TLS 1.3, as I showed via the
excerpts above.
> The existing X.509 encapsultion
works just fine, and makes it possible to transparently interoperate
with both DANE and CA/B forum WebPKI or other PKIX peers.
The existing encoding could be used just fine, just indicate that this is a
DANE-validated cert. Then it will be clear and obvious to everyone how to
validate it. Complex combinations are hard to reason about, cannot be intuited
by the protocol but must be done by reading code and configuration, etc. A
DANE client could specify DANE in the acceptable cert-type, which is encoded as
X509. I believe this approach was considered, but rejected. I was trying to
offer advice on how that draft might be edited and brought forward more
productively if the authors want to try again in the general sense of enabling
DANE-style trust within TLS generally. I don't care, I have no horse in that
race.
/r$
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
