[cabfpub] .onion proposal

[Ryan Sleevi]

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>
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]
> Sent: Tuesday, December 2, 2014 7:54 PM
> To: Jeremy Rowley
> Cc: 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>
> 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
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141209/2ec3e49e/attachment-0003.html>