[cabfpub] .onion and .exit

Jeremy Rowley jeremy.rowley at digicert.com
Fri Oct 17 14:20:55 UTC 2014

Adding Peter Bowen's comment to the discussion:

What about using the uniformResourceIdentifier option for subjectAlternativeName?

The Baseline Requirements say "Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server", which would appear to rule this out, but I'm not sure if that was the intention.  Do the BRs really mean to disallow putting rfc822Name, directoryName, or other types of names in the SAN?


-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Friday, October 17, 2014 3:18 AM
To: Jeremy Rowley; Adam Langley
Cc: Phillip Hallam-Baker; CABFPub
Subject: Re: [cabfpub] .onion and .exit

On 16/10/14 18:01, Jeremy Rowley wrote:
> I asked a couple of companies who have requested these types of certs 
> about this and here is one reason for wanting a cert:

It looks like the real issue here is proving real-world ownership and control of .onion addresses, either by tying them to an existing real-world website (DV with multiple SANs) or an identity (EV).

In the EV case, the UI would show the tied identity, but not in the DV case. Although the Tor Browser Bundle could be updated to do something smart - if there's a .onion address, instead show the DNS name from the first non-onion SAN, or something.

(You may remember a while back I suggested that internal server name certs should have at least one globally-resolvable name in, and that browsers should display that instead, even if the internal name was used. This is a similar idea.)


More information about the Public mailing list