Re: [TLS] Enforcing Protocol Invariants

["Salz, Rich" <[e-mail]>]

>    [ 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$