[cabfpub] .onion proposal

Tue Dec 9 16:18:18 MST 2014

Thanks Ryan!  I’ll get it updated.  I appreciate the endorsement.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Tuesday, December 9, 2014 4:16 PM
To: Jeremy Rowley
Cc: Tom Ritter; public at cabforum.org
Subject: Re: [cabfpub] .onion proposal

Hi Jeremy,

I believe you mean for (b) that it was "signing a Certificate Request using the .onion private key"

I think the wording for b. could be improved by being a bit more explicit on those OID values and how they're encoded in the CSR, but I consider that more editorial work than anything. That is, something like (and here I'm being lazy and not fully fleshing out the proposal, just the structure)

b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Signing Request signed the the .onion private key if the Attributes section of the certificationRequestInfo contains:
 i) A [someNameHere] attribute which contains a single value that contains at least 64-bits of entropy, generated by the CA and delivered to the Applicant out-of-band
 ii) A [someOtherNameHere] attribute which contains a single value that contains at least 64-bits of entropy, generated by the Applicant

cabf-someIdHere ID ::= { someIdHere }
cabf-someOtherIdHere ID ::= { someOtherIdHere }

someNameHere ATTRIBUTE ::= {
  WITH SYNTAX OCTET STRING,
  ID cabf-someIdHere
}
someOtherNameHere ATTRIBUTE ::= {
  WITH SYNTAX OCTET STRING,
  ID cabf-someOtherIdHere
}

The reason I suggest rewording is to address a couple ambiguities in the current proposal:
1) It's not clear that { 2.23.140.1.41 } is the OID (or at least not called out as such)
2) You don't mention until the end that it appears in the Attributes section. Since you're enumerating multiple attributes, it helps to place that statement first, then enumerate each of the attributes that must be present
3) Note that ASN.1 is awful for the uninitiated (and I consider myself among them). Above is possibly a misreading of the X.501 module and the X.683 syntax, but I've made a good stab at it. I suspect Tom has some contacts who can check my awful ASN.1 1998, if not some of the members here.

A point with 3 is that the current language may leave some ambiguity. An RFC 2986 Attribute is a type identified by an OID, whose value is a SET of 1...MAX of the internal type. The SET type for each of the OIDs MUST only include a single value, but I'm not sure how to express that. The ASN.1 definitions in RFC 2986 ignore the single-valued attribute of the ATTRIBUTE type from X.501, so I've just left it to prose.

For example, it'd be non-conforming to have this proposal be interpreted as encouraging violating RFC 2986, where instead of a SEQUENCE { OBJECT IDENTIFIER id, SET OF Types }, it's instead a SEQUENCE { OBJECT IDENTIFIER id, OCTET STRING }.

(Yes, this means that the RFC 2986 syntax is more limiting than the RFC 5280 syntax. Oh well).

Feel free to smith at will, but those were the concerns.

I think we'd be happy to endorse with a few fixes to the above issues, however you see fit.

On Mon, Dec 8, 2014 at 9:33 AM, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
Thanks Tom!  Does anyone else have comments? If not, do I have someone willing to endorse?

-----Original Message-----
From: Tom Ritter [mailto:tom at ritter.vg<mailto:tom at ritter.vg>]
Sent: Tuesday, December 2, 2014 7:54 PM
To: Jeremy Rowley
Cc: public at cabforum.org<mailto:public at cabforum.org>
Subject: Re: [cabfpub] .onion proposal
Thanks Jeremy! I'm working with Tor to try and advance this effort on a few different technical and policy fronts, and I think this is a good path forward.

On 1 December 2014 at 18:18, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
> b.      The CA MAY verify the Applicant's control over the .onion service by
> signing a Certificate Request using the .onion public key if (i) the
> signature contains a random value chosen by the CA that prevents a
> fraudulent applicant from obtaining the signed statement within the
> signature { 2.23.140.1.41 }  and (ii) the signature contains a random
> value chosen by the Applicant that prevents the CA from choosing the
> entire contents of the signed statement { 2.23.140.1.42 }.  Each
> nonce/counter-nonce MUST have at least 64-bits of entropy and MUST be
> presented as an OCTET STRING in the appropriate extension (specified
> above) in the Attributes section of the certificationRequestInfo.

I've started a thread on tor-dev that discusses ways to safely do
this: https://lists.torproject.org/pipermail/tor-dev/2014-November/007853.html
(and https://lists.torproject.org/pipermail/tor-dev/2014-December/007901.html
).  I need to update the specification I sent in the first email with Nick and Ian's thoughts in the second link - but the effort to define a safe way to do this (because of the key reusage Ryan brought up) is underway.

-tom
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141209/4e61108b/attachment-0001.html 