Re: [Danish] Application-Independent Client Identity through DANE

[Rick van Rein <[e-mail]>]

Hello Ash,

> This is interesting. So, let me summarize what I understand so far: this
> provides a way of conveying an organization's CA so that any sub-identity
> may be authenticated without explicitly creating a record for every
> sub-identity in DNS. Is my understanding correct?

Yes.  Although I barely focus on finding certificates, as I am assuming
a rich user or server environment.  It's interesting though.

The central idea is to trust a domain on the basis of (root or
intermediate) CA certificates in DANE; they might be stored or hashed in
DNS.

> Here's an overlap (maybe): In the PKIX-CD draft (
> https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd/) we present a
> method by which an authenticating entity may use the EE's DNS name and AKI
> (both found in the certificate) to construct a URL for discovering the CA
> certificate.

That is an interesting idea, and perhaps not specific to client DANE.  I
would venture to guess that it solves a general problem, possibly even
of finding a root CA that may be solely trusted on grounds of DANE.  I
was lazily proposing to put whole certificates into DNS, perhaps even
for intermediate CAs.

> Even if you don't publish the EE certs for DNS-based identities in DNS, you
> can still use DNS to discover the trust chains. You can still get the DNS
> name or email address out of the presented certificate and use that with
> the AKI to construct a URL where the intermediate certificate that can
> verify the EE certificate should be found.

Yes.  This is also a way to get away from a large-but-limited set of
well-known CAs, so it might help in applications that are more diverse,
such as a domain-local CA or even peer-to-peer networks that employ DNS.

> If this pattern works for your use case, then you'll have some
> cross-compatibility for other use cases, where we do need the certificate
> to be discoverable in DNS (object security use cases) as well as having a
> sort of transitional mode between traditional PKI and DANE for
> authentication, both hinging around DNS names for entities.

I think it *almost* works.

Your "_device" is an example of an identity grouping label, but it is
not clear to me if this is something that is formally registered or a
local network choice.

When formally registered, a specification could be attached that defines
the semantics of that name.  As a consequence, it would be possible to
visit completely foreign domains for the first time to discover what
their certificates are saying.  The shared semantics are the pivotal
point here; applications need to know what they can assume when they
find such a label.  This is a reason why SRV records work so well, yet
are flexible for new specifications to adopt.

It would be possible to make a choice to trust only configured domains
to set a configured _label.  Then, anyone can add names without
formalities, but a label _client-identity would not have necessary
meaning; the domain owner would not be expressing anything but data,
with no necessarily implied meaning.  So this idea of registered naming
is vital to the idea of Realm Crossover.

The ideas of with/without semantics can both be used with a _label that
says "make no assumptions, unless you were configured to look underneath
this one".

Can you elaborate on that please?


Cheers,
 -Rick