Hi Evan, I scanned through the SPIFFE docs but didn’t any mentioning of OAuth (just plain X.509). What’s your plan for introducing OAuth and mtls?
kind regards,
Torsten.
> Am 13.11.2018 um 00:59 schrieb Evan Gilman <evan2...@gmail.com>:
>
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
