On Tue, Jan 27, 2026 at 12:32:41PM -0800, Ted Lemon via Datatracker wrote:
> Section 9.18 adds a new TLSA selector type, but doesn't talk about the
> implications of this addition. I think this has the potential to create a lot
> of confusion, and should probably be discussed with subject matter experts
> before moving forward with this document.
There are two possible concerns.
- Section 9.17 aims to define the CBOR certificate type for TLS,
but the wording looks too fluffy to me. I'd expect it to closely
mirror https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2
and display the usual TLS structure syntax spelling out the details
unambiguously. In particular the last sentence of the below
excerpt puzzles me:
C509 is defined in the same way as X.509, but uses a different
value and instead of the DER-encoded X.509 certificate, opaque
cert_data<1..2^24-1> in TLS 1.3 and opaque ASN.1Cert<1..2^24-1>
in TLS 1.2, contains the CBOR sequence ~C509Certificate (an
unwrapped C509Certificate). Similar to COSE_C509, the TLS
handshake contains the length of each certificate.
TLS always length-encodes variable-length "vectors", what exactly
is being said here? Presumably we're talking about an extended
union type:
struct {
select (certificate_type) {
case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509:
opaque cert_data<1..2^24-1>;
case C509:
opaque c509_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
in which "c509_data" is apparently an unwrapped ~C509Certificate
sequence. Then just say so, and I see no need to drag in COSE.
Without a crystal clear way to negotiate CBOR in TLS, TLSA records
are not useful.
- Section 9.18 specifies a new DANE selector, but it is not
completely clear what form these take. Are they unwrapped or
wrapped? This is especialy critical when the matching type is a
digest, the verifier must definitively know what is expected to be
passed to the digest algorithm.
My best guess is that this time we have a "C509CertData"
structure:
C509CertData = bytes .cborseq C509Certificate
presumably as shown in Figure 26 of A.1.5.
I don't anticipate much need for the CBOR DANE selector, the most
sensible choice (especially if the aim to save time and space, ...) is
to use TLSA records of the "3 1 1" form: DANE-EE(3) SPKI(1) SHA2-256(1).
Which then makes it possible to negotiate use raw public keys, with no
certificates on the wire in either CBOR Or X.509 form.
$ posttls-finger -c -ldane -Lsummary dnssec-stats.ant.isi.edu
posttls-finger: Verified TLS connection established
to dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519MLKEM768
server-signature RSA-PSS (2048 bit raw public key)
server-digest SHA256
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
dane mailing list -- [email protected]
To unsubscribe send an email to [email protected]
