Re: [TLS] Why TLSA RR and not CERT RR?

[Robert Moskowitz <[e-mail]>]

Viktor,

thank you for your response.

For those uses that are DANE/DANCE/TLS related, TLSA records WILL be 
used.  See

draft-moskowitz-drip-secure-nrid-c2

Which I am working on an update to correct some errors and add MAVlink 
as a message format for NRID.

and these TLSA records will be installed? in DNS via
draft-ietf-drip-registries (still in need of serious work)

But in draft-ietf-drip-auth, we have attestations that are carried in 
very contrained messages, and there have been various opinions that 
these should also be in DNS.  So how?  CERT RR, it seems.  And again 
this will be done in drip-registries.

So there is a part of this which is TLS (and IPsec and HIP) and a part 
which is custom design work to fit into the mandated Unmanned Aircraft comm.

Fun to be had.

Bob


On 6/26/22 16:55, Viktor Dukhovni wrote:
> On Sun, Jun 26, 2022 at 04:29:38PM -0400, Robert Moskowitz wrote:
>
>> I will use them in draft-ietf-drip-registries for our X.509 certs and
>> our 'custom' attestation certs (private OID will be needed). And then
>> the powers-that-be can sort it out as we move forward.
> Why do the certificates need to be delivered via DNS?  Are TLS or DTLS
> not suitable as protocols between the subject and relying party?
>
> What is the management model for these certificates?  How will key
> rollover at the subject be coördinated with changes in the DNS?
>
> TLSA records are flexible in that they can specify trust-anchor keys or
> certificates (typically their digests) as well as EE keys or
> certificates.  Multiple TLSA records can be published at the same RRset,
> and rollover is facilitated by requiring only one to match.
>
> The need to tightly synchronise regular certificate rollovers with DNS
> changes can be avoided by keeping EE keys stable, or publishing a stable
> issuer trust-anchor key.  Alternatively, one can pre-publish future
> EE public keys and then use that key in a later certificate rollover
> if observed in DNS for a sufficient number of TTLs, or else renew the
> certificate with the extant key.
>
> So there are well-understood (if not yet universally practiced)
> operational practices that enable robust deployments of DANE TLSA.
>
> Is there something similar for the proposed use of CERT?  Is publication
> of (often multi-kilobyte) full certificates in DNS a good idea?
>