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

Thanks Rick,

I'm reviewing, and hope others will too.

I'll note that although this work is expected to be done in the context of
an IOT focussed working group, the DANE client authentication draft is
general purpose in nature, and we know that there are several folks from
other application communities interested in this (SMTP, etc). So, I'm
personally very open to expanding the utility of the draft to your Internet
identity proposals, and adding another proposed format to support
application independent identities sounds quite reasonable to me. Will
circle back with more detailed comments soon.

Shumon.

On Fri, Apr 2, 2021 at 2:34 AM Rick van Rein <rick@openfortress.nl> wrote:

> Hello Danish,
>
> Shumon suggested that the text I wrote might be too specific
> for an application that I have in mind.  This is an alternative
> text aiming to say just enough to support meaningful conclusions.
>
> I mention "uid" and "dc" attributes as a hint without force.
> This may be helpful to provide some guidance to allow various
> applications to come together.
>
>
> Cheers,
>  -Rick
>
>
> 2.0.  Format 0: Application-Independent Client Identity
>
>    The purpose of this format is to certify client's
>    [client-user-identity]@[client-domain-name] style
>    identities without ties to any specific application or
>    protocol.  This is a mechanism to support 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]
>
>    TLSA records with such names SHOULD NOT set the RDATA field
>    for Certificate Usage to match end entity certificates.
>
>    The issuing CA or CAs approved by this statement MUST NOT
>    publish certificate attributes whose meaning specify the
>    [client-user-identity], the [client-domain-name] or any
>    parts or combinations thereof, except when (1) the full
>    [client-domain-name] is represented and (2) that domain has
>    approved the [client-user-identity] and the public key to
>    belong to the requesting client for at least the period
>    of validity of the certificate to be issued.
>
>    After extracting the [client-domain-name] from a client
>    certificate and validating the certificate to comply to
>    this TLSA record, a relying party can trust attributes
>    that specify the [client-user-identity] such as "uid", and
>    the [client-domain-name] such as in a "dc" sequence, to
>    adhere to the authoritative hierarchy of Internet names.
>
> --
> Danish mailing list
> Danish@ietf.org
> https://www.ietf.org/mailman/listinfo/danish
>