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
