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

[Ash Wilson <[e-mail]>]

Hi Rick,
Sorry to keep you waiting on a reply.
I agree with you that we will need a registry of identity grouping
labels, if the construct does not fit within another existing registry.

The use case for discovering CA certificates makes sense to me, and with
such a mechanism, you can simplify the use of private PKI for establishing
TLS sessions. Having an underscore label representing the client identity
type, immediately to the left of the identity grouping label, could fit for
generic discovery of CA certificates via TLSA records, secured by DNSSEC.
This sounds like it would require a change in how TLS works, and for this
case we will also need a registry of client identity types. But I think
this might work, and it doesn't necessarily need to carry the complexity of
the PKIX-CD discovery pattern as long as you have DNSSEC configured for
your zone.

What are your thoughts on signing and encryption for object security use
cases? How do you see entity certificate discovery happening?

-Ash

On Tue, Apr 6, 2021 at 2:11 AM Rick van Rein <[e-mail]> wrote:

> 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
>


-- 

*Ash Wilson* | Technical Director
*e:* [e-mail]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.