Thanks for referring us to this spec. How I read it, every way to represent an application identity may require specific verification rules (including typ specific syntactical rules).
In my interpretation this means we must explicitly manage expected type and value of the identifier used to match the client identity. It could also require the AS to apply type specific matching rules. Comments? > Am 07.11.2018 um 04:03 schrieb Rifaat Shekh-Yusef <rifaat.i...@gmail.com>: > > You might want to look at RFC6125 which covers this topic and provides > recommendations for representing application in certificates: > https://tools.ietf.org/html/rfc6125 > > Regards, > Rifaat > > > On Tue, Nov 6, 2018 at 3:53 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 > _______________________________________________ > 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
