Hi Viktor,
My question was about identity validation, which is what 6125bis is about. So
it's a subset of your second option, "validation of certificates". And yes,
this boils to, are DANE-based EE certificates expected to adhere to the draft's
requirements.
And the reason I raised this question is that the draft defines its own scope
with these words:
This document applies only to service identities that meet these three
characteristics: associated with fully-qualified domain names (FQDNs), used
with TLS and DTLS, and are PKIX-based.
I wasn't sure whether "PKIX-based" should be interpreted to include DANE
certificates.
Thanks,
Yaron
On 6/25/22, 21:45, "Uta on behalf of Viktor Dukhovni" <uta-boun...@ietf.org on
behalf of ietf-d...@dukhovni.org> wrote:
On Fri, Jun 24, 2022 at 07:04:28PM +0300, Yaron Sheffer wrote:
> * Similarly, it is not clear to me whether certs obtained through DANE
> are in or out of scope.
I may be able to help, but I am struggling to understand the question in
sufficient detail. Can you be more specific about:
- What do you mean by "certs obtained through DANE" (typically the
certs are obtained from the TLS server certificate message, and
matching type Full(0) certificates in the TLSA record are very
rare)? Even then, these are semantically not much different from
those sent in the server certificate message, other than being
asserted or required trust anchors.
- Did you perhaps mean *validation* of certificates (received in the
usual way) via DANE TLSA records? That is, are DANE-based
expected to adhere to all the normative text in the draft?
The main thing that's different about DANE is that in some
application protocols Unknown Key Share issues are not believed to
be a concern. And in these cases EE TLSA records that specify
only the certificate or public key hash validate a presented
certificate with a matching public key regardless of lack of
matching presented identifiers or inception / expiration dates.
Validation via DANE trust-anchors is the same as validation via
local WebPKI trust anchors, except that in the case DANE-TA(2) the
trust-anchor certificate must appear in the server certificate
chain when the TLSA record provides just a hash of its SPKI (or
even just the SPKI, which I expect some implementations might not
support, though this is supported in OpenSSL).
- Either way, what is it that might then be in or out of scope?
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
