Subject: [kitten] BrowserID mutual auth

From: Luke Howard <[email-masked]>
Date: Sat, 13 Apr 2013 19:11:24 -0400

GSS BrowserID allows authentication of the acceptor using PKIX certificates. This is an optional feature. (We use PKIX instead of BrowserID certificates as they're more likely to be available for server authentication; issuing BrowserID server certificates would likely require each RP to run a custom IdP, or a standardized provisioning protocol.)

Depending on policy, the initiator may solely verify the acceptor hostname (by looking at the dNSName SAN or least significant CN), or verify the entire acceptor service name.

In the current implementation and specification, the initiator may verify the acceptor service name by validating the URI SAN. (GSS BrowserID encodes the service name in a URN anyway, so this makes sense.)

Nico points out that it may be difficult to get CAs to issue certificates with URIs in them. Instead, he proposes that we continue to use the dNSName SAN, and encode the GSS-API service name (and the domain presumably, for RFC5178 domain-based services) into an EKU OID.  (Absence of EKUs == all services.)

Thoughts?

-- Luke (and Nico)

---

From: Luke Howard <[email-masked]>
Date: Sun, 14 Apr 2013 20:02:51 -0400

> Nico points out that it may be difficult to get CAs to issue certificates with URIs in them. Instead, he proposes that we continue to use the dNSName SAN, and encode the GSS-API service name (and t…

By encode, we mean either encode each ASCII character of the service name into an OID element, or maintain a registry mapping GSS/SASL service names to OIDs.

Alternatively, we could use otherName with an OID representing a service name (but that has similar issues to using a URI).

Ultimately, if service-constrained certificates are to work, we need to find a way that will work with deployed CA policies.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sun, 14 Apr 2013 20:15:38 -0400

Nico points out that PKU2U may have addressed this. Looking at draft-zhu-pku2u:

   3.  If a X.509 certificate has a dNSName SAN that matches the
       hostname part of the host-based service principal name, and
       either the anyExtendedKeyUsage extended key usage (EKU), or no
       EKU is present, or an EKU is present which corresponds to the
       service part of the host-based service principal name, then the
       X.509 certificate matches.  The id-kp-serverAuth EKU SHALL be
       considered to match the 'HTTP' service name.

So, whereas currently the BrowserID draft specifies that id-kp-serverAuth (or a BrowserID equivalent) is mandatory but not bound to a particular service name, PKU2U binds it to HTTP and establishes a registry for other services.

There's certainly an argument for being consistent with PKU2U, but a registry (as opposed to an algorithmic mapping) is a burden to implementors and/or deployers.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Sun, 14 Apr 2013 19:17:57 -0500

Ah, I just remembered that the PKU2U I-D has all the required text
regarding EKU.

---

From: Nico Williams <[email-masked]>
Date: Sun, 14 Apr 2013 19:52:28 -0500

Luke would prefer an algorithmic service name to eku mapping.  quite
frankly, so would I.

---

From: Luke Howard <[email-masked]>
Date: Sun, 14 Apr 2013 21:46:14 -0400

On 14/04/2013, at 8:52 PM, Nico Williams <[email-masked]> wrote:

> Luke would prefer an algorithmic service name to eku mapping.  quite frankly, so would I.

Hmm, I think I could go either way. Consistency with PKU2U wouldn't be a bad thing.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sun, 14 Apr 2013 21:57:40 -0400

Also see id-pkinit-san in RFC 4556 (also referenced from PKU2U). That contains an ASN.1 encoded KRB5PrincipalName. I'm not sure what CAs support that, but perhaps it's a cleaner encoding of a service name than a URI.

So options are one or some combination of:

* dNSName SAN, service name ignored (we probably want to support this anyway)

* dNSName SAN, service name mapped from EKU through a registry

* dNSName SAN, service name mapped from EKU algorithmically

* id-pkinit-san (RFC 4556), containing a Kerberos name

* URI SAN containing BrowserID audience, service name encoded into URN

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Sun, 14 Apr 2013 21:03:26 -0500

On Sunday, April 14, 2013, Luke Howard wrote:

> Also see id-pkinit-san in RFC 4556 (also referenced from PKU2U). That
> contains an ASN.1 encoded KRB5PrincipalName. I'm not sure what CAs support
> that, but perhaps it's a cleaner encoding of a service name than a URI.
>

We should have just one EKU mapping, IMO.  I can live with a registry, but
note that nothing has stopped people from using whatever GSS service names
they wished without registration, and this EKU thing would put an end to
that -- annoying, no?

> * id-pkinit-san (RFC 4556), containing a Kerberos name

We may want this for domain-based names.

> * URI SAN containing BrowserID audience, service name encoded into URN

All of these are OK, but new PKIX name types depend on CA support (in
software, procedures) for issuance, so to the extent that we can avoid
that, all the better.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Mon, 15 Apr 2013 09:05:28 -0400

> We should have just one EKU mapping, IMO.  I can live with a registry, but note that nothing has stopped people from using whatever GSS service names they wished without registration, and this EKU thing would put an end to that -- annoying, no?

True. I've put all on-the-table options in draft -02, but obviously we need to trim them down before publication. While I do like the consistency of id-pkinit-san, it also means implementations have to have an (exposed) ASN.1 library. Ultimately broad CA support (as you said, in software and procedures) should be the deciding factor.

See below, anyway.
   If the initiator policy requires the acceptor service name to be
   validated in addition to the acceptor host name, the service name
   MUST be validated against one of the following:

   o  A service-name EKU from the registry defined by [I-D.zhu-pku2u]

   o  An algorithmically mapped service-name EKU (TBD)

   o  A spn expressed as a realm-less KRB5PrincipalName in the id-
      pkinit-san otherName SAN (see [RFC4556] Section 3.2.2)
   o  A BrowserID audience URN containing the spn, encoded in a URI SAN
      (see Section 3.2)

   o  An out-of-band binding to the certificate

   If the initiator policy only requires the acceptor host name to be
   authenticated, or an EKU binding is used (rather than the id-pkinit-
   san or URI SAN, which contain a host name), then the host component
   of the service name (service-host) MUST be present as a value for the
   dNSName SAN or as the least significant Common Name RDN.

   If the acceptor name contains a service-specific component and the
   initiator policy requires this to be authenticated, note only the id-
   pkinit-san or URI SANs provide this binding.
-- Luke

---

From: [email-masked] (Martin Rex)
Date: Mon, 15 Apr 2013 17:42:04 +0200 (CEST)

Luke Howard wrote:
> Also see id-pkinit-san in RFC 4556 (also referenced from PKU2U).
> That contains an ASN.1 encoded KRB5PrincipalName. I'm not sure what
> CAs support that, but perhaps it's a cleaner encoding of a service
> name than a URI.

The problem with KRB5PrincipalName as otherName SAN is that this structure
is an ambiguous mess, and its definition and semantics smeared over several
documents, rather than a simple, well-defined datatype that is
easily parsable by non-Kerberos RPs.

The MS-UPN otherName SAN is **MUCH** easier to deal with.

> * URI SAN containing BrowserID audience, service name encoded into URN

That list seems to be missing the "Service Name" otherName SAN

  http://tools.ietf.org/html/rfc4985

Btw. HTTP-over-TLS (rfc2818) does not recognize or require the id-kp-serverAuth
nor the id-kp-clientAuth.

Both EKUs (id-kp-serverAuth and id-kp-clientAuth) were defined exclusively
by PKIX (rfc2459, rfc3280, rfc5280), and the PKIX definition is limited
to "TLS WWW server/client authentication".  There is no clear definition
what "WWW" means.  The conservative assumption would be, that it refers
to "HTTP over TLS", which has been retroactively documented ("informative")
in rfc2818.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Apr 2013 10:56:56 -0500

>   http://tools.ietf.org/html/rfc4985

Oh, that's awesome!  Much better than having an EKU OID column added to the
GSS service name registry.

Are there CAs that know how to handle this?  Because that's key here, and I
assume that getting CAs to understand EKUs is relatively easy, since EKUs
are a constraint on certs the CAs already know how to and are willing to
issue.

> to "HTTP over TLS", which has been retroactively documented ("informative")

Thanks for the info Martin!

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Mon, 15 Apr 2013 19:32:24 +0200 (CEST)

Nico Williams wrote:
> Martin Rex wrote:

Myself, I don't know about CAs and what they offer.

Btw. here is the guidance from rfc6125:

  http://tools.ietf.org/html/rfc6125#section-3

Although I personally do not believe in certificate name constraints,
existing specs (PKIX for DNSName, PKIX for URI and
rfc4985 for otherName SRVName) at least contain name constraints
processing rules for them.

AFAIK, there are no name constraints processing rules defined for the
KerberosPrincipalName otherName SAN. (And Microsoft's MS-UPN does not
have a public spec, nor published name constraints processing rules).

-Martin

---

From: Luke Howard <[email-masked]>
Date: Mon, 15 Apr 2013 13:57:12 -0400

> The MS-UPN otherName SAN is **MUCH** easier to deal with.

That's not applicable to our use case because it is for client principal names only. (The protocol uses BrowserID rather than PKIX certificates for client authentication.)

>  http://tools.ietf.org/html/rfc4985

Ah, thanks for this! Are GSS and DNS service names always aligned?

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Mon, 15 Apr 2013 13:59:02 -0400

> have a public spec, nor published name constraints processing rules).

Well, the UPN suffix namespace in Active Directory is distinct from the domain namespace (although they may have common members). Each forest has a set of valid UPN suffixes, and trusts between forests also specify which suffixes they will accept.

Anyway, this has nothing to do with BrowserID mutual auth. :-)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Mon, 15 Apr 2013 14:17:07 -0400

> Ah, thanks for this! Are GSS and DNS service names always aligned?

For example, RFC 6120 registers "xmpp" as a GSS-API service name, but "xmpp-client" and "xmpp-server" as IANA service names. So there's no straightforward mapping.

I'm also curious why PKU2U did not use RFC 4985. Larry?

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Mon, 15 Apr 2013 14:23:33 -0400

>  http://tools.ietf.org/html/rfc6125#section-3

Interesting. Following the RFC6125 logic, we should use the URI SAN, which is what I originally proposed! (We still have the issue of whether CAs will actually issue certificates with URIs in them.)

Another thing: in our current draft, I suggested it's a matter of initiator policy whether they wish to require a complete service name match (using a URI or PKINIT SAN, or EKU) or just verify the dNSName/CN. Would it better to say that all services are allowed by a certificate lacking a service name binding?

-- Luke

---

From: Larry Zhu <[email-masked]>
Date: Mon, 15 Apr 2013 18:54:41 +0000

Hi Luke,
I am catching up the context. Can you expand on the question? I do not think PKU2U has any restrictions on the use of RFC4985, right? Thanks.

-----Original Message-----
From: Luke Howard [mailto:[email-masked]] 
Sent: Monday, April 15, 2013 11:17 AM
To: [email-masked]
Cc: Larry Zhu
Subject: Re: [kitten] BrowserID mutual auth

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Mon, 15 Apr 2013 15:12:42 -0400

Hi Larry,

> I am catching up the context. Can you expand on the question? I do not think PKU2U has any restrictions on the use of RFC4985, right? Thanks.

The context is, for a new GSS-API mechanism that supports authentication of the acceptor using PKIX certificates:

“How should such certificates be bound to GSS-API service principal names (SPNs) where it is desired to authenticate the service name as well as the acceptor host name?” [1]

There seem to be a bunch of options:

* the PKU2U EKU registry
* a putative encoding of the service name contents into an EKU OID
* a URI SAN containing a URN (the mechanism in question uses URIs natively, so this makes sense)
* RFC4556 KRB5PrincipalName (the mechanism in question uses Kerberos-like names, so this also makes sense)
* RFC4985 (simple, but assumes GSS and IANA service names are equivalent)

Nico's biggest concern is: given this mechanism is designed to be used over the Internet, what will be most interoperable with existing CA policies? This is the advantage of an EKU, because CAs can continue to use their existing validation policies to certify the SAN, and consider the EKU as an additional restriction. The disadvantage of the PKU2U EKU registry is that implementations would have to be updated to support new or arbitrary service names.

-- Luke

[1] Note here I am using "service name" to mean "http" or "host" and "service principal name" to mean that bound to a host, e.g. "host/example.com" in our native representation, or "[email-masked]" as a  GSS_C_NT_HOSTBASED_SERVICE. Let's avoid RFC5178 names for now.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 15 Apr 2013 12:28:10 -0700

Are you thinking this means that the PKU2U draft should be revived and published?  Or just that the text on EKU should be pulled into the BrowserID draft if applicable

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Sunday, April 14, 2013 5:18 PM
To: Luke Howard
Cc: [email-masked]; Ryan Hurst
Subject: Re: [kitten] BrowserID mutual auth

Ah, I just remembered that the PKU2U I-D has all the required text regarding EKU.

---

From: Luke Howard <[email-masked]>
Date: Mon, 15 Apr 2013 15:34:06 -0400

> Are you thinking this means that the PKU2U draft should be revived and published?  Or just that the text on EKU should be pulled into the BrowserID draft if applicable

Good point; the BrowserID draft already references a bunch of abandoned Internet Drafts, such as NegoEx. (We are planning to pull the NegoEx text out though.)

So, we could just import the text from the PKU2U draft, but both drafts can't each update the IANA GSS-API service name registry to include an EKU. How we proceed depends on (a) whether we choose the PKU2U approach and (b) whether the PKU2U draft is to be revived.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Apr 2013 14:54:48 -0500

On Monday, April 15, 2013, Luke Howard wrote:

> That's not applicable to our use case because it is for client principal
> names only. (The protocol uses BrowserID rather than PKIX certificates for
> client authentication.)
>

They are!

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Apr 2013 15:59:01 -0500

On Monday, April 15, 2013, Luke Howard wrote:

> For example, RFC 6120 registers "xmpp" as a GSS-API service name, but
> "xmpp-client" and "xmpp-server" as IANA service names. So there's no
> straightforward mapping.

That's a spec bug, IMO.  We could bake that in code.  we could update IANA
instructions to avoid this in the future.

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Apr 2013 16:06:54 -0500

> instructions to avoid this in the future.

 We should probably update RFC2743 to indicate that (with exceptions) the
service name component of host-based service name should match service
names from the IANA ports registry.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 15 Apr 2013 15:13:01 -0600

On 4/15/13 2:59 PM, Nico Williams wrote:
>     For example, RFC 6120 registers "xmpp" as a GSS-API service name,
>     but "xmpp-client" and "xmpp-server" as IANA service names. So
>     there's no straightforward mapping.
>
>
> That's a spec bug, IMO.  We could bake that in code.  we could update
> IANA instructions to avoid this in the future.
>
A bug in RFC 6120 or in RFC 2743?

Peter

---

From: Luke Howard <[email-masked]>
Date: Tue, 16 Apr 2013 11:28:13 -0400

FWIW, my gut feeling is that we should do what PKU2U does, including assigning EKUs to currently registered GSS service names. For unregistered service names, or domain-based service names, the URI SAN should be used. (Not sure whether we should ignore the EKUs in that case?)

Of course, my gut is directly indexed to ease of implementation and what my current implementation does. I am usually happy to change my mind ;-)

-- Luke

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 24 Apr 2013 18:06:43 -0400

> instructions to avoid this in the future.

Um.  ssh/telnet/whatever vs host ?

---

From: Luke Howard <[email-masked]>
Date: Wed, 24 Apr 2013 23:42:55 +0100

> Um.  ssh/telnet/whatever vs host ?

And www/http vs http. My thoughts were described in my message of 16 April, anyway (which was: do what PKU2U does, but also allow URI SANs containing BrowserID URNs, in which case SANs/EKUs are ignored).

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Wed, 24 Apr 2013 18:08:05 -0500

> Um.  ssh/telnet/whatever vs host ?

Right, we'll have exceptions.  But why add more such things?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Apr 2013 16:40:46 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> FWIW, my gut feeling is that we should do what PKU2U does,
    Luke> including assigning EKUs to currently registered GSS service
    Luke> names. For unregistered service names, or domain-based service
    Luke> names, the URI SAN should be used. (Not sure whether we should
    Luke> ignore the EKUs in that case?)  Of course, my gut is directly

I tend to agree.
I tend to agree with the possible exception of URI SAN.
I wonder if the SRV SAN would not be more appropriate both here and for
pku2u.
In the case where you have a service-specific SAN I think ignoring EUK
is fine.

---

From: Luke Howard <[email-masked]>
Date: Thu, 25 Apr 2013 22:25:38 +0100

> I wonder if the SRV SAN would not be more appropriate both here and for

I'm on the fence. The SRV SAN has the problem of differing IANA vs GSS service names. The URI SAN has the problem of, well, there isn't a standardised URN form for GSS service names beyond what we define in the BrowserID draft.

Either I suspect is going to be problematic for CAs to issue. Name constraints should be imposable on both, but the relying party is going to need to know how to apply them.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Apr 2013 17:55:35 -0400

Yes. I'm fairly sure CAs will issue neither.

I'm definitely in favor of  SRV SAN over a URN for GSS service names.
I thought you were talking about URI sans like
xmpp://painless-security.com

---

From: Luke Howard <[email-masked]>
Date: Thu, 25 Apr 2013 23:02:17 +0100

> xmpp://painless-security.com

No, that would introduce another set of mapping problems. URIs in GSS BrowserID look like urn:x-gss:spn where spn is a Kerberos-like service name. For example, urn:x-gss:xmpp/painless-security.com.

Hopefully we can get a non-experimental URN assigned when we progress the draft (tips, anyone?)

(Technically, we could probably just put the service name in the assertion directly, given that we specify the protocol behaviour for both endpoints. But it would be valid for a BrowserID implementation to reject an audience that is not a valid URI.)

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Apr 2013 19:20:35 -0400

I think srv san sounds better than that

Luke Howard <[email-masked]> wrote:

>No, that would introduce another set of mapping problems. URIs in GSS
>BrowserID look like urn:x-gss:spn where spn is a Kerberos-like service
>name. For example, urn:x-gss:xmpp/painless-security.com.
>
>(Technically, we could probably just put the service name in the
>assertion directly, given that we specify the protocol behaviour for
>both endpoints. But it would be valid for a BrowserID implementation to
>reject an audience that is not a valid URI.)
>
>-- Luke

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Luke Howard <[email-masked]>
Date: Fri, 26 Apr 2013 01:12:58 +0100

> Me too.

I disagree but I am happy to change my mind if you can convincingly work around the IANA port / GSS service name conflicts.

> The "gss" bit seems superfluous (we don't have that in, say,
> Kerberos), and at the same time insufficient (there's no GSS name-type
> indication; but then, though Kerberos has a name-type, it's
> effectively optional anyways).

This is not a representation of a generic GSS name. The "gss" refers to the fact that this usage of the BrowserID protocol is for a GSS-API mechanism. Please see:

	http://tools.ietf.org/html/draft-howard-gss-browserid-04#section-3.2

This contains a "spn" which is defined here:

	http://tools.ietf.org/html/draft-howard-gss-browserid-04#section-3.1.1

If you don't like "x-gss" please feel free to suggest something else, e.g. "x-spn". :-)

> In the acceptor's response token?  In that case it fails to work as a
> constraint on the certificate (since the acceptor can sign whatever it
> wants then).

No, the audience claim is only in the request assertion. See:

	http://tools.ietf.org/html/draft-howard-gss-browserid-04#section-6

and the BrowserID spec here:

	https://github.com/mozilla/id-specs/blob/prod/browserid/index.md

> We might be able to do something else: use BrowserID for the acceptor
> credential with the BrowserID certificate signed with the key for a
> TLS server PKI EE cert with an EKU denoting the ability to do this.
> (Yeah, this just after deciding to use PKIX for the acceptor
> credential; sucks, I know.  But this should be easier to manage w.r.t.
> CAs.)

Maybe. I'm loath to make things more complicated, but I guess it depends how much we want to embrace the existing X.509 CA model. (I was going to write "subvert".)

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 Apr 2013 19:34:06 -0500

Me too.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 25 Apr 2013 19:23:59 -0600

On 4/25/13 4:02 PM, Luke Howard wrote:
>> I'm definitely in favor of  SRV SAN over a URN for GSS service 
>> names. I thought you were talking about URI sans like 
> No, that would introduce another set of mapping problems. URIs in
> GSS BrowserID look like urn:x-gss:spn where spn is a Kerberos-like 
> service name. For example, urn:x-gss:xmpp/painless-security.com.
> 

Hi Luke,

I'm happy to help with that. It's really quite straightforward. See
RFC 3406 and draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05.

Peter

P.S. Oh, and if I have my way, experimental URN namespaces will be
going away... :-)

http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05#section-5

---

From: Luke Howard <[email-masked]>
Date: Fri, 26 Apr 2013 08:42:51 +0100

> Maybe we can sidestep that by switching to using BrowserID credentials
> for the acceptor.

Indeed. We could allow either/or. Of course, then we need to define how service names are encoded in BrowserID certificates, but it's a lot simpler when everything is JSON. :-)

> Sure, x-spn.

OK, I will update the draft. But obviously, this will have to be changed to something like urn:ietf:params:gss:spn anyway (the gss registry is created by the EAP naming draft, hopefully that'll be done before us).

> Right, if we can't change the CAs, sidestep them.  But I'm afraid that
> there may be nothing we can to get CAs to issue suitable certs.  Do
> CAs issue certs with EKUs?  We have one CA telling us "no".

Let's step back a little. Maybe most deployments will be happy with host-based certificates? (No service name.)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 26 Apr 2013 08:43:40 +0100

> RFC 3406 and draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05.

Actually maybe we want RFC 3553 and something like urn:ietf:params:gss:spn?

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 26 Apr 2013 17:00:46 +0100

> credential; sucks, I know.  But this should be easier to manage w.r.t.

Ironically this might force CAs to be more flexible about issuing certificates with the necessary EKUs or SAN extensions, if they have competition. :-)

-- Luke

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 26 Apr 2013 10:03:22 -0600

On 4/26/13 1:43 AM, Luke Howard wrote:
>> I'm happy to help with that. It's really quite straightforward.
>> See RFC 3406 and draft-ietf-urnbis-rfc3406bis-urn-ns-reg-05.
> 

Sure, that's even simpler. I don't think we need a namespace ID here,
since we need only a single namespace, not a whole series of them.

Peter

---

From: [email-masked] (Martin Rex)
Date: Fri, 26 Apr 2013 18:59:34 +0200 (CEST)

A simple comment on use of "urn" in cert SANs.  It seems to be currently
impossible to constrain "urn" SAN by name contraints in X.509v3 certs.

>From a recent PKIX discussion:
  http://www.ietf.org/mail-archive/web/pkix/current/msg32574.html

-Martin

---

From: Luke Howard <[email-masked]>
Date: Fri, 26 Apr 2013 18:08:50 +0100

>  http://www.ietf.org/mail-archive/web/pkix/current/msg32574.html

Thanks for this Martin. I guess this is probably another nail in the coffin of using URNs in SANs. It's a pity because they're text, easier to encode than the Kerberos SAN, don't have the IANA/GSS service name ambiguity, etc. But I am fine with that :-)

-- Luke