On 6/27/22 4:33 PM, Peter Saint-Andre wrote:
On 6/27/22 4:27 PM, Viktor Dukhovni wrote:
On Mon, Jun 27, 2022 at 02:37:22PM -0600, Peter Saint-Andre wrote:
It does for the majority of the certificate usages, but in practice
today DANE is primarily used with SMTP, and predominantly with
DANE-EE(3) TLSA records, in which case identity questions are settleda
at the DNS layer, and the presented identifiers in the certificate are
irrelevant.
Even in this case, doesn't the certificate include a service identifier?
Actually, no. A handful of DANE SMTP server operators configure
certificates that have empty Subject and Issuer DNs and no Subject
Alternative names. The certificate is (kind-of) self-signed and
essentially holds just the public key and its self-signature.
Excellent. Thanks for the clarification. Thus in the case of DANE-EE
certs it truly is the case that, as you said in a previous message, the
equivalent of the presented identifier is derived purely from DNS.
Peter
Given these considerations, I propose that we add something like the
following text to the section on what's in scope for this document
(copied from the markdown source, thus the curly braces):
###
With regard to PKIX certificates, the primary usage is in the
context of the public key infrastructure described in {{5280}}.
In addition, technologies such as DNS-Based Authentication
of Named Entities (DANE) {{RFC6698}} sometimes use certificates based
on PKIX (more precisely, certificates structured via {{X.509}} or
specific encodings thereof such as {{X.690}}), at least in certain
modes. Alternatively, a TLS peer could issue delegated credentials
that are based on a CA-issued certificate, as in {{TLS-SUBCERTS}}.
In both of these cases, a TLS client could learn of a service identity
through its inclusion in the relevant certificate. The rules specified
here are intended to apply whenever service identities are included in
X.509 certificates or credentials that are derived from such certificates.
###
Let me know what you think.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
