[OAUTH-WG] Mail regarding draft-ietf-oauth-mtls

[Evan Gilman <[e-mail]>]

Hello everyone.

Very excited to see this draft. It helps tremendously in addressing
use cases around oauth client management in machine-to-machine
scenarios. Particularly, the PKI authentication method.

In reviewing the document, I noticed that the only supported method
for identifying a client using the PKI authentication method is by
referencing its distinguished name. This caught me a bit by surprise -
many newer projects aimed at automating X.509 issuance in the
datacenter utilize SAN extensions rather than distinguished name in
order to encode identity. I am further under the impression that the
community is, in general, moving away from the subject extension
altogether in favor of SAN-based identification.

Full disclosure: I am one of the maintainers on a project called
SPIFFE, which provides identity specifications for datacenter workload
applications. For X.509, SPIFFE encodes identity into a URI SAN
extension. A number of projects using SPIFFE do not configure the
subject with identifying information (SPIRE and Google Istio being
just a couple). I am also hearing of other X.509 automation projects
which are moving away from subject/distinguished name (even if they
are not using SPIFFE).

While I think support for distinguished name is absolutely necessary,
I worry that supporting it solely will render it incompatible with
some of the more modern PKIX systems and not stand the test of time. I
know that I am a little late to this, and for that I apologize... but
I feel this is a significant point.

I would like to open a discussion on supporting the most commonly used
SAN extension types in addition to distinguished name. To accomplish
this, amending section 2.1.2 `Client Registration Metadata` with
additional parameters seems appropriate. In my experience, the most
commonly used SAN extensions are: DNS name, IP address, URI, and email
address.

Are there significant drawbacks to extending the number of client
registration metadata parameters? I would very much like to see this -
without it, many existing projects will be unable to use the spec. I
am happy to contribute time and text to this, assuming people feel
that this is a beneficial addition. Sorry again for the timing

-- 
evan