[cabfpub] .onion proposal

Ryan Sleevi sleevi at google.com
Mon Nov 17 23:30:50 MST 2014


On Nov 17, 2014 8:23 PM, "Jeremy Rowley" <jeremy.rowley at digicert.com> wrote:
>
> 1)      Okay with me if we include it in 11.1 (although the exception is
in 9.2.1) .  I’m not really tied to any particular format for the rule set.
>
> 2)      Yes – I think there is a disparity.  I sincerely hope that no CA
has issued an EV certificate with an internal name, but I think we created
the possibility when changing the EV Guidelines to reference the BR’s
domain validation section.  I haven’t looked at it too much though. If
others agree there is a gap, I’d support a motion to fix it.  The other
reason for including it in the EV Guidelines is that I don’t think the
certs need to be EV certs.  Sure, the identity should be validated but,
because of the prohibition on EV wildcards, I think onion service providers
should have the option of using either an EV or non-EV Cert.
>
> 3)     On EV – I think the fields should be communicated, but I don’t
think EV CPS should be mandatory for the reason above.
>
> 4)     On the key issue – that’s why I specify the requirement of two
CSRs (although in retrospect, I should have made this clearer – the CA
should not be issuing a cert with the key used to create the onion
service).  Will it satisfy your concern if I specify that the CSRs must not
contain the same public keys?  That’s certainly something the CA should
check.
>

I would have to look into how the .onion key is used. If it isn't
performing signing of PKCS#1 data, then you run the risk of using the same
key with multiple algorithms. I was less concerned about using the .onion
key as the TLS key (which strikes me as inherently risky, and would happy
to prohibit), but in requiring the .onion key to be used to sign a .CSR

Why would it not be sufficient to deliver the CSR via the .onion service,
since the .onion service by definition is a secure tunnel to the hidden
service/holder of the service private key?

For example, a well-known URI delivered via the hidden service seems like
it would offer binding, delivering the CSR (as POP of the TLS key) and a
challenge-response nonce (establishing authorization of the request)? I
just get nervous at the repurposing of key material, fundamentally.

>
>
>
>
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Monday, November 17, 2014 11:11 PM
>
> To: Jeremy Rowley
> Cc: CABFPub
> Subject: Re: [cabfpub] .onion proposal
>
>
>
>
>
>
>
> On Mon, Nov 17, 2014 at 9:48 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:
>
> I’m thinking it should be amendment to the BRs, not the EV Guidelines.
The BRs have the prohibition against internal names, not the EV
Guidelines.  We can move the language into Section 11; however, I thought
it’d be better to keep the language separate as an appendix, similar to how
we addressed issuance in Japan.
>
>
>
> 1) I definitely think this belongs in Section 11.1 - or at least with
respect to (ii), (iii), and (iv) - since that's specifically about
validating how names are presented in a certificate. This ensures that if a
name DOES exist that contains both a valid web address and a .onion name,
it's clear how those names apply (namely, how ALL DNS names - including
name constraints - apply)
>
>
>
> 2) This does highlight a disparity with the EVGs if the feeling is that
the EVGs can issue internal names. Or are you saying that you're seeing the
EVGs already incorporate by reference the BRs' sunset dates?
>
>
>>
>>
>>
>> Embarrassingly, I sent the wrong proposal for validation:
>>
>> a) .onion
>>
>> .onion is a pseudo-top level domain name that is used to designated
hidden services reachable within the Tor network.  When issuing a
Certificate that contains a .onion Domain Name, the CA MUST:
>
> Except it's not a pseudo-top level domain. It's a real and valid
top-level domain. It MAY be reserved by IANA action (as being pursued in
the IETF). It MAY be delegated by IANA (if IANA so chooses), though it may
be a high risk domain if they do.
>>
>> i) Verify the Applicant's legal existence and identity, business
presence, reliable method of communication, and operational existence in
accordance with the CA/Browser Forum's EV Guidelines,
>
> Will this be communicated via a set of mandatory fields in the cert? Will
it contain the EV CPS?
>
>
>>
>> ii) Obtain the hidden service descriptor for the requested .onion Domain
Name by connecting to the .onion service,
>>
>> iii) Obtain a CSR from the Applicant that is signed by the private key
obtained from the hidden service descriptor for the requested .onion Domain
Name,
>
> This is good in theory, but it potentially means using the .onion key for
multiple purposes, which would be bad.
>
>
>
> Let's also not forget that .onion names are NOT globally unique, not in
the way that DNS names are, at least with respect to a truncated SHA-1's
second preimage resistance
>
>
>>
>> iv) Obtain a CSR from the Applicant that contains the public key that
will be asserted by the issued Certificate, and
>>
>> v) Include the Applicant's verified Subject Identity Information in the
issued Certificate.
>>
>>
>>
>> Sorry about that.
>>
>>
>>
>> From: Ryan Sleevi [mailto:sleevi at google.com]
>> Sent: Monday, November 17, 2014 4:26 PM
>> To: Jeremy Rowley
>> Cc: CABFPub
>> Subject: Re: [cabfpub] .onion proposal
>>
>>
>>
>>
>>
>> On Nov 17, 2014 1:16 PM, "Jeremy.Rowley" <jeremy.rowley at digicert.com>
wrote:
>> >
>> > Thanks to everyone who has commented so far.  Based on the feedback,
I'm
>> > amending the proposal as follows:
>> >
>> > 1) Modify the definition of internal name to exclude reserved names
>> > approved by the Forum (which will only be onion as far as I know).
>> > Here's the language:
>> > Internal Name: A string of characters (not an IP address) in a Common
>> > Name or Subject Alternative Name field of a Certificate that cannot be
>> > verified as globally unique within the public DNS at the time of
>> > certificate issuance because it does not end with either (a) a reserved
>> > name approved by the CAB Forum under Appendix D or (b) a Top Level
>> > Domain registered in IANA’s Root Zone Database.
>> >
>> > 2) Add Appendix D that contains the following requirements:
>> > Although CAs are prohibited from issuing Internal Names as of 1
November
>> > 2015,  the following TLDs are outside the scope of this prohibition
>> > because of their delegation outside of IANA and use in certain
>> > communities supported by CA/Browser Forum members. In each case, the
>> > CA/Browser Forum has established set procedures for verifying the
>> > information contained in the Certificate. If there is any conflict
>> > between the procedures set forth in this appendix and the other
controls
>> > established by the CA/Browser Forum, the procedures set forth in this
>> > appendix control.
>> >
>> > a) .onion
>> > .onion is a pseudo-top level domain name that is used to designated
>> > hidden services reachable within the Tor network. Prior to issuing a
>> > Certificate that contains a .onion Domain Name, the CA MUST:
>> > i) Verify that the Applicant controls the service provided at the
>> > requested .onion Domain Name by specifying a change to the service and
>> > verifying the Applicant made the change using the onion routing
network.
>>
>> I think this would be better expressed in the 9.2.1 / 11.1
>>
>> 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.
>>
>> > ii) Verify the Applicant's legal existence and identity, business
>> > presence, reliable method of communication, and operational existence
in
>> > accordance with the CA/Browser Forum's EV Guidelines.
>> >
>>
>> This would be an amendment to the EVGs, not the BRs, right? Again,
specific sections would help here.
>>
>> > Thoughts?
>> >
>> > Jeremy
>> >
>> > On 11/12/2014 6:34 PM, Brian Smith wrote:
>> > > On Wed, Nov 12, 2014 at 12:51 PM, Jeremy Rowley
>> > > <jeremy.rowley at digicert.com> wrote:
>> > >> I’d like to continue the .onion discussion that I started here
about a month
>> > >> ago.  Primarily, I’d like to see how we can create a very limited
exception
>> > >> to the general prohibition on internal name certificates that will
take
>> > >> effect in 2015 for the purpose of permitting the CA community to
show
>> > >> support for both Tor and entities operating .onion names.
>> > > I suggest that you redefine "internal name" so that .onion isn't
>> > > considered an internal name. I don't see much resistance to that.
>> > >
>> > >> 2)      The CA MUST verify a non-onion domain name owned by the
applicant
>> > >> and assert that domain name in the same certificate as the .onion
address
>> > > I don't think that this should be required. It could have very
>> > > negative consequences. In particular, whether this is even safe or
not
>> > > depends on some unspecified/undocumented subtleties of how browsers
>> > > coalesce connections. Also, it seems unnecessary. We don't require
>> > > such a thing for the issuance of normal certificates, and I don't
>> > > think Tor is special here. In fact, for now, I would argue that the
>> > > certificate should only contain a single dNSName SAN entry, which
>> > > would be the single .onion address.
>> > >> 2)      Tor uses its own encryption so the certificates are about
>> > >> identification
>> > > It is true that Tor uses its own encryption, but HTTPS over Tor is
>> > > going to use HTTPS encryption too, right? And, there are significant
>> > > benefits to the HTTPS-level encryption.
>> > >
>> > >> 3)      .onion addresses are generated from the service provider’s
key,
>> > >> meaning they are unique (you don’t choose the onion address)
>> > > As Facebook showed, you can control a significant part of the onion
>> > > address. However, it is too expensive and complicated to do so for
>> > > most people, so it would be unreasonable to force somebody requesting
>> > > a certificate to do what Facebook did. However, CAs should be aware
of
>> > > the possibility of somebody generating addresses which are misleading
>> > > (e.g. contain trademarks of other companies) or addresses that are
>> > > confusingly similar to other addresses.
>> > >
>> > > I agree with your other points.
>> > >
>> > > Cheers,
>> > > Brian
>> > > .
>> > >
>> >
>> > _______________________________________________
>> > Public mailing list
>> > Public at cabforum.org
>> > https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141117/ef7fde2b/attachment.html 


More information about the Public mailing list