Subject: representation of multiple otherName entities

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Aug 2008 15:12:21 -0600

In the upcoming revisions to the core XMPP RFC (see Section 15.2.1 of 
rfc3920bis at [1]), we plan to recommend inclusion of two different 
otherName extensions in server certificates:

1. id-on-dnsSRV (per RFC 4985)

2. id-on-xmppAddr (for backwards-compatibility with RFC 3920)

Pardon my ignorance, but it's not clear to me from RFC 5280 how these 
name types are to be represented in a certificate. Shall the certificate 
contain one subjectAltName extension containing two otherName entities, 
or two subjectAltName extensions (each containing a single otherName 
entity)?

Thanks.

/psa

[1] http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 6 Aug 2008 09:08:51 -0400

Peter,

RFC 5280 section 4.2 says:
   A certificate MUST NOT include more
   than one instance of a particular extension.  For example, a
   certificate may contain only one authority key identifier extension
   (Section 4.2.1.1).

Dave

-----Original Message-----
From: Peter Saint-Andre

Shall the certificate contain one subjectAltName extension containing
two otherName entities, or two subjectAltName extensions (each
containing a single otherName entity)?

---

From: Russ Housley <[email-masked]>
Date: Wed, 06 Aug 2008 09:52:25 -0400

I would recommend on subjectAltName extension with more than one name in it.

This is supported by the syntax:

    SubjectAltName ::= GeneralNames

    GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

Russ

At 05:12 PM 8/5/2008, Peter Saint-Andre wrote:

>In the upcoming revisions to the core XMPP RFC (see Section 15.2.1 
>of rfc3920bis at [1]), we plan to recommend inclusion of two 
>different otherName extensions in server certificates:
>
>Pardon my ignorance, but it's not clear to me from RFC 5280 how 
>these name types are to be represented in a certificate. Shall the 
>certificate contain one subjectAltName extension containing two 
>otherName entities, or two subjectAltName extensions (each

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 06 Aug 2008 09:52:50 -0400

The certificate must include both names in a single subjectAltName 
extension:

   RFC 5280, Section 4.2 (Certificate Extensions):
      A certificate MUST NOT include more than one instance of a
      particular extension.  For example, a certificate may contain only
      one authority key identifier extension (Section 4.2.1.1).

   X.509, Clause 8 (Public-key certificate and CRL extensions):
      For all certificate extensions, CRL extensions, and CRL entry
      extensions defined in this Directory Specification, there shall be no
      more than one instance of each extension type in any certificate,
      CRL, or CRL entry, respectively.

The subjectAltName extension holds a sequence of one or more 
GeneralName.  There is no limit on the number of names that may appear 
in the sequence, and the extension may even include more than one name 
of the same name form (e.g., two email addresses).

Dave

Peter Saint-Andre wrote:
> name types are to be represented in a certificate. Shall the 
> otherName entities, or two subjectAltName extensions (each containing 
> a single otherName entity)?
>
> Thanks.
>
> /psa
>
> [1] 
> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 08 Aug 2008 12:09:25 -0600

Thanks to everyone who replied for setting me straight.

A follow-up question regarding implementation: Is it common for well 
known software (e.g., OpenSSL, GnuTLS) to support the generation and 
processing of subjectAltName extensions with more than one GeneralName? 
If not, the XMPP community may need to decide on including one or the 
other otherName entity, but not both.

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 08 Aug 2008 20:39:25 +0100

> other otherName entity, but not both.

Yes, OpenSSL supports this.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 14 Aug 2008 20:39:49 +1200

>Yes, OpenSSL supports this.

I think you need to distinguish between "supports multiple GeneralNames 
containing different types of fields" (e.g. an email address, a DNS name, and 
an URI), and "supports multiple GeneralNames containing the same fields" (e.g. 
three email addresses).  In the past I've encountered all sorts of erratic 
behaviour with the latter when apps assume (probably quite rightly) that a 
cert will be associated with only a single email address or URI.  The most 
common failure mode seemed to be that only one instance of a particular 
GeneralName field would be recognised, e.g. if there were three email 
addresses then only the first one would be treated as present.  I can see the 
app developers' point here, if a cert contains three email addresses which one 
are you supposed to use?

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 14 Aug 2008 11:00:30 -0400

A certificate contains attributes of an entity; that the attributes
apply to the entity is the claim made by the CA when signing the
certificate.  I have multiple phone numbers and multiple email addresses
regardless of whether or not I have a certificate.  Which one to use is
an issue to be resolved by the caller/sender regardless of whether I
have a certificate.  The cert says only that if one has been chosen, on
whatever application-specific basis, then it should be legitimate.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Gutmann
Sent: Thursday, August 14, 2008 4:40 AM
To: [email-masked]; [email-masked]
Subject: Re: representation of multiple otherName entities

I think you need to distinguish between "supports multiple GeneralNames 
containing different types of fields" (e.g. an email address, a DNS
name, and 
an URI), and "supports multiple GeneralNames containing the same fields"
(e.g. 
three email addresses).  In the past I've encountered all sorts of
erratic 
behaviour with the latter when apps assume (probably quite rightly) that
a 
cert will be associated with only a single email address or URI.  The
most 
common failure mode seemed to be that only one instance of a particular 
GeneralName field would be recognised, e.g. if there were three email 
addresses then only the first one would be treated as present.  I can
see the 
app developers' point here, if a cert contains three email addresses
which one 
are you supposed to use?

Peter.

---

From: Tom Gindin <[email-masked]>
Date: Fri, 15 Aug 2008 07:49:34 -0400

I thought that the correct action in verifying that a presented 
TLS server certificate is for the expected server starts with the 
following two steps (assuming that the caller specified the connection by 
fully qualified DNS name):
1       assemble all DNSNames from the server certificate's subjectAltName 
extension
2       if the host name in the request URL matches any of those, permit 
connection
        Certainly RFC 2818 section 3.1 suggests that, although the 
parenthesis closes at the wrong point.

        Tom Gindin

"Kemp, David P." <[email-masked]> 
Sent by: [email-masked]
08/14/2008 11:00 AM

To
<[email-masked]>, <[email-masked]>
cc

Subject
RE: representation of multiple otherName entities

Dave

-----Original Message-----

Peter.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 15 Aug 2008 09:14:07 -0500

Peter Saint-Andre wrote:
> Tom Gindin wrote:
>>         I thought that the correct action in verifying that a 
>> presented TLS server certificate is for the expected server starts 
>> with the following two steps (assuming that the caller specified the 
>> connection by fully qualified DNS name):
>> 1       assemble all DNSNames from the server certificate's 
>> subjectAltName extension
>> 2       if the host name in the request URL matches any of those, 
>> permit connection
> IMHO the correct action depends on the using protocol. In XMPP (RFC 
> 3920) we do something similar to RFC 2818, but are working to make it 
> clearer in rfc3920bis, see here:
> 
> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html#security-certificates 

In the same vein, in SIP we have something similar as well.
The process is documented in
http://tools.ietf.org/html/draft-ietf-sip-domain-certs-01

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Aug 2008 08:04:05 -0600

/psa

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 18 Aug 2008 23:57:59 +1200

"Kemp, David P." <[email-masked]> writes:

>A certificate contains attributes of an entity; that the attributes apply to
>the entity is the claim made by the CA when signing the certificate.  I have
>multiple phone numbers and multiple email addresses regardless of whether or
>not I have a certificate.  Which one to use is an issue to be resolved by the
>caller/sender regardless of whether I have a certificate.

Right, but in this case the original poster was asking what sort of behaviour
you'd expect from typical software, as opposed to what you'd expect to read in
PKI marketing literature, and the behaviour of typical software in the
presence of (say) three URIs in one cert seems to be a coin-toss.  Flipping
coins for decisions is not a good way to build a security infrastructure.

So the logical extension to this, for the original poster's question, would be
to either suggest that people not put multiple fields of the same type (email
address, URI, etc) in a single cert if they need to rely on RPs processing
them in a predictable way, or to include wording in the security
considerations of the spec to say that if you put multiple URIs or whatnot in
a single cert then all bets are off.

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 18 Aug 2008 09:51:44 -0400

To address David's issue, an application could rely on external resources to
associate key to attributes, rather than what's communicated in the
certificate.  E.g., a browser can track which keys associate to which URLs,
an MUA can track which keys associate to which senders, and users are bugged
regarding trust decisions only at the establishment of these associations.  

But this is X.509 heresy and doesn't apply to the OP's question.  :)

-- Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Gutmann
Sent: Monday, August 18, 2008 6:58 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: RE: representation of multiple otherName entities

>caller/sender regardless of whether I have a certificate.

Right, but in this case the original poster was asking what sort of
behaviour
you'd expect from typical software, as opposed to what you'd expect to read
in
PKI marketing literature, and the behaviour of typical software in the
presence of (say) three URIs in one cert seems to be a coin-toss.  Flipping
coins for decisions is not a good way to build a security infrastructure.

So the logical extension to this, for the original poster's question, would
be
to either suggest that people not put multiple fields of the same type
(email
address, URI, etc) in a single cert if they need to rely on RPs processing
them in a predictable way, or to include wording in the security
considerations of the spec to say that if you put multiple URIs or whatnot
in
a single cert then all bets are off.

Peter.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Aug 2008 09:55:28 -0600

Peter Gutmann wrote:

> address, URI, etc) in a single cert...

Just to be clear, the original poster (c'est moi) was interested in 
learning how common software would handle a certificate issued with one 
instance each of different otherNames, in particular one instance of 
"id-on-xmppAddr" (RFC 3920) and one instance of "id-on-dnsSRV" (RFC 
4985) as described in rfc3920bis. Based on discussions I've had on and 
off the list, I think that such a certificate would not cause inordinate 
problems.

Peter