Thank you everyone for the feedback.
I am currently working on the sample text, and should be complete in
the next couple days. Apologies for the delay.
On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell
<bcampb...@pingidentity.com> wrote:
>
> Sure, I think they could be treated as different different
> client_auth_methods. But there is a lot more commonality than differences to
> the point where I think it makes sense to keep it all in a single document
> and under a single client auth method with just the variation on which name
> is being used.
>
> On Tue, Nov 6, 2018 at 5:11 PM Justin P Richer <jric...@mit.edu> wrote:
>>
>> Would it make sense for these to be a different client_auth_method entirely?
>> Much the same way that we have private_key_jwt and client_secret_jwt today,
>> both of which use the JWT assertion framework but have very different keying
>> and security assumptions. In the same way, here you’re still validating the
>> cert but the means by which it’s validated is different, so the auth method
>> is arguably not going to benefit from being overloaded. Caveat, I’ve not
>> built out a system using SANs in any meaningful way.
>>
>> If we were to do that, this draft could go forward as-is (since it’s fairly
>> done in my opinion) and a new document could better define the semantics for
>> the various SAN types, but while building on the framework and concepts
>> listed in here.
>>
>> — Justin
>>
>> On Nov 6, 2018, at 3:52 PM, Evan Gilman <evan2...@gmail.com> wrote:
>>
>> Response(s) inline
>>
>> On Mon, Nov 5, 2018 at 11:53 PM Neil Madden <neil.mad...@forgerock.com>
>> wrote:
>>
>>
>> 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?
>>
>>
>> There are some extra things we could do if we attached type-specific
>> semantics to the matching (e.g. DNS wildcarding etc), however I think
>> that continuing to use the values as opaque identifiers would get us
>> most of what we need while keeping things simple.
>>
>> 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.
>>
>>
>> I am far from an authority here, but it is my understanding that one
>> of the primary drivers in supporting SAN over Subject is that the
>> values are strongly typed. While some of the advantages gained from
>> this may be less useful in our own context, I feel that it make sense
>> to keep the values separate and not overload a single value. Whether
>> that means dedicated metadata parameters or a structured parameter
>> value, I am not sure what the tradeoffs would be, but both options
>> sound suitable to me.
>>
>> 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).
>>
>>
>> Great. I will work on some sample text since it sounds like that would
>> be generally helpful
>>
>> 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
>>
>>
>>
>>
>> --
>> 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.
--
evan
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
