[Danish] Application-Independent Client Identity through DANE

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

Hallo Danish,

I was happy to learn that Client DANE is being worked on again.  An
opportunity that I'd like to see addressed is a mechanism for clients
to state that their identity sits under a given domain.  The way to do
that now involves LDAP, protected with TLS and DANE/DNSSEC.  There are
advantages including simplicity about doing this with Client DANE.

Would you consider the attached portion of text?  It would be a way of
achieving Realm Crossover, our globally described intention in
draft-vanrein-internetwide-realm-crossover

The general approach is to use DNSSEC-based authority for domains, and
treat the assignment of userids as the prerogative of the domain, to be
validated over a secure backlink.  The draft expired just yet, and I'd
love to update it with a reference to the following in Client DANE :)


Thanks for considering,

Rick van Rein
InternetWide.org / OpenFortress.nl



2.0.  Format 0: Application-Independent Client Identity

   The purpose of this format is to allow clients to
   state [client-user-identity]@[client-domain-name] style
   identities which are not tied to any specific application.
   This uses certificates to implement Realm Crossver
   <xref target="draft-vanrein-internetwide-realm-crossover"/>.

   In this format, domain users hold certificates signed
   under a CA certificate that is approved of in a TLSA
   record named

   _client-identity.[client-domain-name]

   The TLSA record SHOULD NOT set the TLSA RDATA field for
   Certificate Usage to match end entity certificates.

   The issuing CA or CAs approved by this statement MUST NOT
   issue any attributes that represents another domain name
   than [client-domain-name].  Note that a sequence of
   "domainComponent" or "dc" RDNs would combine to form a
   domain name.  Note that a domain name may occur as part
   of a longer attribute.

   The issuing CA or CAs approved by this statement SHOULD NOT
   issue any attributes that represent a user identity that
   has not been established by a RA run under control of the
   domain [client-domain-name].  Note that a userid may occur
   as part of a longer attribute.

   To implement these rules, the issuing CA or CAs approved by
   this statement MUST NOT produce attributes of which it does
   not known whether it represents a domain name and/or user
   identity.

   On the grounds of this TLSA statement, the relying party
   SHOULD NOT trust any other information than domain names
   and user identities.  This does not preclude that other
   paths may validate the information, possibly including
   application choices to treat attributes as informative
   suggestions without security implications.