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

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

Hello Ash,

> I agree with you that we will need a registry of identity grouping
> labels, if the construct does not fit within another existing registry.

I hadn't checked if a suitable registry already exists, but the
"Underscored and Globally Scoped DNS Node Names" could be it, because
RFC 8552 defines it as just what I had in mind.

https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Note that these are "static" _labels, defined under Expert Review, to be
assigned structure/semantics while at it, which is what I meant.  These
are not "dynamic" _node123 labels that could be defined by clients,
though that would be possible under a static _label too.  I am not sure
what you are looking for.

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

Yes, that's a nice and terse summary of what I have in mind.

> This sounds like it would require a change in how TLS works,

Not the protocol, but the trust evaluation.  It's not that different
from server DANE applications though.  In fact, trust in a client/peer
certificate is often defined locally.  One of those local definitions
could be to adopt the "CXOVER" or "Certificate Crossover" mechanism.

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

This is not mine to judge.

> What are your thoughts on signing and encryption for object security use
> cases?

Before you mentioned sigverify and encrypt, which are the pivotal points
where trust is needed.  I'd say that the technical operations with these
names are not what users need; they need to use them in protocol
settings for purposes: authentication, integrity validation, and indeed
from-here-to-recipient privacy.

> How do you see entity certificate discovery happening?

Ehm, use cases...

1. TLS clients would transmit the identity that the want trusted.
   The other TLS peer retrieves the uid=,dc=,dc= from the certificate
   and does a TLSA lookup for the dc=,dc= domain to validate the CA
   and trust the uid=,dc=,dc= remote TLS client.

2. S/MIME signatures https://tools.ietf.org/html/rfc5652#section-5.1
   intends for signerInfos-mentioned certificates to be contained
   in the certificates set.  Validation retrieves the uid=,dc=,dc=
   from the certificate and does a TLSA lookup for the dc=,dc= domain
   to validate the CA and trust the uid=,dc=,dc= sender identity.
   S/MIME signatures intend to include the certificate chain.

3. S/MIME encryption https://tools.ietf.org/html/rfc5652#section-5.2
   is cryptographically initialised by the sending party, so this is
   the case that requires download of certificates.  To validate the
   certificate retrieved from such a download, the uid=,dc=,dc= in
   the certificate is verified against the intended recipient and
   then the sender does a TLSA lookup or the dc=,dc= domain and
   validates the downloaded certificate can be trusted; it then sends
   S/MIME content which intends to include the certificate chain(s).

For downloading in 3, I tend to prefer the standards' prescribed choice
of LDAP because of its rich semantics.  For small devices there may be
other considerations, but they are likely to be less rich, and so not a
general solution.  (BTW, I have made a very small LDAP stack too, but to
date it has only been unit-tested.)


Inviting opinions :)


Cheers,
 -Rick