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?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
