<p dir="ltr"><br>
On Nov 17, 2014 1:16 PM, "Jeremy.Rowley" <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
><br>
> Thanks to everyone who has commented so far. Based on the feedback, I'm<br>
> amending the proposal as follows:<br>
><br>
> 1) Modify the definition of internal name to exclude reserved names<br>
> approved by the Forum (which will only be onion as far as I know).<br>
> Here's the language:<br>
> Internal Name: A string of characters (not an IP address) in a Common<br>
> Name or Subject Alternative Name field of a Certificate that cannot be<br>
> verified as globally unique within the public DNS at the time of<br>
> certificate issuance because it does not end with either (a) a reserved<br>
> name approved by the CAB Forum under Appendix D or (b) a Top Level<br>
> Domain registered in IANA’s Root Zone Database.<br>
><br>
> 2) Add Appendix D that contains the following requirements:<br>
> Although CAs are prohibited from issuing Internal Names as of 1 November<br>
> 2015, the following TLDs are outside the scope of this prohibition<br>
> because of their delegation outside of IANA and use in certain<br>
> communities supported by CA/Browser Forum members. In each case, the<br>
> CA/Browser Forum has established set procedures for verifying the<br>
> information contained in the Certificate. If there is any conflict<br>
> between the procedures set forth in this appendix and the other controls<br>
> established by the CA/Browser Forum, the procedures set forth in this<br>
> appendix control.<br>
><br>
> a) .onion<br>
> .onion is a pseudo-top level domain name that is used to designated<br>
> hidden services reachable within the Tor network. Prior to issuing a<br>
> Certificate that contains a .onion Domain Name, the CA MUST:<br>
> i) Verify that the Applicant controls the service provided at the<br>
> requested .onion Domain Name by specifying a change to the service and<br>
> verifying the Applicant made the change using the onion routing network.</p>
<p dir="ltr">I think this would be better expressed in the 9.2.1 / 11.1</p>
<p dir="ltr">The current language feels way too broad, which is already an issue with the existing language. We should ensure that new language provides narrow scoping and guidelines.<br></p>
<p dir="ltr">> ii) Verify the Applicant's legal existence and identity, business<br>
> presence, reliable method of communication, and operational existence in<br>
> accordance with the CA/Browser Forum's EV Guidelines.<br>
></p>
<p dir="ltr">This would be an amendment to the EVGs, not the BRs, right? Again, specific sections would help here.</p>
<p dir="ltr">> Thoughts?<br>
><br>
> Jeremy<br>
><br>
> On 11/12/2014 6:34 PM, Brian Smith wrote:<br>
> > On Wed, Nov 12, 2014 at 12:51 PM, Jeremy Rowley<br>
> > <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
> >> I’d like to continue the .onion discussion that I started here about a month<br>
> >> ago. Primarily, I’d like to see how we can create a very limited exception<br>
> >> to the general prohibition on internal name certificates that will take<br>
> >> effect in 2015 for the purpose of permitting the CA community to show<br>
> >> support for both Tor and entities operating .onion names.<br>
> > I suggest that you redefine "internal name" so that .onion isn't<br>
> > considered an internal name. I don't see much resistance to that.<br>
> ><br>
> >> 2) The CA MUST verify a non-onion domain name owned by the applicant<br>
> >> and assert that domain name in the same certificate as the .onion address<br>
> > I don't think that this should be required. It could have very<br>
> > negative consequences. In particular, whether this is even safe or not<br>
> > depends on some unspecified/undocumented subtleties of how browsers<br>
> > coalesce connections. Also, it seems unnecessary. We don't require<br>
> > such a thing for the issuance of normal certificates, and I don't<br>
> > think Tor is special here. In fact, for now, I would argue that the<br>
> > certificate should only contain a single dNSName SAN entry, which<br>
> > would be the single .onion address.<br>
> >> 2) Tor uses its own encryption so the certificates are about<br>
> >> identification<br>
> > It is true that Tor uses its own encryption, but HTTPS over Tor is<br>
> > going to use HTTPS encryption too, right? And, there are significant<br>
> > benefits to the HTTPS-level encryption.<br>
> ><br>
> >> 3) .onion addresses are generated from the service provider’s key,<br>
> >> meaning they are unique (you don’t choose the onion address)<br>
> > As Facebook showed, you can control a significant part of the onion<br>
> > address. However, it is too expensive and complicated to do so for<br>
> > most people, so it would be unreasonable to force somebody requesting<br>
> > a certificate to do what Facebook did. However, CAs should be aware of<br>
> > the possibility of somebody generating addresses which are misleading<br>
> > (e.g. contain trademarks of other companies) or addresses that are<br>
> > confusingly similar to other addresses.<br>
> ><br>
> > I agree with your other points.<br>
> ><br>
> > Cheers,<br>
> > Brian<br>
> > .<br>
> ><br>
><br>
> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
</p>