Is there an intention that any semantics are attached to the SAN being a URI or
DNS name or IP or ...? Or is it still intended to be an opaque identifier?
> On 6 Nov 2018, at 01:55, Brian Campbell
> <bcampbell=40pingidentity....@dmarc.ietf.org> wrote:
>
> Thanks Evan for bringing this to the WG's attention. More or less the same
> question/issue was raised yesterday in the area director's review of the
> document as well. I plan to bring this up as a discussion item in the meeting
> today. But my sense from some early discussions is that there is likely to be
> (rough) consensus to make some change in order to allow a SAN to be specified
> as the certificate subject identifier in the PKI client auth mode. We'll need
> to figure out the specifics of how that works. I don't think there are
> significant drawbacks to extending the number of client registration metadata
> parameters per se. I guess I've just been attracted to the idea of
> overloading the existing value because that felt like maybe a less invasive
> change. But perhaps that's shortsighted. And there's nothing inherently wrong
> with additional client metadata parameters.
>
> I don't know if we could get away with a single new parameter that could
> carry the value for any SAN type. Something like, { ...
> "tls_client_auth_san": "spiffe://trust-domain/path" ...}. In practice I feel
> like that'd probably be okay but in theory there's the potential for
> confusion of the value across different types. So probably there's a need to
> indicate the SAN type too. Either with more client metadata parameters like
> tls_client_auth_san_uir, tls_client_auth_san_email, tls_client_auth_san_ip,
> etc. or maybe with a structured value of some sort like {...
> "tls_client_auth_san": {"type":"URI", "value":"spiffe://trust-domain/path"}
> ... }. And then deciding which types to support and if/how to allow for the
> extensible types.
>
> Anyway, those are just some thoughts on it. And it'll be discussed more
> today. Suggested/proposed text is always helpful though (even if it's not
> used directly it can help move the conversation forward and/or help editor(s)
> to have prospective wording).
>
>
>
>
>
>> On Tue, Nov 6, 2018 at 5:53 AM Evan Gilman <evan2...@gmail.com> wrote:
>> 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
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.. If you have
> received this communication in error, please notify the sender immediately by
> e-mail and delete the message and any file attachments from your computer.
> Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
