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?


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to