On Tue Dec 02 2014 at 7:15:54 PM Peter B= owen <pzbowen@gmail.com> wro= te:

On Tue, Dec 2, 2014 at 10:05 AM, Paul= Hoffman <pau= l.hoffman@vpnc.org> wrote:
> Greetings again. A few people have asked for HTTP-based verification f= or the certificate request, but I'm not sure that is needed. Are there = environments where someone who will be able to stand up a server with a CA-= issued cert on HTTPS-over-443 could not stand up such a service with a temp= orary self-issued cert? If not, what is the value of checking if the person= can control the content on port 80?

The primary case where I see a problem is when the site already has a
trusted certificate and wants to use ACME to get a new certificate.
They are unlikely to want to replace their working certificate with a
self-signed certificate.=C2=A0

Why would yo= u need to replace it? You use SNI on some new domain...

=C2=A0

So the proof would need to happen at the=
HTTP layer, not the TLS layer.

Thanks,
Peter

_______________________________________________
Acme mailing list
Acme@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/acme

--001a11c2cc9e7520ac050951f5df-- From nobody Wed Dec 3 08:20:33 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43F91A6EE7 for ; Wed, 3 Dec 2014 08:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYItbOxMYmse for ; Wed, 3 Dec 2014 08:20:27 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC051A6F44 for ; Wed, 3 Dec 2014 08:20:21 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so1301277obc.11 for ; Wed, 03 Dec 2014 08:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OLgbzhNcS8OKGp1P2QQfmObiwkCELPHsQ2AilLPi+o0=; b=oIjciM2J1oMDmPJOPu4i8UoVn+ngE5s3p2WDtlZJWVDuiSLP8ExIHeUibTOr9K02q2 B+tFYD9Q0s5z7lAbkcTb2G7hswCz4IYWbdgFxEZIxVkQ1CT1AE4piNo5vUTxq2FbFBLw ZURXnJNZNpqI6guL256UMACiU1RUZ8a8XtUiUKJ78WPJTRaGi/vKiKiQ2ILunY76hCjo WnBfrpsyC5qoUh3GH/wSx9xBNtHXakR0QoCFEeaNxYVPtG19Ax7DzJM9BpIelR1CHzgo jHW7Vd0Lu7a8umZKanz3nchFOxxHdhpadyA+x2jw73K3mGftQjdcJOR6rngsKdya3MBe /g0w== MIME-Version: 1.0 X-Received: by 10.202.111.3 with SMTP id m3mr3505551oic.16.1417623621188; Wed, 03 Dec 2014 08:20:21 -0800 (PST) Received: by 10.202.115.4 with HTTP; Wed, 3 Dec 2014 08:20:21 -0800 (PST) In-Reply-To: References:

Date: Wed, 3 Dec 2014 08:20:21 -0800 Message-ID: From: Martin Thomson To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/DQk3tjoqKFkvL4u55Z-LAf6JiLQ Cc: "acme@ietf.org" , Peter Bowen , Paul Hoffman Subject: Re: [Acme] Why "HTTP verification" X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 16:20:30 -0000 On 3 December 2014 at 08:01, Ben Laurie wrote: > Why would you need to replace it? You use SNI on some new domain... That is currently only specified for the dvsni validation method. And it creates an additional burden on the implementation AND it makes it much, much harder to deploy something like this. If you have a front-end that routes on SNI, then it would need to be modified. The advantage of simpleHttps is that it doesn't depend on control of the demux point. From nobody Wed Dec 3 08:30:17 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530811A1B4B for ; Wed, 3 Dec 2014 08:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFDyectGnFv0 for ; Wed, 3 Dec 2014 08:30:09 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CF21A1B3F for ; Wed, 3 Dec 2014 08:30:09 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id rd3so16020836pab.35 for ; Wed, 03 Dec 2014 08:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/Wq+QXlTLRTbd1l56o6Fd6C43oQgWIRxsM9ChyExs2c=; b=zE+HUSEzW2y7b5a+UgIQbOdaJpDkv2yb/X+Dl3q/OVyVkZyH1g9YXP2cPrgWjbLhP+ sBw1X5F2UsBsp6/b/sCRB9yaieL4HNtpNbVq++Kf7oppbSXiwDcUgWZ2UdE3KJKpoaYF WGkMC1ue7mvq1VQgPWHyXvsxfx4lwa9u/tD1kX2HaFg0LgAe3GhWiziGUjrDJYXGUbcj XSUD0AkWeqG3azI0EeAh8PJIY0BfCKatHxpt/s7Ca9xrlhZ56/0j+q8ytEeewyFcNkt5 SiWGTTOA+02J+ZrhAgk1agNG9YHae6R6NFzOx85R1WxIVSW+FOc1j4uNPjLnuyckwl3C me2Q== MIME-Version: 1.0 X-Received: by 10.70.90.11 with SMTP id bs11mr10682292pdb.16.1417624208220; Wed, 03 Dec 2014 08:30:08 -0800 (PST) Received: by 10.70.76.10 with HTTP; Wed, 3 Dec 2014 08:30:08 -0800 (PST) In-Reply-To: References:

Date: Wed, 3 Dec 2014 08:30:08 -0800 Message-ID: From: Peter Bowen To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/VPmq2Sl5uing-ububXNuyzHrXI4 Cc: acme@ietf.org, Paul Hoffman Subject: Re: [Acme] Why "HTTP verification" X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 16:30:13 -0000 On Wed, Dec 3, 2014 at 8:01 AM, Ben Laurie wrote: > On Tue Dec 02 2014 at 7:15:54 PM Peter Bowen wrote: >> On Tue, Dec 2, 2014 at 10:05 AM, Paul Hoffman wrote: >> > Greetings again. A few people have asked for HTTP-based verification for >> > the certificate request, but I'm not sure that is needed. Are there >> > environments where someone who will be able to stand up a server with a >> > CA-issued cert on HTTPS-over-443 could not stand up such a service with a >> > temporary self-issued cert? If not, what is the value of checking if the >> > person can control the content on port 80? >> >> The primary case where I see a problem is when the site already has a >> trusted certificate and wants to use ACME to get a new certificate. >> They are unlikely to want to replace their working certificate with a >> self-signed certificate. > > Why would you need to replace it? You use SNI on some new domain... Assuming I want to get a new certificate for secure.example.org, which is current using a certificate from Connotation, a trusted CA. How would using SNI on another FQDN help validate control of secure.example.org? The ACME proposal suggests that "DV + Proof of Possession of previous CA-signed key" is the appropriate mechanism for "Existing valid certs, first use of ACME." However I don't see a clear definition of DV outside of DVSNI. Thanks, Peter From nobody Wed Dec 3 12:32:25 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6A41A6F3A for ; Wed, 3 Dec 2014 12:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqxkv6R3N72P for ; Wed, 3 Dec 2014 12:32:15 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673AC1A1B4A for ; Wed, 3 Dec 2014 12:31:52 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so8482436lab.14 for ; Wed, 03 Dec 2014 12:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=3X0KFftyEFYdHgwaDTTP0guDkptqVqBzPBVkKVvy/Zs=; b=UjUIt93CTTbL3M/8eRpevo3/6vBayyaDOdkodxTVCSwxq791zEeknN9S++qY2iC0DP NBU3Vm9VkTWT7GcgteJTp7JXglTr7/+2Vy5DKXd+HdO1kih7gQR0rnPYkvRFFZHJD761 xHMQqX6Yt6wDWXRRjWil67wM40PXTKN/WmfuRtXyN/UuvSPb829QBBNUjEMkKju/T0oI 3aXeJxlQSu8Sr7BEQVDZm0bDREIpem+JvmjOvTGpS89SO1LWVqHSr9Etfy0FB/MUBTzb 1OBHPefDl1LhmBTnZSLI/UGpYLjvBQGIyELpMxllq5/yB8g08Ra/jwjqTEMytNEexekr LS3Q== MIME-Version: 1.0 X-Received: by 10.112.27.133 with SMTP id t5mr5968091lbg.45.1417638710841; Wed, 03 Dec 2014 12:31:50 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Wed, 3 Dec 2014 12:31:50 -0800 (PST) Date: Wed, 3 Dec 2014 15:31:50 -0500 X-Google-Sender-Auth: mnhz59jnKK8jo2YHIrWZL8TqB-4 Message-ID: From: Phillip Hallam-Baker To: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a1133b04ac79666050955bbdd Archived-At: http://mailarchive.ietf.org/arch/msg/acme/O89RZ8a3_FBchxrf3dZXiclNBfc Subject: [Acme] (Re)Design sketch X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 20:32:18 -0000 --001a1133b04ac79666050955bbdd Content-Type: text/plain; charset=UTF-8 Comodo has an existing API for certificate issue. It is functional and works but it isn't ideal because: 1) It isn't JSON and we have customers that demand JSON. 2) It is proprietary which means we have to support plug ins for a large number of servers which is costly and reduces the utility to larger installations. 3) It is rather crusty as features have been added gradually over the years by a variety of authors in a variety of styles. If we follow the path of only addressing the problems considered important by one CA that has yet to issue a cert then the result is only going to address the first two problems. We will end up with another PKIX situation where the stack is ridiculously complicated BECAUSE of the attempts to 'keep it simple'. Lowballing requirements results in redundancy and unnecessary complexity. A better way to address the problem is to architect the system recognizing that in some circumstances functions will be split across different actors at subscriber site at the start rather than trying to retrofit this capability as an afterthought. It isn't just enterprise firewalls that present corner cases. Managing credentials on a Web service in the cloud presents similar issues. *Architectural Constraints:* * Use the existing CSR format for proof of possession of the private key for X.509v3 issue. * Use JSON encoding for all new structures and protocol messages. * Assume HTTP binding, do not rely on HTTPS for security properties. * Use SRV and CAA records in DNS to enable automation. *Actors:* Subject: The party whose identity is validated Issuer: The party that issues the certificate Host: The machine on which the private key and certificate are installed Recognizing that the Host is not the same as the Subject is important as without that distinction it becomes impossible to talk about failures or attacks in a meaningful way. Note that as far as the protocol interactions are concerned, the Issuer need not be a CA. A CA is a party that is subject to audit and insurance and has actual custody of the signing key. It is not actually necessary for the Subject to have a direct interaction with their CA. In the ideal situation any party with more than a dozen certs is going to channel cert requests through a local issuer which forwards them to a CA (possibly through another intermediary). *Processes:* Validation: Determining that a purported subject meets a set of criteria specified by a certificate policy and in particular has the right to use a specified identity. Key Generation: Generating a public/private key pair Certificate Issue: Signing a Certificate While each process must occur at least once for a certificate to be issued, these are three separate processes. In particular, Validation is an interaction with the certificate subject, Certificate Issue is to the Host holding the corresponding private key. In any deployment that has more than one host it is going to be desirable to amortize a validation process across the multiple hosts. Today Key Generation and Validation might occur once every three years and Certificate Issue once a year. One of the reasons I am interested in automating Cert Management is to change these parameters. My ideal situation would be to perform Key Generation and Certificate Issue every 24 hours with overlapping 72 hour validity intervals of which 24 hours is backdated. I certainly don't want to have to perform OV or EV validation every 24 hours. I am not averse to performing the DV component of validation every 24 hours as well but the most appropriate response to single validation failure after a long stream of successful validations is probably to notify the system admin rather than force their site offline. A somewhat more complicated question is how to deal with the problem of multiple ports, multiple protocols and multiple applications on the same host. We should not limit the use of HTTP validation to certificates that will be used with HTTP. While the requirements appear complicated, it is actually fairly straightforward to support them all if we recognize the distinction between the Subject and the Host. Since there is a relationship between the subject and the issuer that potentially persists across multiple certificate issue transactions, this implies some form of account/credential. Since we are doing PKI we can insist that the credential used to authenticate transactions be a public key. For a free cert provider with a zero touch model, the account identifier might well be simply the public key or a fingerprint thereof. If the account identifier is never seen by a user, it does not need to be particularly human readable. Thoughts? Comments? --001a1133b04ac79666050955bbdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Comodo has an existing API for certificate issue. It is fu= nctional and works but it isn't ideal because:

1) It= isn't JSON and we have customers that demand JSON.

2) It is proprietary which means we have to support plug ins for a la= rge number of servers which is costly and reduces the utility to larger ins= tallations.

3) It is rather crusty as features hav= e been added gradually over the years by a variety of authors in a variety = of styles.

If we follow the path of only addressin= g the problems considered important by one CA that has yet to issue a cert = then the result is only going to address the first two problems. We will en= d up with another PKIX situation where the stack is ridiculously complicate= d BECAUSE of the attempts to 'keep it simple'.

Lowballing requirements results in redundancy and unnecessary complexi= ty.

A better way to address the pro= blem is to architect the system recognizing that in some circumstances func= tions will be split across different actors at subscriber site at the start= rather than trying to retrofit this capability as an afterthought.

It isn't just enterprise firewalls that present corne= r cases. Managing credentials on a Web service in the cloud presents simila= r issues.

Architectural Constrai= nts:

* Use the existing CSR format for proof o= f possession of the private key for X.509v3 issue.

* Use JSON enc= oding for all new structures and protocol messages.

* Assume HTTP= binding, do not rely on HTTPS for security properties.

* Use SRV= and CAA records in DNS to enable automation.

Actors:

Subject: The party whose= identity is validated

Issuer: The party that issues the certific= ate

Host: The machine on which the private key and certificate ar= e installed

Recognizing that the Host is not the s= ame as the Subject is important as without that distinction it becomes impo= ssible to talk about failures or attacks in a meaningful way.

Note that as far as the protocol interactions are concerned, th= e Issuer need not be a CA. A CA is a party that is subject to audit and ins= urance and has actual custody of the signing key. It is not actually necess= ary for the Subject to have a direct interaction with their CA.

<= br>

In the ideal situation any party with more than a dozen certs= is going to channel cert requests through a local issuer which forwards th= em to a CA (possibly through another intermediary).

Processes:

Validation: Det= ermining that a purported subject meets a set of criteria specified by a ce= rtificate policy and in particular has the right to use a specified identit= y.

Key Generation: Generating a public/private key= pair

Certificate Issue: Signing a Certificate

While each process must occur at least= once for a certificate to be issued, these are three separate processes.= =C2=A0

In particular, Validation is an interaction= with the certificate subject, Certificate Issue is to the Host holding the= corresponding private key. In any deployment that has more than one host i= t is going to be desirable to amortize a validation process across the mult= iple hosts.

Today Key Generation an= d Validation might occur once every three years and Certificate Issue once = a year. One of the reasons I am interested in automating Cert Management is= to change these parameters.

My ideal situation wo= uld be to perform Key Generation and Certificate Issue every 24 hours with = overlapping 72 hour validity intervals of which 24 hours is backdated. I ce= rtainly don't want to have to perform OV or EV validation every 24 hour= s.

I am not averse to performing the DV component = of validation every 24 hours as well but the most appropriate response to s= ingle validation failure after a long stream of successful validations is p= robably to notify the system admin rather than force their site offline.

A somewhat more complicated question = is how to deal with the problem of multiple ports, multiple protocols and m= ultiple applications on the same host.

We should n= ot limit the use of HTTP validation to certificates that will be used with = HTTP.

While the requirements appear= complicated, it is actually fairly straightforward to support them all if = we recognize the distinction between the Subject and the Host. Since there = is a relationship between the subject and the issuer that potentially persi= sts across multiple certificate issue transactions, this implies some form = of account/credential. Since we are doing PKI we can insist that the creden= tial used to authenticate transactions be a public key.

For a free cert provider with a zero touch model, the account identif= ier might well be simply the public key or a fingerprint thereof. If the ac= count identifier is never seen by a user, it does not need to be particular= ly human readable.

Thoughts? Commen= ts?

--001a1133b04ac79666050955bbdd-- From nobody Wed Dec 3 19:45:07 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9E91A0010 for ; Wed, 3 Dec 2014 19:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyrBEDDVN_s1 for ; Wed, 3 Dec 2014 19:40:56 -0800 (PST) Received: from mr11p24im-asmtp001.me.com (mr11p24im-asmtp001.me.com [17.110.78.41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856141A0013 for ; Wed, 3 Dec 2014 19:40:56 -0800 (PST) Received: from Den (c-67-183-152-156.hsd1.wa.comcast.net [67.183.152.156]) by mr11p24im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NG100JQKGW5OY50@mr11p24im-asmtp001.me.com> for acme@ietf.org; Thu, 04 Dec 2014 03:40:55 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-04_02:2014-12-03,2014-12-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1412040036 From: Trevor Freeman To: 'Phillip Hallam-Baker' , acme@ietf.org References: In-reply-to: Date: Wed, 03 Dec 2014 19:40:47 -0800 Message-id: <002d01d00f74$1823d990$486b8cb0$@icloud.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_002E_01D00F31.0A07C580" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQLN9r/Q5ArEYkdTvz45Letl4obCxJqC7odA Content-language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/acme/f9RkFnB53kdSNB79c_DzAIzPWqY Subject: Re: [Acme] (Re)Design sketch X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 03:41:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002E_01D00F31.0A07C580 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See inline =20 From: Acme [mailto:acme-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker Sent: Wednesday, December 03, 2014 12:32 PM To: acme@ietf.org Subject: [Acme] (Re)Design sketch =20 Comodo has an existing API for certificate issue. It is functional and = works but it isn't ideal because: =20 1) It isn't JSON and we have customers that demand JSON. =20 2) It is proprietary which means we have to support plug ins for a large = number of servers which is costly and reduces the utility to larger = installations. =20 3) It is rather crusty as features have been added gradually over the = years by a variety of authors in a variety of styles. =20 If we follow the path of only addressing the problems considered = important by one CA that has yet to issue a cert then the result is only = going to address the first two problems. We will end up with another = PKIX situation where the stack is ridiculously complicated BECAUSE of = the attempts to 'keep it simple'. =20 Lowballing requirements results in redundancy and unnecessary = complexity. =20 =20 A better way to address the problem is to architect the system = recognizing that in some circumstances functions will be split across = different actors at subscriber site at the start rather than trying to = retrofit this capability as an afterthought. =20 It isn't just enterprise firewalls that present corner cases. Managing = credentials on a Web service in the cloud presents similar issues. =20 =20 Architectural Constraints: =20 * Use the existing CSR format for proof of possession of the private key = for X.509v3 issue. [TF] Seems reasonable. There is a lot of code on many platforms to do = this.=20 * Use JSON encoding for all new structures and protocol messages. [TF] Seems reasonable if we are defining something new.=20 * Assume HTTP binding, do not rely on HTTPS for security properties. [TF] Why would we need HTTP?=20 * Use SRV and CAA records in DNS to enable automation. [TF] These seem niece to have ret than must haves. You can provide = better load bailing and floe via NLB rather than SRV records.=20 =20 Actors: =20 Subject: The party whose identity is validated Issuer: The party that issues the certificate Host: The machine on which the private key and certificate are installed [TF] There is also the DVRA =20 Recognizing that the Host is not the same as the Subject is important as = without that distinction it becomes impossible to talk about failures or = attacks in a meaningful way. =20 Note that as far as the protocol interactions are concerned, the Issuer = need not be a CA. A CA is a party that is subject to audit and insurance = and has actual custody of the signing key. It is not actually necessary = for the Subject to have a direct interaction with their CA. [TF] You will have to elaborate on the Asser <> CA part because I have = always takes the issuer to be by definition a CA. The ACME server is a = front end to a CA. =20 In the ideal situation any party with more than a dozen certs is going = to channel cert requests through a local issuer which forwards them to a = CA (possibly through another intermediary). [TF] Do you mean ACME server chaining where one ACME server sends = request to another ACE server? =20 Processes: =20 Validation: Determining that a purported subject meets a set of criteria = specified by a certificate policy and in particular has the right to use = a specified identity. [TF] Determining that a request meets a set criteria as determined by a = certificate policy. The policy will establish a LoA for the binding to = the subject name. =20 Key Generation: Generating a public/private key pair =20 Certificate Issue: Signing a Certificate =20 =20 While each process must occur at least once for a certificate to be = issued, these are three separate processes.=20 =20 In particular, Validation is an interaction with the certificate = subject, Certificate Issue is to the Host holding the corresponding = private key. In any deployment that has more than one host it is going = to be desirable to amortize a validation process across the multiple = hosts. [TF] Validation does not require interaction with the entity making the = request. An administrator may have proven control of the domain thereby = authorizing the issuance of certificates in the domain namespace and the = subject making the request it technically their delegate.=20 =20 Today Key Generation and Validation might occur once every three years = and Certificate Issue once a year. One of the reasons I am interested in = automating Cert Management is to change these parameters. =20 My ideal situation would be to perform Key Generation and Certificate = Issue every 24 hours with overlapping 72 hour validity intervals of = which 24 hours is backdated. I certainly don't want to have to perform = OV or EV validation every 24 hours. [TF] Ironic in that this is the model proposed by Barb Fox many moons = ago=E2=80=A6 I get the frequent cert issuance but frequent key = generation seems a bit ott given the move to pfs. Reissuing a = certificate with the same key is a safer process. =20 I am not averse to performing the DV component of validation every 24 = hours as well but the most appropriate response to single validation = failure after a long stream of successful validations is probably to = notify the system admin rather than force their site offline. [TF] We need to look at the threat model for the actual proofs. You = could generate false negative due to operational procedures on the part = of the domain.=20 =20 A somewhat more complicated question is how to deal with the problem of = multiple ports, multiple protocols and multiple applications on the same = host. [TF] Why should you care what the cert gets used for? We should not limit the use of HTTP validation to certificates that will = be used with HTTP. [TF] Don=E2=80=99t you mean HTTPS validation? =20 While the requirements appear complicated, it is actually fairly = straightforward to support them all if we recognize the distinction = between the Subject and the Host. Since there is a relationship between = the subject and the issuer that potentially persists across multiple = certificate issue transactions, this implies some form of = account/credential. Since we are doing PKI we can insist that the = credential used to authenticate transactions be a public key. =20 For a free cert provider with a zero touch model, the account identifier = might well be simply the public key or a fingerprint thereof. If the = account identifier is never seen by a user, it does not need to be = particularly human readable. =20 =20 Thoughts? Comments? =20 =20 =20 ------=_NextPart_000_002E_01D00F31.0A07C580 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

See inline

From:= = Acme [mailto:acme-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker
Sent: Wednesday, December 03, 2014 12:32 = PM
To: acme@ietf.org
Subject: [Acme] (Re)Design = sketch

Comodo = has an existing API for certificate issue. It is functional and works = but it isn't ideal because:

1) It isn't JSON and we have customers that demand = JSON.

2) It is proprietary which means we have to support = plug ins for a large number of servers which is costly and reduces the = utility to larger installations.

3) It is rather crusty as features have been added = gradually over the years by a variety of authors in a variety of = styles.

If we follow the path of only addressing the problems = considered important by one CA that has yet to issue a cert then the = result is only going to address the first two problems. We will end up = with another PKIX situation where the stack is ridiculously complicated = BECAUSE of the attempts to 'keep it simple'.

Lowballing requirements results in redundancy and = unnecessary complexity.

A = better way to address the problem is to architect the system recognizing = that in some circumstances functions will be split across different = actors at subscriber site at the start rather than trying to retrofit = this capability as an afterthought.

It isn't just enterprise firewalls that present corner = cases. Managing credentials on a Web service in the cloud presents = similar issues.

Architectural = Constraints:

* = Use the existing CSR format for proof of possession of the private key = for X.509v3 issue.

[TF] Seems reasonable. There is a lot of code on many platforms to do = this.

* Use JSON = encoding for all new structures and protocol messages.

[TF] Seems reasonable if we are defining something new. =

* Assume HTTP = binding, do not rely on HTTPS for security properties.

[TF] Why would we need HTTP?

* Use SRV and = CAA records in DNS to enable automation.

[TF] = These seem niece to have = ret than must haves. You can provide better load bailing and floe via = NLB rather than SRV records.

Actors:

Subject: The party whose identity is = validated

Issuer: The = party that issues the certificate

Host: The machine on which the private key and = certificate are installed

[TF] There is also the DVRA

Recognizing that the Host is not the same as the = Subject is important as without that distinction it becomes impossible = to talk about failures or attacks in a meaningful = way.

Note that as far as the protocol interactions are = concerned, the Issuer need not be a CA. A CA is a party that is subject = to audit and insurance and has actual custody of the signing key. It is = not actually necessary for the Subject to have a direct interaction with = their CA.

[TF] You will have to elaborate on the Asser <> CA part because = I have always takes the issuer to be by definition a CA. The ACME server = is a front end to a CA.

In the ideal situation any party with more than a = dozen certs is going to channel cert requests through a local issuer = which forwards them to a CA (possibly through another = intermediary).

[TF] Do you mean ACME server chaining where one ACME = server sends request to another ACE = server?

Processes:

Validation: Determining that a purported subject meets = a set of criteria specified by a certificate policy and in particular = has the right to use a specified identity.

[TF] Determining that a request meets a set criteria as determined by = a certificate policy. The policy will establish a LoA for the binding to = the subject name.

Key Generation: Generating a public/private key = pair

Certificate Issue: Signing a = Certificate

While each process must occur at least once for a = certificate to be issued, these are three separate = processes.

In particular, Validation is an interaction with the = certificate subject, Certificate Issue is to the Host holding the = corresponding private key. In any deployment that has more than one host = it is going to be desirable to amortize a validation process across the = multiple hosts.

[TF] = Validation does not require = interaction with the entity making the request. An administrator may = have proven control of the domain thereby authorizing the issuance of = certificates in the domain namespace and the subject making the request = it technically their delegate.

Today Key Generation and Validation might occur once = every three years and Certificate Issue once a year. One of the reasons = I am interested in automating Cert Management is to change these = parameters.

My ideal situation would be to perform Key Generation = and Certificate Issue every 24 hours with overlapping 72 hour validity = intervals of which 24 hours is backdated. I certainly don't want to have = to perform OV or EV validation every 24 hours.

[TF] Ironic in that this is the model proposed by Barb Fox many moons = ago=E2=80=A6 I get the frequent cert issuance but frequent key = generation seems a bit ott given the move to pfs. Reissuing a = certificate with the same key is a safer process.

I = am not averse to performing the DV component of validation every 24 = hours as well but the most appropriate response to single validation = failure after a long stream of successful validations is probably to = notify the system admin rather than force their site = offline.

[TF] We need to look at the threat model for the = actual proofs. You could generate false negative due to operational = procedures on the part of the domain. =

A = somewhat more complicated question is how to deal with the problem of = multiple ports, multiple protocols and multiple applications on the same = host.

[TF] Why should you care what the cert gets used = for?

We should not = limit the use of HTTP validation to certificates that will be used with = HTTP.

[TF] Don=E2=80=99t you mean HTTPS = validation?

While the requirements appear complicated, it is = actually fairly straightforward to support them all if we recognize the = distinction between the Subject and the Host. Since there is a = relationship between the subject and the issuer that potentially = persists across multiple certificate issue transactions, this implies = some form of account/credential. Since we are doing PKI we can insist = that the credential used to authenticate transactions be a public = key.

For a free cert provider with a zero touch model, the = account identifier might well be simply the public key or a fingerprint = thereof. If the account identifier is never seen by a user, it does not = need to be particularly human readable.

Thoughts? Comments?

------=_NextPart_000_002E_01D00F31.0A07C580-- From nobody Sun Dec 7 22:38:55 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E578E1A6F7F for ; Sun, 7 Dec 2014 22:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.599 X-Spam-Level: *** X-Spam-Status: No, score=3.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS0_vSNcwCGC for ; Sun, 7 Dec 2014 22:38:49 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id CD8401A6F6B for ; Sun, 7 Dec 2014 22:38:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,536,1413205200"; d="scan'208,217";a="244408379" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 08 Dec 2014 17:24:32 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7645"; a="261762693" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipccvi.tcif.telstra.com.au with ESMTP; 08 Dec 2014 17:38:46 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Mon, 8 Dec 2014 17:38:46 +1100 From: "Manger, James" To: "acme@ietf.org" Date: Mon, 8 Dec 2014 17:38:44 +1100 Thread-Topic: ACME signature mechanics Thread-Index: AdASsZ0M8xUwytSnTxy9udVU0T4hkg== Message-ID: <255B9BB34FB7D647A506DC292726F6E127D5205188@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E127D5205188WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/SkJma2ZHVoHIrr06vIGCxGfW1os Subject: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 06:38:52 -0000 --_000_255B9BB34FB7D647A506DC292726F6E127D5205188WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-barnes-acme looks like a promising spec. https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.txt A couple of comments: 1. The bytes to-be-signed for the various messages are the concatenation of= a few fields, with no separators. signature-input =3D nonce || content signature-input =3D signature-nonce || identifier || server-nonce signature-input =3D signature-nonce || server-nonce This looks problematic as the bytes to-be-signed are not unambiguous by the= mselves. The same signature (eg over ABC) is valid even if bytes are moved = from a nonce to the content (eg nonce=3DA, content=3DBC; and nonce=3DAB, co= ntent=3DC). The same signature may be valid when treated as a different typ= e of message (eg signature-nonce=3DA, identifier=3DB, server-nonce=3DC). Suggestion: signature-input =3D || || ... (wh= ere is the length in bytes of the following field, encoded in 8 byt= es) [P.S. Watson Ladd pointed out a similar issue with HOBA earlier today in an= email titled "[http-auth] Concatenation is not injective". http://www.ietf= .org/mail-archive/web/http-auth/current/msg02053.html] 2. Appending 'path' to '.well-known/acme-challenge' as part of a simpleHttp= s challenge (section 6.1) looks dangerous if not done carefully. What if 'p= ath' is "../../user/alice/whatever"? Suggestion: I would be tempted to say: "take the 'path' string value, UTF-8= encode it, base64url-encode those bytes, then append to '.well-known/acme-= challenge'". 3. 'nonce' is "at least 16 bytes, base64-encoded" according to section 5.2 = "Signatures". Is the base64-encoding removed before using the nonce as part= of the signature input? -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E127D5205188WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-barnes-acm= e looks like a promising spec.

https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme= .txt

A couple of comments= :

1. The bytes to-be-signed for the various messages are the concatenatio= n of a few fields, with no separators.

&= nbsp; signature-input =3D nonce || content

signature-input =3D signature-nonce || identifier || = server-nonce

signature-inpu= t =3D signature-nonce || server-nonce

Th= is looks problematic as the bytes to-be-signed are not unambiguous by thems= elves. The same signature (eg over ABC) is valid even if bytes are moved fr= om a nonce to the content (eg nonce=3DA, content=3DBC; and nonce=3DAB, cont= ent=3DC). The same signature may be valid when treated as a different type = of message (eg signature-nonce=3DA, identifier=3DB, server-nonce=3DC).=

Su= ggestion: signature-input =3D <len1><field1> || <len2><= ;field2> || … (where <lenn> is the length in by= tes of the following field, encoded in 8 bytes)

[P.S. Watson Ladd pointed= out a similar issue with HOBA earlier today in an email titled “[htt= p-auth] Concatenation is not injective”. http://www.ietf.org/ma= il-archive/web/http-auth/current/msg02053.html]

2. Appending ‘path’ to ‘.well-known= /acme-challenge’ as part of a simpleHttps challenge (section 6.1) loo= ks dangerous if not done carefully. What if ‘path’ is “..= /../user/alice/whatever”?

&nb= sp;

Suggestion: I would be tempted to say: &#= 8220;take the ‘path’ string value, UTF-8 encode it, base64url-e= ncode those bytes, then append to ‘.well-known/acme-challenge’&= #8221;.

3. ‘nonce’ = is “at least 16 bytes, base64-encoded” according to section 5.2= “Signatures”. Is the base64-encoding removed before using the = nonce as part of the signature input?

James Manger

= --_000_255B9BB34FB7D647A506DC292726F6E127D5205188WSMSG3153Vsrv_-- From nobody Sun Dec 7 22:59:17 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42241A6F80 for ; Sun, 7 Dec 2014 22:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4pvGc4U26Vk for ; Sun, 7 Dec 2014 22:59:14 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D641A1A1E for ; Sun, 7 Dec 2014 22:59:14 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id hq12so1850792vcb.21 for ; Sun, 07 Dec 2014 22:59:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xCRMGxR6ZjR4R2g33Y42KAQ/z4FEC766bmo9/hLTTc0=; b=ErRush/jf3ahYwJOtykFbRPBOJlvS42mduVDEqtAdXFv0ofC7qRIQlF4+Y9cv/79PG 9BnRCD+9Il80HKwPd2MKc+u82Cfk6to537qSeWV8WUXXicxsTiagJpl8vX3ZBgzEM4q8 zZ4PCip0R6D5guSFLjnMcsms29RxdAE9HDHhgVFLCYtAJWGPJRpZeGx5CS6+8sNM6Dvb Qcvb5RNhmcSUVVDGPW6DzoNRVVgQelqPImD581bMjPpsNgFuRFA6FJkO/aI3hJu+T+st 7wyHruFrIKtwsEy8Ka5tIzX62/3Gr3JOcHefUGpHZDYWG5EMnl0oXnzipYHI2mMCtjjr IMNw== X-Gm-Message-State: ALoCoQn3R2zoI9Y5JteTelyQ9s2Rnarj8kOout+jMsCINS68Des/92w7PjrIQDZUjXCVmlLxxsZk MIME-Version: 1.0 X-Received: by 10.52.117.161 with SMTP id kf1mr19920725vdb.65.1418021953202; Sun, 07 Dec 2014 22:59:13 -0800 (PST) Received: by 10.31.139.9 with HTTP; Sun, 7 Dec 2014 22:59:13 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127D5205188@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E127D5205188@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 7 Dec 2014 22:59:13 -0800 Message-ID: From: Richard Barnes To: "Manger, James" Content-Type: multipart/alternative; boundary=bcaec547cbddce2e740509aef67b Archived-At: http://mailarchive.ietf.org/arch/msg/acme/2nyR8aJGCypzAPWk436IUBv6sIo Cc: "acme@ietf.org" Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 06:59:16 -0000 --bcaec547cbddce2e740509aef67b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey James, Thanks for the comments. On Sun, Dec 7, 2014 at 10:38 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > draft-barnes-acme looks like a promising spec. > > https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.tx= t > Thanks! > > A couple of comments: > > > > 1. The bytes to-be-signed for the various messages are the concatenation > of a few fields, with no separators. > > signature-input =3D nonce || content > > signature-input =3D signature-nonce || identifier || server-nonce > > signature-input =3D signature-nonce || server-nonce > > This looks problematic as the bytes to-be-signed are not unambiguous by > themselves. The same signature (eg over ABC) is valid even if bytes are > moved from a nonce to the content (eg nonce=3DA, content=3DBC; and nonce= =3DAB, > content=3DC). The same signature may be valid when treated as a different > type of message (eg signature-nonce=3DA, identifier=3DB, server-nonce=3DC= ). > > > > Suggestion: signature-input =3D || || =E2= =80=A6 (where > is the length in bytes of the following field, encoded in 8 > bytes) > > > > [P.S. Watson Ladd pointed out a similar issue with HOBA earlier today in > an email titled =E2=80=9C[http-auth] Concatenation is not injective=E2=80= =9D. > http://www.ietf.org/mail-archive/web/http-auth/current/msg02053.html] > Adam Langley also pointed this out in a Github issue. I think the simplest answer is going to be to just use JWS to sign the entire request, including the nonce as a protected header field. That gets around these issues, and re-uses the JWS machinery. > 2. Appending =E2=80=98path=E2=80=99 to =E2=80=98.well-known/acme-challeng= e=E2=80=99 as part of a > simpleHttps challenge (section 6.1) looks dangerous if not done carefully= . > What if =E2=80=98path=E2=80=99 is =E2=80=9C../../user/alice/whatever=E2= =80=9D? > > > > Suggestion: I would be tempted to say: =E2=80=9Ctake the =E2=80=98path=E2= =80=99 string value, > UTF-8 encode it, base64url-encode those bytes, then append to > =E2=80=98.well-known/acme-challenge=E2=80=99=E2=80=9D. > Good point. It seems like a simpler solution would just be to require that the "path" value meet a certain ABNF, e.g., the URL-safe base64 alphabet. The only reason that the client provides the path is to let it avoid collisions if it has multiple validations in progress, so there's not a need for it to be especially expressive. > 3. =E2=80=98nonce=E2=80=99 is =E2=80=9Cat least 16 bytes, base64-encoded= =E2=80=9D according to section 5.2 > =E2=80=9CSignatures=E2=80=9D. Is the base64-encoding removed before using= the nonce as part > of the signature input? > That was my intent, but if we make the JWS change mentioned above, then this won't matter. --Richard > > > -- > > James Manger > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --bcaec547cbddce2e740509aef67b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hey James,

Thanks for the comments.

On Sun, Dec 7, 2014 at 10:3= 8 PM, Manger, James <James.H.Manger@team.telstra.com>= wrote:

draft-barnes-acme lo= oks like a promising spec.
https://github.com/letsencrypt/acme-spec/blob/master= /draft-barnes-acme.txt

=C2=A0

Thanks!

=C2=A0

=
=C2=A0
A couple of= comments:
=C2=A0
=
1. The bytes to-be-signed for the various messages a= re the concatenation of a few fields, with no separators.
=
=C2=A0=C2=A0 signature-input =3D nonce || content=
=C2=A0=C2=A0 signature-input =3D sign= ature-nonce || identifier || server-nonce
=C2=A0=C2=A0 signature-input =3D signature-nonce || server-nonce<= /u>
This looks problematic as the bytes to= -be-signed are not unambiguous by themselves. The same signature (eg over A= BC) is valid even if bytes are moved from a nonce to the content (eg nonce= =3DA, content=3DBC; and nonce=3DAB, content=3DC). The same signature may be= valid when treated as a different type of message (eg signature-nonce=3DA,= identifier=3DB, server-nonce=3DC).
=C2=A0
Suggestion: signature-input= =3D <len1><field1> || <len2><field2> || =E2=80=A6 = (where <lenn> is=C2=A0 the length in bytes of the following fi= eld, encoded in 8 bytes)
=C2= =A0
[P.S. Watson Ladd pointed out a simila= r issue with HOBA earlier today in an email titled =E2=80=9C[http-auth] Con= catenation is not injective=E2=80=9D. http://www.ie= tf.org/mail-archive/web/http-auth/current/msg02053.html]

Adam Langley also pointed this out in a G= ithub issue.

I think the simplest answer is going to be t= o just use JWS to sign the entire request, including the nonce as a protect= ed header field.=C2=A0 That gets around these issues, and re-uses the JWS m= achinery.

=C2=A0

2. Appending =E2=80=98p= ath=E2=80=99 to =E2=80=98.well-known/acme-challenge=E2=80=99 as part of a s= impleHttps challenge (section 6.1) looks dangerous if not done carefully. W= hat if =E2=80=98path=E2=80=99 is =E2=80=9C../../user/alice/whatever=E2=80= =9D?
=C2=A0
Suggestion: I would be tempted to say: =E2=80=9Ctake the = =E2=80=98path=E2=80=99 string value, UTF-8 encode it, base64url-encode thos= e bytes, then append to =E2=80=98.well-known/acme-challenge=E2=80=99=E2=80= =9D.

Good point.=C2=A0 It s= eems like a simpler solution would just be to require that the "path&q= uot; value meet a certain ABNF, e.g., the URL-safe base64 alphabet.=C2=A0 T= he only reason that the client provides the path is to let it avoid collisi= ons if it has multiple validations in progress, so there's not a need f= or it to be especially expressive.

=C2=A0=C2=A0

3. =E2=80=98nonce=E2=80=99 is =E2=80=9Ca= t least 16 bytes, base64-encoded=E2=80=9D according to section 5.2 =E2=80= =9CSignatures=E2=80=9D. Is the base64-encoding removed before using the non= ce as part of the signature input?

That was my intent, but if we make the JWS change men= tioned above, then this won't matter.

--Richard

=C2=A0
=C2=A0
--=
James Manger
=C2=A0

______________________________= _________________
Acme mailing list
Acme@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/acme

--bcaec547cbddce2e740509aef67b-- From nobody Sun Dec 7 23:15:56 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C851A6FD4 for ; Sun, 7 Dec 2014 23:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dtfikHiwou3 for ; Sun, 7 Dec 2014 23:15:43 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9D71A6FCC for ; Sun, 7 Dec 2014 23:15:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,537,1413205200"; d="scan'208,217";a="244415310" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 08 Dec 2014 18:01:22 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7645"; a="319179452" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcavi.tcif.telstra.com.au with ESMTP; 08 Dec 2014 18:15:37 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Mon, 8 Dec 2014 18:15:36 +1100 From: "Manger, James" To: Richard Barnes Date: Mon, 8 Dec 2014 18:15:35 +1100 Thread-Topic: [Acme] ACME signature mechanics Thread-Index: AdAStHwHzfxL5PPwRgSpi3Ok2vOPrgAAV8zw Message-ID: <255B9BB34FB7D647A506DC292726F6E127D52051C8@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E127D5205188@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E127D52051C8WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/kdKNWaUVJL2v-sIB8BfeDqX47V8 Cc: "acme@ietf.org" Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 07:15:44 -0000 --_000_255B9BB34FB7D647A506DC292726F6E127D52051C8WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Mi4gQXBwZW5kaW5nIOKAmHBhdGjigJkgdG8g4oCYLndlbGwta25vd24vYWNtZS1jaGFsbGVuZ2Xi gJkgYXMgcGFydCBvZiBhIHNpbXBsZUh0dHBzIGNoYWxsZW5nZSAoc2VjdGlvbiA2LjEpIGxvb2tz IGRhbmdlcm91cyBpZiBub3QgZG9uZSBjYXJlZnVsbHkuIFdoYXQgaWYg4oCYcGF0aOKAmSBpcyDi gJwuLi8uLi91c2VyL2FsaWNlL3doYXRldmVy4oCdPw0KDQpTdWdnZXN0aW9uOiBJIHdvdWxkIGJl IHRlbXB0ZWQgdG8gc2F5OiDigJx0YWtlIHRoZSDigJhwYXRo4oCZIHN0cmluZyB2YWx1ZSwgVVRG LTggZW5jb2RlIGl0LCBiYXNlNjR1cmwtZW5jb2RlIHRob3NlIGJ5dGVzLCB0aGVuIGFwcGVuZCB0 byDigJgud2VsbC1rbm93bi9hY21lLWNoYWxsZW5nZeKAmeKAnS4NCg0KPiBHb29kIHBvaW50LiAg SXQgc2VlbXMgbGlrZSBhIHNpbXBsZXIgc29sdXRpb24gd291bGQganVzdCBiZSB0byByZXF1aXJl IHRoYXQgdGhlICJwYXRoIiB2YWx1ZSBtZWV0IGEgY2VydGFpbiBBQk5GLCBlLmcuLCB0aGUgVVJM LXNhZmUgYmFzZTY0IGFscGhhYmV0LiAgVGhlIG9ubHkgcmVhc29uIHRoYXQgdGhlIGNsaWVudCBw cm92aWRlcyB0aGUgcGF0aCBpcyB0byBsZXQgaXQgYXZvaWQgY29sbGlzaW9ucyBpZiBpdCBoYXMg bXVsdGlwbGUgdmFsaWRhdGlvbnMgaW4gcHJvZ3Jlc3MsIHNvIHRoZXJlJ3Mgbm90IGEgbmVlZCBm b3IgaXQgdG8gYmUgZXNwZWNpYWxseSBleHByZXNzaXZlLg0KDQpUaGF0IG1pZ2h0IGJlIHNpbXBs ZXIsIGJ1dCBpdCByZWxpZXMgb24gY2xpZW50cyBkb2luZyBpbnB1dCB2YWxpZGF0aW9uIG9uIOKA mHBhdGjigJkuIFRlbGxpbmcgdGhlIGNsaWVudCB0byBCNjQgd2hhdGV2ZXIgaXQgZ2V0cyBtaWdo dCBiZSBqdXN0IGEgc21pZGdlbiBzYWZlci4NCg0KLS0NCkphbWVzIE1hbmdlcg0K --_000_255B9BB34FB7D647A506DC292726F6E127D52051C8WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwv aGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1X b3JkU2VjdGlvbjE+PGRpdj48ZGl2PjxkaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtJz48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+Mi4gQXBwZW5kaW5nIOKAmHBhdGjigJkgdG8g4oCYLndlbGwta25vd24vYWNt ZS1jaGFsbGVuZ2XigJkgYXMgcGFydCBvZiBhIHNpbXBsZUh0dHBzIGNoYWxsZW5nZSAoc2VjdGlv biA2LjEpIGxvb2tzIGRhbmdlcm91cyBpZiBub3QgZG9uZSBjYXJlZnVsbHkuIFdoYXQgaWYg4oCY cGF0aOKAmSBpcyDigJwuLi8uLi91c2VyL2FsaWNlL3doYXRldmVy4oCdPzxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPlN1Z2dlc3Rpb246IEkgd291bGQgYmUgdGVtcHRlZCB0byBzYXk6IOKAnHRha2UgdGhl IOKAmHBhdGjigJkgc3RyaW5nIHZhbHVlLCBVVEYtOCBlbmNvZGUgaXQsIGJhc2U2NHVybC1lbmNv ZGUgdGhvc2UgYnl0ZXMsIHRoZW4gYXBwZW5kIHRvIOKAmC53ZWxsLWtub3duL2FjbWUtY2hhbGxl bmdl4oCZ4oCdLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz4mZ3Q7IDwvc3Bhbj5Hb29kIHBvaW50LiZuYnNwOyBJdCBzZWVtcyBsaWtlIGEg c2ltcGxlciBzb2x1dGlvbiB3b3VsZCBqdXN0IGJlIHRvIHJlcXVpcmUgdGhhdCB0aGUgJnF1b3Q7 cGF0aCZxdW90OyB2YWx1ZSBtZWV0IGEgY2VydGFpbiBBQk5GLCBlLmcuLCB0aGUgVVJMLXNhZmUg YmFzZTY0IGFscGhhYmV0LiZuYnNwOyBUaGUgb25seSByZWFzb24gdGhhdCB0aGUgY2xpZW50IHBy b3ZpZGVzIHRoZSBwYXRoIGlzIHRvIGxldCBpdCBhdm9pZCBjb2xsaXNpb25zIGlmIGl0IGhhcyBt dWx0aXBsZSB2YWxpZGF0aW9ucyBpbiBwcm9ncmVzcywgc28gdGhlcmUncyBub3QgYSBuZWVkIGZv ciBpdCB0byBiZSBlc3BlY2lhbGx5IGV4cHJlc3NpdmUuPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGF0IG1p Z2h0IGJlIHNpbXBsZXIsIGJ1dCBpdCByZWxpZXMgb24gY2xpZW50cyBkb2luZyBpbnB1dCB2YWxp ZGF0aW9uIG9uIOKAmHBhdGjigJkuIFRlbGxpbmcgdGhlIGNsaWVudCB0byBCNjQgd2hhdGV2ZXIg aXQgZ2V0cyBtaWdodCBiZSBqdXN0IGEgc21pZGdlbiBzYWZlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn Pi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E127D52051C8WSMSG3153Vsrv_-- From nobody Sun Dec 7 23:45:12 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DA91A6FF5 for ; Sun, 7 Dec 2014 23:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnxGl7JkYS4U for ; Sun, 7 Dec 2014 23:45:09 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807B01A6FE1 for ; Sun, 7 Dec 2014 23:45:09 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id le20so1935677vcb.12 for ; Sun, 07 Dec 2014 23:45:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EztPufirnZixZrDegLdTMbJSgn7MJKmouooOZaTZ/9I=; b=bM6npG0qP5moPjXE7nYGdEiqvfO84pN2kWKupwdQf8fZzKfPvU5WJ1BL7nVHoJUaHE 73GRnFi4hvReu3jjmaORC5cxchFhAPoh8dvx7o2Rrqn5HAdWavkSjVKpiEFbDOH/tYCO cGC4kll+X1Dr6alwNiiml7DcXr1wPix1V/HnH8nkT0qaDHPc8RAwyHWAt80Qkwit1aoC QOB3A+QSB0QO1tS4npw4gbh+k2Fabu60gC79CdYUvu1Z9JfMpcqeAKP+/GB5rPmX1cO7 ZDjbYE4bV9M67CZPEtulS8DbT1RUSwkcXmaf1kHSiBvkRvoI6aUXBqxaeR7+XY+chru8 doyA== X-Gm-Message-State: ALoCoQkIBgVp10K6+0Iu3q0q0Kds39jP8CSLChHFG7dxs4qUhhlTzt6v8PCZ+T4TpkutstAHMMo2 MIME-Version: 1.0 X-Received: by 10.221.66.143 with SMTP id xq15mr23956697vcb.35.1418024708691; Sun, 07 Dec 2014 23:45:08 -0800 (PST) Received: by 10.31.139.9 with HTTP; Sun, 7 Dec 2014 23:45:08 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127D52051C8@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E127D5205188@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E127D52051C8@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 7 Dec 2014 23:45:08 -0800 Message-ID: From: Richard Barnes To: "Manger, James" Content-Type: multipart/alternative; boundary=001a113608d20b68e10509af9bfd Archived-At: http://mailarchive.ietf.org/arch/msg/acme/aMhg-ijjhUBUtZEdS6p6mRuVkg4 Cc: "acme@ietf.org" Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 07:45:11 -0000 --001a113608d20b68e10509af9bfd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 7, 2014 at 11:15 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > 2. Appending =E2=80=98path=E2=80=99 to =E2=80=98.well-known/acme-challeng= e=E2=80=99 as part of a > simpleHttps challenge (section 6.1) looks dangerous if not done carefully= . > What if =E2=80=98path=E2=80=99 is =E2=80=9C../../user/alice/whatever=E2= =80=9D? > > > > Suggestion: I would be tempted to say: =E2=80=9Ctake the =E2=80=98path=E2= =80=99 string value, > UTF-8 encode it, base64url-encode those bytes, then append to > =E2=80=98.well-known/acme-challenge=E2=80=99=E2=80=9D. > > > > > Good point. It seems like a simpler solution would just be to require > that the "path" value meet a certain ABNF, e.g., the URL-safe base64 > alphabet. The only reason that the client provides the path is to let it > avoid collisions if it has multiple validations in progress, so there's n= ot > a need for it to be especially expressive. > > > > That might be simpler, but it relies on clients doing input validation on > =E2=80=98path=E2=80=99. Telling the client to B64 whatever it gets might = be just a smidgen > safer. > Relies on *servers* doing input validation; the client chooses the path. And if the server isn't validating its inputs, we have bigger problems :) Since not checking other inputs can lead to the issuance of bad certs. --Richard > -- > > James Manger > --001a113608d20b68e10509af9bfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Dec 7, 2014 at 11:15 PM, Manger, James <James.H.= Manger@team.telstra.com> wrote:

=
2. Appending =E2=80=98path=E2=80=99 to =E2=80= =98.well-known/acme-challenge=E2=80=99 as part of a simpleHttps challenge (= section 6.1) looks dangerous if not done carefully. What if =E2=80=98path= =E2=80=99 is =E2=80=9C../../user/alice/whatever=E2=80=9D?
=
=C2=A0
Sugge= stion: I would be tempted to say: =E2=80=9Ctake the =E2=80=98path=E2=80=99 = string value, UTF-8 encode it, base64url-encode those bytes, then append to= =E2=80=98.well-known/acme-challenge=E2=80=99=E2=80=9D.
=C2=A0
=
> Good point.=C2=A0 It seems like a simpler s= olution would just be to require that the "path" value meet a cer= tain ABNF, e.g., the URL-safe base64 alphabet.=C2=A0 The only reason that t= he client provides the path is to let it avoid collisions if it has multipl= e validations in progress, so there's not a need for it to be especiall= y expressive.
=C2=A0=C2= =A0
That might be simpler, but it relies on clients doing in= put validation on =E2=80=98path=E2=80=99. Telling the client to B64 whateve= r it gets might be just a smidgen safer.
=

Relies on *servers* doing input validation= ; the client chooses the path.=C2=A0 And if the server isn't validating= its inputs, we have bigger problems :)=C2=A0 Since not checking other inpu= ts can lead to the issuance of bad certs.

--Richard

=C2=A0

--
= James Manger

--001a113608d20b68e10509af9bfd-- From nobody Tue Dec 16 01:22:55 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B161ACD42 for ; Tue, 16 Dec 2014 01:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWvX--HSXbu9 for ; Tue, 16 Dec 2014 01:22:51 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA74C1A1A67 for ; Tue, 16 Dec 2014 01:22:50 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so16940282wgh.2 for ; Tue, 16 Dec 2014 01:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=aSDtJZBNuaf2jaQp2hkLPpRJM4/KGF8G5rhltQ/rqxU=; b=Xm+OFykc2IZHRu30oPUEP+QGkmEZKMDO258EgqcUctVyQOHC+dTXPpDP4PWVI/ZBU4 Ji4hc3E5ZVovbhFStxgIe9d54GhI9GStUAnCzVqwDqEzhQrGiwFU2IrJSNgSQG0PLtCP NABietdlZUNtfh7Rrp08TVKi5fx1i9GxhdmM8IuMsqs53EfEB9E0X/Eaa8OO5ihCFOYa U97lK377NvCHRWYTx5pLUKqlHkHt+pCE4OXTICTMbPS2D2YIBTH1i3bY2yfXFglGUS8a LNRcLWKWPl5Tdsgl6qKa1qEQm5QMUkwnI3azmLsH11Tap2HX/539cOcjLXPJVhR9aZOs /1MA== X-Received: by 10.194.108.98 with SMTP id hj2mr60620778wjb.102.1418721769502; Tue, 16 Dec 2014 01:22:49 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id e7sm340760wjx.31.2014.12.16.01.22.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 01:22:48 -0800 (PST) Message-ID: <548FF9E3.1020703@gmail.com> Date: Tue, 16 Dec 2014 10:22:43 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: acme@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/vNTcThXh5_gin0D_kb9XIx_zlRk Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 09:22:53 -0000 When the transition to JWS has been made, human-readable ACME messages like { "type": "certificateRequest", "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P", "signature": { "alg": "RS256", "nonce": "h5aYpWVkq-xlJh6cpR-3cw", "sig": "KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ", "jwk": { "kty":"RSA", "e":"AQAB", "n":"KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ" } } } will rather look like { "payload":"", "protected":"", "header":, "signature":"" } Which apart from being ugly JWS also requires a JSON schema validator (or similar mechanism) to work on separate, unpacked parts of the message. Although I don't expect this to change, you may (or may not) want to know that clear-text JSON signatures (without the complexity of XML DSig), is not black magic, you only have to use JSON parsers that doesn't "manipulate" input data: https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Sample_Signature Cheers AndersR From nobody Tue Dec 16 02:54:31 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A071A1A50 for ; Tue, 16 Dec 2014 02:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSXrHxngGFqA for ; Tue, 16 Dec 2014 02:54:27 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698301A0108 for ; Tue, 16 Dec 2014 02:54:27 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so17090592wgg.0 for ; Tue, 16 Dec 2014 02:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=flYEK9NTYx2xrgjVJNrDTPnDuefFvYtJTGLydA3eJFQ=; b=mGDCiwY7p1totdNWU8WXyH25nftxwEVMQ74jq+2167F0+475m2/E3MeSiqudiG4/Km fBVEg7sktwJ7ujlnNgjOUG1lanKh1dKNobIV1krSg7si53DW7Am9oNlt4+yD77ZIDOJo 8VSF/llHOmhM83N5PNSKmngX4v1G/rFAKb0hKCiB1Ob8NEdK2h/CF7AxsON3ifmNBCK8 gvc5A+12W2s/tXSA1R9sQFLW1CxqbkPamzUetE1yQAC0sqstXS56FoAdUwIhFyHyy3ci ex74pJ8SwnRWa3PWuG1QXJxu8fwmKbHzu0TsONYMx946ARd95hOpUo9K57o9Q00OxIVU q8uQ== X-Received: by 10.194.87.100 with SMTP id w4mr61956745wjz.65.1418727265659; Tue, 16 Dec 2014 02:54:25 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id dr3sm1691190wib.4.2014.12.16.02.54.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 02:54:25 -0800 (PST) Message-ID: <54900F5C.2000809@gmail.com> Date: Tue, 16 Dec 2014 11:54:20 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: acme@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/UpGE2533QZpjQAfbvsIqHx340-c Subject: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 10:54:29 -0000 Hi List, I don't see an absolute necessity continuing with PKCS #10 in a JSON-world: https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.KeyCreationResponse I was able to integrate this (with ease) in EJBCA which is the most widely used Open Source CA. Anders From nobody Tue Dec 16 05:09:38 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8A31ACD88 for ; Tue, 16 Dec 2014 05:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4nCVMI606hH for ; Tue, 16 Dec 2014 05:09:24 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168A11ACD84 for ; Tue, 16 Dec 2014 05:09:15 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id 10so10994010lbg.1 for ; Tue, 16 Dec 2014 05:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=sdpAY9eMLpV6CSEeF7cZKQCkph3Y70Y+nCFyrJZ/H50=; b=A6voMmb/EmAOmZ5Rmsjmo+lPEQpmu82TygikfR/xKgbUKyetsZeNAw8C5HfLP0/b1g nFomFTeFQeBF+G9CwiYHOmRmcN0irRaaDqqqCoLhHcvokZdYhNDm3kK6ucyM3Kti1u2U c3y9SauNrfslxgnevdxrkUTyGcfBT/8Tlf5AYoS/Ov/wawZPS3I+E98W04mp8abjZ9z/ Eg6PVY9s7JlAcfuawTEtrKWW9byNH/4fEM6qJU6T3z1wUBxWW3+3+G7JzKnbxhuS28fF PXS+BUIocdB4dJp7o644eAul395VpFgaXxDjBVCGwsF+spSgwlnhGJ4nIwOyhuQBhef7 a1CA== MIME-Version: 1.0 X-Received: by 10.153.11.170 with SMTP id ej10mr35662128lad.24.1418735347706; Tue, 16 Dec 2014 05:09:07 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Tue, 16 Dec 2014 05:09:07 -0800 (PST) In-Reply-To: <54900F5C.2000809@gmail.com> References: <54900F5C.2000809@gmail.com> Date: Tue, 16 Dec 2014 08:09:07 -0500 X-Google-Sender-Auth: aawZB3TO1o5pAHYYS0WCklIZy_I Message-ID: From: Phillip Hallam-Baker To: "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a113479146e345f050a551024 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/zrk11XD_q75E25z-3k0e7HuAZx8 Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:09:26 -0000 --001a113479146e345f050a551024 Content-Type: text/plain; charset=UTF-8 Since we are going to be generating X.509 certificates, ASN.1 is inescapable. There is a lot of machinery that depends on generating CSRs. So support for CSRs is essential. Duplicating that functionality in JSON does not seem like a priority to me. Now if we were getting rid of the ASN.1 in the certs as well I could see a point. But that is not a 1.0 thing. On Tue, Dec 16, 2014 at 5:54 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > > Hi List, > I don't see an absolute necessity continuing with PKCS #10 in a JSON-world: > https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html# > Sample.KeyCreationResponse > > I was able to integrate this (with ease) in EJBCA which is the most widely > used Open Source CA. > > Anders > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a113479146e345f050a551024 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Since we are going to be generating X.509 certificates, AS= N.1 is inescapable.

There is a lot of machinery that dep= ends on generating CSRs. So support for CSRs is essential. Duplicating that= functionality in JSON does not seem like a priority to me.

<= /div>

Now if we were getting rid of the ASN.1 in the cer= ts as well I could see a point. But that is not a 1.0 thing.

On Tu= e, Dec 16, 2014 at 5:54 AM, Anders Rundgren <anders.rundgren= .net@gmail.com> wrote:

Hi List,=
I don't see an absolute necessity continuing with PKCS #10 in a JSON-wo= rld:
https://openkeystor= e.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.KeyCreationResponse

I was able to integrate this (with ease) in EJBCA which is the most widely = used Open Source CA.

Anders

_______________________________________________
Acme mailing list
Acme@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/acme

--001a113479146e345f050a551024-- From nobody Tue Dec 16 07:47:58 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4ED1A1B05 for ; Tue, 16 Dec 2014 07:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP5G_q_ZEFZL for ; Tue, 16 Dec 2014 07:47:49 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB401A1B30 for ; Tue, 16 Dec 2014 07:47:49 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 12C7347622; Tue, 16 Dec 2014 15:47:48 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 05E1C4761B; Tue, 16 Dec 2014 15:47:48 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 001F680040; Tue, 16 Dec 2014 15:47:48 +0000 (GMT) Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 16 Dec 2014 10:47:41 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.15]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Tue, 16 Dec 2014 10:47:41 -0500 From: "Salz, Rich" To: Phillip Hallam-Baker , "acme@ietf.org" Date: Tue, 16 Dec 2014 10:47:40 -0500 Thread-Topic: [Acme] CSR in JSON Thread-Index: AdAZMZCRzRACJy++TUK50xKZr6xCzQAFb6pQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F27D@USMBX1.msg.corp.akamai.com> References: <54900F5C.2000809@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/C0xTnjD7EUxoRMCMtj_10_HSHzE Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 15:47:57 -0000 PiBTaW5jZSB3ZSBhcmUgZ29pbmcgdG8gYmUgZ2VuZXJhdGluZyBYLjUwOSBjZXJ0aWZpY2F0ZXMs IEFTTi4xIGlzIGluZXNjYXBhYmxlLg0KDQpZZXMsIGJ1dCBub3QgbmVjZXNzYXJpbHkgZm9yIGFu eXRpbmcgb3RoZXIgdGhhbiB0aGUgY2VydHMuDQoNCj5UaGVyZSBpcyBhIGxvdCBvZiBtYWNoaW5l cnkgdGhhdCBkZXBlbmRzIG9uIGdlbmVyYXRpbmcgQ1NScy4gU28gc3VwcG9ydCBmb3IgQ1NScyBp cyBlc3NlbnRpYWwuIER1cGxpY2F0aW5nIHRoYXQgZnVuY3Rpb25hbGl0eSBpbiBKU09OIGRvZXMg bm90IHNlZW0gbGlrZSBhIHByaW9yaXR5IHRvIG1lLg0KDQpBZ3JlZSB3aXRoIGZpcnN0IHNlbnRl bmNlLCBkaXNhZ3JlZSB3aXRoIHRoZSBzZWNvbmQsIGFuZCBoYXZlIGFuIG9wZW4gbWluZCBvbiB0 aGUgdGhpcmQuDQoNClRoZXJlIGFyZSBtYW55IGNlcnRpZmljYXRlIGVucm9sbG1lbnQgcHJvdGNv bHMgYW5kIGRhdGEgZm9ybWF0cyBhbHJlYWR5IG91dCB0aGVyZS4gIEkgZG9uJ3QgYmVsaWV2ZSBB Q01FIG5lZWRzIHRvIGJlIHRpZWQgdG8gaW50ZXJvcCB3aXRoIGFueSBvZiB0aGVtLiBBZnRlciBh bGwsIGlmIHRoZXkgd2VyZSBhcyB3aWxkbHkgc3VjY2Vzc2Z1bCBhcyBpbml0aWFsbHkgZXhwZWN0 ZWQsIHRoZXJlIHdvdWxkbid0IGJlIG5lZWQgZm9yIHlldCBhbm90aGVyLg0KDQo= From nobody Tue Dec 16 08:23:30 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C52C1A1B44 for ; Tue, 16 Dec 2014 08:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtqmGoVAQXuB for ; Tue, 16 Dec 2014 08:23:27 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8761A1B30 for ; Tue, 16 Dec 2014 08:23:27 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq11so6649618vcb.37 for ; Tue, 16 Dec 2014 08:23:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e8Z4SsnT0ghmk09SoUJdrbJntNPbS2xWfh8m+esxXpg=; b=JRxIcE1fuHyx5ryL9zxvRtTb4+8+07/Klq8l0FLDFWbvB4vTIY4c9ty9S4DQL2jOvc Q+2ZPoUe+WkUeS8TOSrOjfzZGjing9OmwOrIpN4C2CjeFPgQBPJJzg5JU/ldMeadxgVU GEhbN2lrIHaLbXNFg0pKCA8n67IBUlvAXgV5utJDZ/bKHdBaT+QR1BplkcvY198LWwbR Eq/KknRZpBYrImovRSrkOlkPZturZD8/I3a6B+9eYSw7+WifmTNEyg+wsRB+xTH7cyWY GedeKEnMc3i+me9Ua3ZJ9RBKsxY2H5gLm1mHZfi4rDO9fCz2LgcT75l6pyR3eQLv+f2P k2Aw== X-Gm-Message-State: ALoCoQleJfDV4woMSXEFV1PcgAMq8rZQIevAz9cFB29R6XbRhfCWWF05OGBkqx5NpRLQqedVdSaY MIME-Version: 1.0 X-Received: by 10.220.92.69 with SMTP id q5mr20894601vcm.35.1418747006219; Tue, 16 Dec 2014 08:23:26 -0800 (PST) Received: by 10.31.139.9 with HTTP; Tue, 16 Dec 2014 08:23:26 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F27D@USMBX1.msg.corp.akamai.com> References: <54900F5C.2000809@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F27D@USMBX1.msg.corp.akamai.com> Date: Tue, 16 Dec 2014 11:23:26 -0500 Message-ID: From: Richard Barnes To: "Salz, Rich" Content-Type: multipart/alternative; boundary=089e015375ba550bac050a57c7ea Archived-At: http://mailarchive.ietf.org/arch/msg/acme/XfuSHiG44a2X_JO85D3WYsiBU7I Cc: Phillip Hallam-Baker , "acme@ietf.org" Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:23:29 -0000 --089e015375ba550bac050a57c7ea Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 10:47 AM, Salz, Rich wrote: > > > Since we are going to be generating X.509 certificates, ASN.1 is > inescapable. > > Yes, but not necessarily for anyting other than the certs. > > >There is a lot of machinery that depends on generating CSRs. So support > for CSRs is essential. Duplicating that functionality in JSON does not seem > like a priority to me. > > Agree with first sentence, disagree with the second, and have an open mind > on the third. > > There are many certificate enrollment protcols and data formats already > out there. I don't believe ACME needs to be tied to interop with any of > them. After all, if they were as wildly successful as initially expected, > there wouldn't be need for yet another. > I'm in sort of the same place as PHB here. No, we don't necessarily have to interop with legacy stuff (though it wouldn't hurt). But we do need a language to talk about X.509 certs, and CSRs have that. If we invented something new, we would have to re-do a bunch of stuff that CSRs already have. Of course, if we get extensibility right, we can add a non-CSR option in the future, if people really think they need it. --Richard > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --089e015375ba550bac050a57c7ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 16, 2014 at 10:47 AM, Salz, Rich <rsalz@akamai.com><= /span> wrote:

> Since we = are going to be generating X.509 certificates, ASN.1 is inescapable.

Yes, but not necessarily for anyting other than the certs.

>There is a lot of machinery that depends on generating CSRs. So support= for CSRs is essential. Duplicating that functionality in JSON does not see= m like a priority to me.

Agree with first sentence, disagree with the second, and have an ope= n mind on the third.

There are many certificate enrollment protcols and data formats already out= there.=C2=A0 I don't believe ACME needs to be tied to interop with any= of them. After all, if they were as wildly successful as initially expecte= d, there wouldn't be need for yet another.

I'm in sort of the same place as PHB here.=C2=A0 No, we don'= ;t necessarily have to interop with legacy stuff (though it wouldn't hu= rt).=C2=A0 But we do need a language to talk about X.509 certs, and CSRs ha= ve that.=C2=A0 If we invented something new, we would have to re-do a bunch= of stuff that CSRs already have.

Of course, if we get extensibility= right, we can add a non-CSR option in the future, if people really think t= hey need it.

--Richard

=C2=A0

_______________________________________________
Acme mailing list
Acme@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/acme

--089e015375ba550bac050a57c7ea-- From nobody Tue Dec 16 08:24:11 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096841A1BC4 for ; Tue, 16 Dec 2014 08:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vuv2lrvdw7EC for ; Tue, 16 Dec 2014 08:24:08 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B111A1BA4 for ; Tue, 16 Dec 2014 08:24:08 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so11043382lbv.21 for ; Tue, 16 Dec 2014 08:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Aj9fKABcwjcuxJXg6F0Clp/m0BxC+A8JM5nHFRQEm3M=; b=LZDXEHIUSwG/8zc1QmtWYV00bWUB+5tiLNg1q4uKrSA4ycAkNDmacYN2F9f/Vhgzzz fAzIMfBpn6HVAlVQHqTl76HxSfzQyJfWJOyEhzUeHb5LXQe0RTEVEkSrtu9+PBfB4pdU 7TLWJ/9Oe4MN58h5RMBMnLoJmlemFshm8oHhAgUz6so11hUqRLZRLmO7HG1IJinsGEBy /0I/dYc2N9eoLfMjxCQdrEw36l7+4usoREhMbAEWMxxu2yJpsS8bS3LXy4HUEjoznIwL NQ2GES1MxB07ztD80I+aHoblruJ7QABhMkLCEht7/XwWekjLn25q7Tv4hiMdFth32U6r Z68g== MIME-Version: 1.0 X-Received: by 10.152.219.3 with SMTP id pk3mr36530005lac.19.1418747046707; Tue, 16 Dec 2014 08:24:06 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Tue, 16 Dec 2014 08:24:06 -0800 (PST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F27D@USMBX1.msg.corp.akamai.com> References: <54900F5C.2000809@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F27D@USMBX1.msg.corp.akamai.com> Date: Tue, 16 Dec 2014 11:24:06 -0500 X-Google-Sender-Auth: lJHac2qqYuLcdvEbBOpJmaQH2oE Message-ID: From: Phillip Hallam-Baker To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a113409d4bec9cc050a57c909 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/Wu0QVxiW65bjXKwPCJMCaf3ji_c Cc: "acme@ietf.org" Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:24:10 -0000 --001a113409d4bec9cc050a57c909 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 10:47 AM, Salz, Rich wrote: > > > Since we are going to be generating X.509 certificates, ASN.1 is > inescapable. > > Yes, but not necessarily for anyting other than the certs. > > >There is a lot of machinery that depends on generating CSRs. So support > for CSRs is essential. Duplicating that functionality in JSON does not seem > like a priority to me. > > Agree with first sentence, disagree with the second, and have an open mind > on the third. > > There are many certificate enrollment protcols and data formats already > out there. I don't believe ACME needs to be tied to interop with any of > them. After all, if they were as wildly successful as initially expected, > there wouldn't be need for yet another. > CSR is widely successful, it is used for pretty much 100% of the public certs issued. I am pretty sure there is no actual 'need' for yet another enrollment protocol. We could almost certainly implement automated enrollment by extending one of the existing schemes. The reason it is preferable to move to a new protocol rather than extend the existing ones is that the only part of the protocol that is strongly coupled to the PKIX part is CSR and the cost of making any change to the protocol is almost entirely the cost of QA. So reuse of legacy code isn't much of an issue. Most of the code and hardware out there has been written based on a CSR though. --001a113409d4bec9cc050a57c909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On T= ue, Dec 16, 2014 at 10:47 AM, Salz, Rich <rsalz@akamai.com> w= rote:

> Since we are goin= g to be generating X.509 certificates, ASN.1 is inescapable.

Yes, but not necessarily for anyting other than the certs.

>There is a lot of machinery that depends on generating CSRs. So support= for CSRs is essential. Duplicating that functionality in JSON does not see= m like a priority to me.

Agree with first sentence, disagree with the second, and have an ope= n mind on the third.

There are many certificate enrollment protcols and data formats already out= there.=C2=A0 I don't believe ACME needs to be tied to interop with any= of them. After all, if they were as wildly successful as initially expecte= d, there wouldn't be need for yet another.

CSR is widely successful, it is used for pretty much 100% of the pu= blic certs issued.

I am pretty sure there is no ac= tual 'need' for yet another enrollment protocol. We could almost ce= rtainly implement automated enrollment by extending one of the existing sch= emes.

The reason it is preferable to move to a new= protocol rather than extend the existing ones is that the only part of the= protocol that is strongly coupled to the PKIX part is CSR and the cost of = making any change to the protocol is almost entirely the cost of QA. So reu= se of legacy code isn't much of an issue.

Most= of the code and hardware out there has been written based on a CSR though.=

=C2=A0

--001a113409d4bec9cc050a57c909-- From nobody Tue Dec 16 08:27:58 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED681A1BDF for ; Tue, 16 Dec 2014 08:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtOI7vlM4Bon for ; Tue, 16 Dec 2014 08:27:45 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0312C1A1BDB for ; Tue, 16 Dec 2014 08:27:39 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hy4so6595643vcb.29 for ; Tue, 16 Dec 2014 08:27:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TX8baUFQ/XGmsvWiz89pupzG3CazRODvtRNUIkdz0vM=; b=RL2D1RWstkQ8sxKYsGrOc4QKfsYionjkS6ZhcCNFxtlZi/91PooyaGyN8j5K6cTd8b POrAX0TD24B3OL2V10CisFnMfux571VYSlAQScPXzBjgAJFv6DKzlrNL+OLheowVXX/g M36goC4/vCIBXZXHlXCVYaHUXfdpZ7Zq+lH5IATnE1Q60OAqHgoSZQg4Y+wrqg9ToK44 G6z8tDvpjUYFEarcqviCuCEZq/1CpoWaxTgq9PXBHKpsQEl26tp79Xdfirl35tHvEAJ3 oYycZogwW11iVo8Q78bC7/LMOjL5Df/NSXf2pEAnUcU6jorlsBfx33LiVjakB6PWpwSh prkg== X-Gm-Message-State: ALoCoQlupXnw3Wqif3i0j9PhEe1o2qoRhaFqV2YTFjUSMGPyQbcxeqsatiucHFPaEPtmm02vHo0P MIME-Version: 1.0 X-Received: by 10.52.252.3 with SMTP id zo3mr19477284vdc.51.1418747259058; Tue, 16 Dec 2014 08:27:39 -0800 (PST) Received: by 10.31.139.9 with HTTP; Tue, 16 Dec 2014 08:27:39 -0800 (PST) In-Reply-To: <548FF9E3.1020703@gmail.com> References: <548FF9E3.1020703@gmail.com> Date: Tue, 16 Dec 2014 11:27:39 -0500 Message-ID: From: Richard Barnes To: Anders Rundgren Content-Type: multipart/alternative; boundary=001a1133e3b867109a050a57d6cc Archived-At: http://mailarchive.ietf.org/arch/msg/acme/r4-d0uGKfm4Zmiq6C41M7m-9ZVs Cc: "acme@ietf.org" Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:27:49 -0000 --001a1133e3b867109a050a57d6cc Content-Type: text/plain; charset=UTF-8 I think there might be a middle way here. I've been musing about making a "Content-Signature" header that just carries a JWS signature over the payload (no HTTP headers). Since HTTP has to carry the payload bit-exact, there's no c14n nonsense, so this could be much simpler than other HTTP signing proposals. It's sort of like JCS, except that there is actually a guarantee that the payload stays the same ;) That said, if your concern is really human readability, I don't think it's a tragedy to make someone copy/paste into a base64 decoder. On Tue, Dec 16, 2014 at 4:22 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > > When the transition to JWS has been made, human-readable ACME messages like > > { > "type": "certificateRequest", > "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P", > "signature": { > "alg": "RS256", > "nonce": "h5aYpWVkq-xlJh6cpR-3cw", > "sig": "KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ", > "jwk": { > "kty":"RSA", > "e":"AQAB", > "n":"KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ" > } } } > > will rather look like > > { > "payload":"", > "protected":"", > "header":, > "signature":"" > } > > Which apart from being ugly JWS also requires a JSON schema validator (or > similar > mechanism) to work on separate, unpacked parts of the message. > > Although I don't expect this to change, you may (or may not) want to know > that > clear-text JSON signatures (without the complexity of XML DSig), is not > black magic, > you only have to use JSON parsers that doesn't "manipulate" input data: > https://openkeystore.googlecode.com/svn/resources/ > trunk/docs/jcs.html#Sample_Signature > > Cheers > AndersR > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a1133e3b867109a050a57d6cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think there might be a middle way here.=C2=A0 I'= ;ve been musing about making a "Content-Signature" header that ju= st carries a JWS signature over the payload (no HTTP headers).=C2=A0 Since = HTTP has to carry the payload bit-exact, there's no c14n nonsense, so t= his could be much simpler than other HTTP signing proposals.=C2=A0 It's= sort of like JCS, except that there is actually a guarantee that the paylo= ad stays the same ;)

That said, if your concern is = really human readability, I don't think it's a tragedy to make some= one copy/paste into a base64 decoder.

<= br>

On Tue, Dec 16, 2014 at 4:22 AM, Anders Rundg= ren <anders.rundgren.net@gmail.com> wrote:When the transition to JWS has been made, human-re= adable ACME messages like

=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0"type": "certificateRequest",
=C2=A0 =C2=A0 =C2=A0"csr": "5jNudRx6Ye4HzKEqT5...FS6a= KdZeGsysoCo4H9P",
=C2=A0 =C2=A0 =C2=A0"signature": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0"alg": "RS256",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"nonce": "h5aYpWVkq-xlJh6cpR-3cw&= quot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0"sig": "KxITJ0rNlfDMAtfDr8eAw...<= u>fSSoehDFNZKQKzTZPtQ",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"jwk": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"kty":"RSA",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"e":"AQAB",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"n":"KxITJ0rNlfDMAtfDr8eAw= ...fSSoehDFNZKQKzTZPtQ"
=C2=A0 }=C2=A0 }=C2=A0 }

will rather look like

{
=C2=A0 "payload":"<base64>",
=C2=A0 "protected":"<base64>",
=C2=A0 "header":<base64>,
=C2=A0 "signature":"<base64>"
}

Which apart from being ugly JWS also requires a JSON schema validator (or s= imilar
mechanism) to work on separate, unpacked parts of the message.

Although I don't expect this to change, you may (or may not) want to kn= ow that
clear-text JSON signatures (without the complexity of XML DSig), is not bla= ck magic,
you only have to use JSON parsers that doesn't "manipulate" i= nput data:
https://openkeystore.googl= ecode.com/svn/resources/trunk/docs/jcs.html#Sample_Signature<= /a>

Cheers
AndersR

_______________________________________________
Acme mailing list
Acme@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/acme

--001a1133e3b867109a050a57d6cc-- From nobody Tue Dec 16 08:33:47 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081E81A1BED for ; Tue, 16 Dec 2014 08:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yu4I8u8zSa1F for ; Tue, 16 Dec 2014 08:33:43 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27BA1A1BEE for ; Tue, 16 Dec 2014 08:33:42 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id hs14so11657164lab.36 for ; Tue, 16 Dec 2014 08:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=H+tc8eZ3dwbfemep9iWBaRwLb/NEja11q+m0e5wJ7D8=; b=VdcsavlUmBqXuysbNrMwlzxmYdeOLCX+akIUnAEqaZJAfRJx46IHX9Q1dbZFOymvuY F8hrI35I3KCEYNNDCK9pdPWaeQWM6ULj5YtFChFbBI3Fl52/puwCEA1WrNSvWJr3/M/+ zMdUsEiuuhjZTI6euPK5uI6ygvZKsRMhQFG/taYyn5kZXtm6qC3czGaBu8o1ziTNfusS 54icKRdqRqCz5y9uIiauN5yZtRCWrjl33d3AbKitVd3RI3nEcFVmSh0Fgy1w3ljnKA3b 2DU1CYrT6e6TCaUHddNDwQQjmDavr0VJFiHJQTqUfxnX5xWTi5QgZ9fCTJYdVpw32BY2 sKLg== MIME-Version: 1.0 X-Received: by 10.112.131.1 with SMTP id oi1mr28750388lbb.2.1418747621153; Tue, 16 Dec 2014 08:33:41 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Tue, 16 Dec 2014 08:33:41 -0800 (PST) In-Reply-To: References: <54900F5C.2000809@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F27D@USMBX1.msg.corp.akamai.com> Date: Tue, 16 Dec 2014 11:33:41 -0500 X-Google-Sender-Auth: ugx3rw0F9sXTzpMl7RriL53wF7k Message-ID: From: Phillip Hallam-Baker To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7b343106fc2500050a57ebf7 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/EtUd_cwFwY2BenIdbPXIDRsAPwY Cc: "Salz, Rich" , "acme@ietf.org" Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:33:45 -0000 --047d7b343106fc2500050a57ebf7 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 11:23 AM, Richard Barnes wrote: > > > > On Tue, Dec 16, 2014 at 10:47 AM, Salz, Rich wrote: >> >> > Since we are going to be generating X.509 certificates, ASN.1 is >> inescapable. >> >> Yes, but not necessarily for anyting other than the certs. >> >> >There is a lot of machinery that depends on generating CSRs. So support >> for CSRs is essential. Duplicating that functionality in JSON does not seem >> like a priority to me. >> >> Agree with first sentence, disagree with the second, and have an open >> mind on the third. >> >> There are many certificate enrollment protcols and data formats already >> out there. I don't believe ACME needs to be tied to interop with any of >> them. After all, if they were as wildly successful as initially expected, >> there wouldn't be need for yet another. >> > > I'm in sort of the same place as PHB here. No, we don't necessarily have > to interop with legacy stuff (though it wouldn't hurt). But we do need a > language to talk about X.509 certs, and CSRs have that. If we invented > something new, we would have to re-do a bunch of stuff that CSRs already > have. > > Of course, if we get extensibility right, we can add a non-CSR option in > the future, if people really think they need it. > > +1 I want to have as little to do with PKIX as possible. It is a Jenga specification at this point. But there is an issue as to what level of abstraction we want ACME to work at. In the PKIX days it was assumed that the end entity would know what sort of cert it wants and ask for it. These days, I am not sure. Lets say we have a site with twenty hosts, some of which process payments, some do ordinary web stuff, some do email. We are likely to have different certificates in use for the different purposes. Should we be expected to configure the end host to know what flavor of cert to install or is that something that we would want to control centrally? If the objective is encrypt by default, we are going to end up with a lot more hosts with certs and a bigger management issue. I see two approaches possible: 1) The end host specifies the type of cert it needs 2) The end hosts specifies what it wants to do with the cert (i.e. domain name and protocol) and lets the issuer sort out what to do --047d7b343106fc2500050a57ebf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 16, 2014 at 11:23 AM, Richard Barnes <= rlb@ipv.sx> w= rote:

On Tue, Dec = 16, 2014 at 10:47 AM, Salz, Rich <rsalz@akamai.com> wrote:> Since we are going to be generating = X.509 certificates, ASN.1 is inescapable.

Yes, but not necessarily for anyting other than the certs.

>There is a lot of machinery that depends on generating CSRs. So support= for CSRs is essential. Duplicating that functionality in JSON does not see= m like a priority to me.

Agree with first sentence, disagree with the second, and have an ope= n mind on the third.

There are many certificate enrollment protcols and data formats already out= there.=C2=A0 I don't believe ACME needs to be tied to interop with any= of them. After all, if they were as wildly successful as initially expecte= d, there wouldn't be need for yet another.

I'm in sort of the same place as PHB here.=C2=A0 No= , we don't necessarily have to interop with legacy stuff (though it wou= ldn't hurt).=C2=A0 But we do need a language to talk about X.509 certs,= and CSRs have that.=C2=A0 If we invented something new, we would have to r= e-do a bunch of stuff that CSRs already have.

Of course, if we get e= xtensibility right, we can add a non-CSR option in the future, if people re= ally think they need it.
=

= +1

I want to have as little to do with PKIX as pos= sible. It is a Jenga specification at this point.

= But there is an issue as to what level of abstraction we want ACME to work = at. In the PKIX days it was assumed that the end entity would know what sor= t of cert it wants and ask for it. These days, I am not sure.

Lets say we have a site with twenty hosts, some = of which process payments, some do ordinary web stuff, some do email. We ar= e likely to have different certificates in use for the different purposes. = Should we be expected to configure the end host to know what flavor of cert= to install or is that something that we would want to control centrally?

If the objective is encrypt by default, we are goin= g to end up with a lot more hosts with certs and a bigger management issue.=

I see two approaches possible:

1) The end host specifies the type of cert it needs

2) The end hosts specifies what it wants to do with the cert (i.e.= domain name and protocol) and lets the issuer sort out what to do

--047d7b343106fc2500050a57ebf7-- From nobody Tue Dec 16 08:48:23 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482E71A6F1D for ; Tue, 16 Dec 2014 08:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX-cdUcXANDd for ; Tue, 16 Dec 2014 08:48:11 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 73A5A1A6EFE for ; Tue, 16 Dec 2014 08:47:46 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 42B932004F729; Tue, 16 Dec 2014 08:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=JYgJPJ2Ipz1FrM /GFcnm7lsPn0g=; b=e5Ql7CPS0EUV5oLZTnp0TbtvA0vhJn5WGBLk5yABKARzfB 5kCxbQBR3d0x48WRbFb0InmifdJtbo5RXCql7FSImFKDI2m7XzclhW6Mt5a4ubZg hETFx0LePR0Mb8jD18pAXeflwxdscZpU7mta2aBSCJloP7O1TW/l1WZ7ZqJ78= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id D6B872004F706; Tue, 16 Dec 2014 08:47:45 -0800 (PST) Date: Tue, 16 Dec 2014 10:47:45 -0600 From: Nico Williams To: Anders Rundgren Message-ID: <20141216164740.GV3241@localhost> References: <54900F5C.2000809@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54900F5C.2000809@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/acme/AOMjGh0FtHRSO3tk7pP2C-s-3pU Cc: acme@ietf.org Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:48:13 -0000 On Tue, Dec 16, 2014 at 11:54:20AM +0100, Anders Rundgren wrote: > I don't see an absolute necessity continuing with PKCS #10 in a JSON-world: > https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.KeyCreationResponse As long as there's no ambiguity between the thing to be signed as a CSR (in whatever encoding, and of whatever form) and other things to be signed with the same key, a different format than PKCS#10 should be fine. Nico -- From nobody Tue Dec 16 09:05:21 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A949C1A6FB5 for ; Tue, 16 Dec 2014 09:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg_TgqzoxK3W for ; Tue, 16 Dec 2014 09:05:03 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFCB1A1BE3 for ; Tue, 16 Dec 2014 09:05:03 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so12333318lbj.27 for ; Tue, 16 Dec 2014 09:05:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rsBx5wGlXgHgL/DJJjN11vVrR6OIX5tBrEfgWqgGGJk=; b=GQ/ZoTN6sH8rqnmYjNrzFrvj6gr5wPvPzEdERhJdUbO7jQfuN07iOxSN3kCGPFNi+q /Ohz+0Bejp/R+lwHKEiI2Ud4pdnNW2wB6gpNqOhQ8uUU5p7c63EPDcTcUBTdmY7sZir1 PE3FrtyPEQaJypiWDZFnKcP1cw46kkUc+7O6ofJCNNOemVt9KTaMW5Rzamz2i8yqptBU DHhVpq0BJFh2IWfaqbEzRMCvEBfHtquOTBtgciWspW4z8dSvxGb+/v3esFCBWg9If2m5 bPUaNqUXxNGCcSsb1FUfZUxeeVapR2ESfvFPrf6ucVv6iBANOZmF9AtmbvvOCxGS1T7o GXPA== X-Gm-Message-State: ALoCoQl8KK21KZSB1JasvJXMkRhWiI3E3iHkp6Rhipw6Ciht+maVNMC3QswFFFnamVEWNfKlDa55 MIME-Version: 1.0 X-Received: by 10.112.63.99 with SMTP id f3mr36014953lbs.47.1418749501756; Tue, 16 Dec 2014 09:05:01 -0800 (PST) Received: by 10.25.12.215 with HTTP; Tue, 16 Dec 2014 09:05:01 -0800 (PST) In-Reply-To: <20141216164740.GV3241@localhost> References: <54900F5C.2000809@gmail.com> <20141216164740.GV3241@localhost> Date: Tue, 16 Dec 2014 12:05:01 -0500 Message-ID: From: Richard Barnes To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c3d1e813eb88050a585ced Archived-At: http://mailarchive.ietf.org/arch/msg/acme/1srNmxgKr4Uu4py6kgzA9aGtx1g Cc: "acme@ietf.org" , Anders Rundgren Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:05:14 -0000 --001a11c3d1e813eb88050a585ced Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 11:47 AM, Nico Williams wrote: > On Tue, Dec 16, 2014 at 11:54:20AM +0100, Anders Rundgren wrote: > > I don't see an absolute necessity continuing with PKCS #10 in a > JSON-world: > > > https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.KeyCreationResponse > > As long as there's no ambiguity between the thing to be signed as a CSR > (in whatever encoding, and of whatever form) and other things to be > signed with the same key, a different format than PKCS#10 should be > fine. > The challenge is making sure there's no ambiguity. That has pretty much been worked out with PKCS#10. --Richard > > Nico > -- > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a11c3d1e813eb88050a585ced Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 16, 2014 at 11:47 AM, Nico Williams <nic= o@cryptonector.com> wrote:

On Tue, = Dec 16, 2014 at 11:54:20AM +0100, Anders Rundgren wrote:
> I don't see an absolute necessity continuing with PKCS #10 in a JS= ON-world:
> https://openke= ystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.KeyCreat= ionResponse

As long as there's no ambiguity between the thing to be signed a= s a CSR
(in whatever encoding, and of whatever form) and other things to be
signed with the same key, a different format than PKCS#10 should be
fine.

The challenge is making sure ther= e's no ambiguity.=C2=A0 That has pretty much been worked out with PKCS#= 10.

--Richard

=C2=A0

Nico
--

_______________________________________________
Acme mailing list
Acme@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/acme

--001a11c3d1e813eb88050a585ced-- From nobody Tue Dec 16 09:14:05 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1401A1BE0 for ; Tue, 16 Dec 2014 09:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ucp2HSIJQQ0N for ; Tue, 16 Dec 2014 09:13:41 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A520A1A6EFC for ; Tue, 16 Dec 2014 09:12:02 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 64D25350079; Tue, 16 Dec 2014 09:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3pSX+/ZTdxymJy rBtiylXHfInpI=; b=PlZu/dJfvWGqbejLyLpmVKGo+3nHwOHIw2RnS2G82i1boh fBQ4CAt4+kPBxBHKssuitVe9VezmBSnV4ojTGOnmxSTBAfC4wEAAT49Yvr/W2XVJ JKCozYCck/hSrSVXCOjutbxYpINPde4etDv5TbAKpGXnmZun4YI8zt2wtlRPI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 0FEEF350078; Tue, 16 Dec 2014 09:12:01 -0800 (PST) Date: Tue, 16 Dec 2014 11:12:01 -0600 From: Nico Williams To: Richard Barnes Message-ID: <20141216171156.GY3241@localhost> References: <54900F5C.2000809@gmail.com> <20141216164740.GV3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/acme/3Oi38rPeUSITA__pev-DZaQ43f0 Cc: "acme@ietf.org" , Anders Rundgren Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:13:42 -0000 On Tue, Dec 16, 2014 at 12:05:01PM -0500, Richard Barnes wrote: > On Tue, Dec 16, 2014 at 11:47 AM, Nico Williams > wrote: > > On Tue, Dec 16, 2014 at 11:54:20AM +0100, Anders Rundgren wrote: > > > I don't see an absolute necessity continuing with PKCS #10 in a > > JSON-world: > > > > > https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.KeyCreationResponse > > > > As long as there's no ambiguity between the thing to be signed as a CSR > > (in whatever encoding, and of whatever form) and other things to be > > signed with the same key, a different format than PKCS#10 should be > > fine. > > The challenge is making sure there's no ambiguity. That has pretty much > been worked out with PKCS#10. I didn't say it would be easy. I just stated a constraint on the alternatives. I think this is a strong incentive to stick to PKCS#10, though it's not a foregone conclusion that we must. Nico -- From nobody Tue Dec 16 09:14:06 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235B91A7016 for ; Tue, 16 Dec 2014 09:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlKXyg2E5KeN for ; Tue, 16 Dec 2014 09:13:58 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165AA1A7013 for ; Tue, 16 Dec 2014 09:12:37 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so17985770wgg.19 for ; Tue, 16 Dec 2014 09:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=L3hHNoKzYiul4su9oJrpIqFDs3xxmXpxldKqv85J+kE=; b=l4RO+J9I19ASafkr1YQcg2NRqR7A3uw4M3+exWmMhnipIR2PaYIl8SeH0Zyjynn1AI qk1Q4WBKe0sSWjoGf6P+ZXpVIlwk6au3geTW1VJEea0hwEl28ePgHVyTF3Z6Ar1NoVxI /zAq3aqdPjmbBIpE5nWbIct3VYqU66612B70R0ZkgkzLGNgDQVjNbxm5MAi1WQryHFkV 7IrR097PfJrEjTQUTGXfMFq1FnPPbrGCW8bCxIQm/DMADh6hGJlj9zdvejQBMJNnX1Oe fnMZJHiQwz3B4o/7GWF+XhZ51d5shnPKwmClUXNN73d3HTzQk4f1g7doZXNpyX5XcHoy bhXQ== X-Received: by 10.194.77.142 with SMTP id s14mr65294457wjw.94.1418749955679; Tue, 16 Dec 2014 09:12:35 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id gs9sm1779273wjc.47.2014.12.16.09.12.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 09:12:34 -0800 (PST) Message-ID: <549067FD.4060307@gmail.com> Date: Tue, 16 Dec 2014 18:12:29 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Richard Barnes , Nico Williams References: <54900F5C.2000809@gmail.com> <20141216164740.GV3241@localhost> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/xf-LuiC4E2bA7ByHj_NmYXaePME Cc: "acme@ietf.org" Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:14:01 -0000 On 2014-12-16 18:05, Richard Barnes wrote: > On Tue, Dec 16, 2014 at 11:47 AM, Nico Williams > wrote: > > On Tue, Dec 16, 2014 at 11:54:20AM +0100, Anders Rundgren wrote: > > I don't see an absolute necessity continuing with PKCS #10 in a JSON-world: > >https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.KeyCreationResponse > > As long as there's no ambiguity between the thing to be signed as a CSR > (in whatever encoding, and of whatever form) and other things to be > signed with the same key, a different format than PKCS#10 should be > fine. > > > The challenge is making sure there's no ambiguity. That has pretty much been worked out with PKCS#10. As I understand quite a lot of CAs out there do not use anything but the public key + proof of a CSR and take the "information" from other sources. If this applies to ACME I don't know since I haven't fully digested the process model yet. FWIW, the the FIDO/Google folks didn't reuse anything but X.509 in their JSON-based U2F stuff. I found it trivial creating the CSR for SKS/KeyGen2. Anders > > --Richard > > > Nico > -- > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Tue Dec 16 10:39:59 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097871A86EC for ; Tue, 16 Dec 2014 10:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3BavIJt8Ocu for ; Tue, 16 Dec 2014 10:39:56 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93421A86FC for ; Tue, 16 Dec 2014 10:39:54 -0800 (PST) Received: from [10.20.30.90] (50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBGIdrpJ049886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 11:39:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 $1993$) From: Paul Hoffman In-Reply-To: Date: Tue, 16 Dec 2014 10:39:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54900F5C.2000809@gmail.com> <20141216164740.GV3241@localhost> To: Richard Barnes X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/acme/-gTHPT5NFPl_6Po-LFGByybSer8 Cc: "acme@ietf.org" Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:39:58 -0000 On Dec 16, 2014, at 9:05 AM, Richard Barnes wrote: > The challenge is making sure there's no ambiguity. That has pretty = much been worked out with PKCS#10. No, no it hasn't. There is little agreement about which fields in a CSR = should appear in the issued cert, which fields in the issued cert that = the CA can add, and which fields from the CSR that the CA can change in = the cert. Enrollment protocols that use CSRs handwave. They also don't negotiate the above. If your CSR has two identities and = three key usages in it, and you can show proof of possession for both = identities at all three usages, but the CA issues a cert with just one = of each, should you have to pay for that cert? It would have been nice = if the CA could say "Given that CSR, I'm going to issue this cert, do = you agree?". --Paul Hoffman= From nobody Tue Dec 16 10:48:56 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8165A1ACDC7 for ; Tue, 16 Dec 2014 10:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szebaAEhUMoj for ; Tue, 16 Dec 2014 10:48:53 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1696F1A6EFF for ; Tue, 16 Dec 2014 10:48:53 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so11404184lbv.14 for ; Tue, 16 Dec 2014 10:48:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BO2pS/eb2SMOhnz7w6An0VR6++g3wP92U5m3f03UYoA=; b=Xa2jO+9sYtuIxvh+7RtcglDSGKqIyDuJ5eyxeArlLSco/J1kWBf08ZbUwcZFSaQBjA idqb2/0Y8vvmuLy20ewXQ51mRQGl6PYwG2nSzBhHlnZt0PkjT6DJvzXiDEg/V7yDQu6z zYH2SoMN4cWWPs/N+GxHP8LwSc2ssRpmdqzH7deP3Wv+51qmTbSp8zVh7/6ZVcoZCLdk 8MaxH6cgebZ4OYVLxb3dFAuK0JZ25ErxxQCoaAVtMAAOrWnjOVvoXJsBCP8cmY2aquG0 UeH8Ud2zQ6+0YlCeGB7R99uPg+GoU5vsSsD/VBAj8d1Neoc7mLP4iQml0HdIXSPnekYK 4ytA== X-Gm-Message-State: ALoCoQnyNPB+muBb2ylrVLIWSN2zHz9Zectg2YO8usqzC9Rjnn1jzvkuX/4OnnRcAzXt2JdoKtep MIME-Version: 1.0 X-Received: by 10.112.63.99 with SMTP id f3mr36463155lbs.47.1418755731568; Tue, 16 Dec 2014 10:48:51 -0800 (PST) Received: by 10.25.12.215 with HTTP; Tue, 16 Dec 2014 10:48:51 -0800 (PST) In-Reply-To: References: <54900F5C.2000809@gmail.com> <20141216164740.GV3241@localhost>

Date: Tue, 16 Dec 2014 13:48:51 -0500 Message-ID: From: Richard Barnes To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c3d1e86764e4050a59cfe7 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/A3jUEQsg_j39kU7gGhqRmdWAvik Cc: "acme@ietf.org" Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:48:55 -0000 --001a11c3d1e86764e4050a59cfe7 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 1:39 PM, Paul Hoffman wrote: > On Dec 16, 2014, at 9:05 AM, Richard Barnes wrote: > > The challenge is making sure there's no ambiguity. That has pretty much > been worked out with PKCS#10. > > No, no it hasn't. There is little agreement about which fields in a CSR > should appear in the issued cert, which fields in the issued cert that the > CA can add, and which fields from the CSR that the CA can change in the > cert. Enrollment protocols that use CSRs handwave. > > They also don't negotiate the above. If your CSR has two identities and > three key usages in it, and you can show proof of possession for both > identities at all three usages, but the CA issues a cert with just one of > each, should you have to pay for that cert? It would have been nice if the > CA could say "Given that CSR, I'm going to issue this cert, do you agree?". > Fair enough. It seems pretty doubtful that you're ever going to get much resolution on this negotiation, since ultimately, the CA gets to do what it wants*. At least CSR has a clear syntax for talking about these things. Trying to build a full negotiation protocol seems like an infinite well of complexity. In the context of ACME, which is oriented around name validation, it seems like you could solve it partially. For example, you could say that the CA is expected to issue a certificate that contains SANs for all names from the CSR for which the client has proved possession. And probably draw some boxes around subject/issuer/validity with regard to which ones the CA needs to respect and which the client should assume the CA will change. It only really gets fiddly when you start talking about key usages and other extensions, which are secondary to the authentication function of the cert, and honestly probably inappropriate for most ACME contexts. If my only relationship to you is that you proved possession of example.com, how should I decide what uses I grant you over that domain? Seems very CA-specific. --Richard > > --Paul Hoffman --001a11c3d1e86764e4050a59cfe7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 16, 2014 at 1:39 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:

On Dec 16, 2014, at 9:05 AM, Richard Barnes <rlb@ipv.sx> wro= te:
> The challenge is making sure there's no ambiguity.=C2=A0 That has = pretty much been worked out with PKCS#10.

No, no it hasn't. There is little agreement about which fields i= n a CSR should appear in the issued cert, which fields in the issued cert t= hat the CA can add, and which fields from the CSR that the CA can change in= the cert. Enrollment protocols that use CSRs handwave.

They also don't negotiate the above. If your CSR has two identities and= three key usages in it, and you can show proof of possession for both iden= tities at all three usages, but the CA issues a cert with just one of each,= should you have to pay for that cert? It would have been nice if the CA co= uld say "Given that CSR, I'm going to issue this cert, do you agre= e?".

Fair enough. It seems pretty = doubtful that you're ever going to get much resolution on this negotiat= ion, since ultimately, the CA gets to do what it wants*.=C2=A0=C2=A0 At lea= st CSR has a clear syntax for talking about these things.=C2=A0

Try= ing to build a full negotiation protocol seems like an infinite well of com= plexity.=C2=A0 In the context of ACME, which is oriented around name valida= tion, it seems like you could solve it partially.=C2=A0 For example, you co= uld say that the CA is expected to issue a certificate that contains SANs f= or all names from the CSR for which the client has proved possession.=C2=A0= And probably draw some boxes around subject/issuer/validity with regard to= which ones the CA needs to respect and which the client should assume the = CA will change.=C2=A0

It only really gets fiddly when you start tal= king about key usages and other extensions, which are secondary to the auth= entication function of the cert, and honestly probably inappropriate for mo= st ACME contexts.=C2=A0 If my only relationship to you is that you proved p= ossession of example.com, how should I d= ecide what uses I grant you over that domain?=C2=A0 Seems very CA-specific.=

--Richard

=C2=A0

--Paul Hoffman

--001a11c3d1e86764e4050a59cfe7-- From nobody Tue Dec 16 11:12:17 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152531A1B99 for ; Tue, 16 Dec 2014 11:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2HGfMCFPFfc for ; Tue, 16 Dec 2014 11:12:13 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5371ACD95 for ; Tue, 16 Dec 2014 11:12:13 -0800 (PST) Received: from [10.20.30.90] (50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBGJCBoc053601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 12:12:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 $1993$) From: Paul Hoffman In-Reply-To: Date: Tue, 16 Dec 2014 11:12:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7EFE41CA-5976-4FF6-8A71-874733890DCC@vpnc.org> References: <54900F5C.2000809@gmail.com> <20141216164740.GV3241@localhost>

To: Richard Barnes X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/acme/lMQQdqQlpzcxfwKnEB73zlJbGkc Cc: "acme@ietf.org" Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:12:15 -0000 On Dec 16, 2014, at 10:48 AM, Richard Barnes wrote: > On Tue, Dec 16, 2014 at 1:39 PM, Paul Hoffman = wrote: > On Dec 16, 2014, at 9:05 AM, Richard Barnes wrote: > > The challenge is making sure there's no ambiguity. That has pretty = much been worked out with PKCS#10. >=20 > No, no it hasn't. There is little agreement about which fields in a = CSR should appear in the issued cert, which fields in the issued cert = that the CA can add, and which fields from the CSR that the CA can = change in the cert. Enrollment protocols that use CSRs handwave. >=20 > They also don't negotiate the above. If your CSR has two identities = and three key usages in it, and you can show proof of possession for = both identities at all three usages, but the CA issues a cert with just = one of each, should you have to pay for that cert? It would have been = nice if the CA could say "Given that CSR, I'm going to issue this cert, = do you agree?". >=20 > Fair enough. It seems pretty doubtful that you're ever going to get = much resolution on this negotiation, since ultimately, the CA gets to do = what it wants*. Disagree. It wants to be paid and it wants your repeat business. If our = enrollment protocol doesn't build that, you'll have a bunch of = pissed-off customers. > At least CSR has a clear syntax for talking about these things. =20 No, it really doesn't. In today's CSR, there is no way to say "I would = like a cert for this set of things, but I won't accept one that doesn't = at least have this set of things". It also does not have a clear way of = indicating wildcards in identities: that is done by vague mutual = agreement. I understand the desire not to do the hard work here. It's fine to say = "we can live with CSRs", but not fine to say that the do things well = that we know they don't. > Trying to build a full negotiation protocol seems like an infinite = well of complexity. Not to some of us. > In the context of ACME, which is oriented around name validation, it = seems like you could solve it partially. For example, you could say = that the CA is expected to issue a certificate that contains SANs for = all names from the CSR for which the client has proved possession. =20 That seems fine as long as a response with no cert can also say "I = didn't issue the cert because I could not validate name X which you = asked for" and "I didn't issue the cert because you asked for too many = names". > And probably draw some boxes around subject/issuer/validity with = regard to which ones the CA needs to respect and which the client should = assume the CA will change. That is good, but not enough. Expectations about key usage turns out to = be a huge problem. The location of the subject in the cert (subject vs. = subjectAltName) is a huge issue. The format of some of the subjects = (FQDN vs. DC for domain names) is a a huge issue. > It only really gets fiddly when you start talking about key usages and = other extensions, which are secondary to the authentication function of = the cert, and honestly probably inappropriate for most ACME contexts. =20= Fully disagree: they are not "secondary" at all, certainly not for PKIX.=20= > If my only relationship to you is that you proved possession of = example.com, how should I decide what uses I grant you over that domain? = Seems very CA-specific. That would be fine in a protocol that was not trying to include payment, = but I thought ACME was going to try that (and I think it should).=20 Please don't undershoot here. The sooner we start to deal with all the = issues CSRs have, and enrollment has, the sooner we can be sure which = bits we don't want to do. Assuming from the beginning that we are going = to do some under-specified minimum is not a good way to design a = protocol that we hope will have a huge impact on the security of the = web. --Paul Hoffman= From nobody Tue Dec 16 11:49:01 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457931A8752 for ; Tue, 16 Dec 2014 11:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHcXJTdejhld for ; Tue, 16 Dec 2014 11:48:53 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187701A8750 for ; Tue, 16 Dec 2014 11:48:52 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so11271858lbd.20 for ; Tue, 16 Dec 2014 11:48:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=A0JVpm1JGsMo/0KsCXDLd7v6CGmUi/4quqG7+TYZYgE=; b=OXTzSn+LD25C/WAEq55v7jnkFROj+KEjoWQT0CBHGT7dKyuhs3eCj2xQO8E5NiNMB5 ckXOZ5OSwrIcddLAzquRNZuQkSfxqCb+LE/g3RjHrzA0O9kdFcIKb57MxbsAK4cNOs3z CZAU1p+pUhDjyhqdxjcXCKNiTo9JrrUjzBAVPNOXBTqGwrifxcxbqEec5NvxJdv1wNZq ic+T4zphSJMqWexqFX8WLn+nyqQHX4/iNqlKWYz0A+lyAXaTQzupb9yNa5NJ8Ou1j3qc G4ZgKNGEFdXB6Ka5SuHsfNvlKhshv6bx6J1SAMDsxmXdTv46a/SRilhiJ4i3OvpiL23X ojvQ== X-Gm-Message-State: ALoCoQlXKXv9g03KG+iLKhAszAZMu/GaZp/uPFqBrt1V7wmwmNYD+9bQufqZMvEdtdDo0kmu4BBM MIME-Version: 1.0 X-Received: by 10.112.101.100 with SMTP id ff4mr37029955lbb.94.1418759330441; Tue, 16 Dec 2014 11:48:50 -0800 (PST) Received: by 10.25.12.215 with HTTP; Tue, 16 Dec 2014 11:48:50 -0800 (PST) In-Reply-To: <7EFE41CA-5976-4FF6-8A71-874733890DCC@vpnc.org> References: <54900F5C.2000809@gmail.com> <20141216164740.GV3241@localhost>

<7EFE41CA-5976-4FF6-8A71-874733890DCC@vpnc.org> Date: Tue, 16 Dec 2014 14:48:50 -0500 Message-ID: From: Richard Barnes To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1135e298e9c87f050a5aa56a Archived-At: http://mailarchive.ietf.org/arch/msg/acme/Q9KAxYW7S1ooNET11dPGY-XGKA0 Cc: "acme@ietf.org" Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:48:57 -0000 --001a1135e298e9c87f050a5aa56a Content-Type: text/plain; charset=UTF-8 Please do not get hung up on payment. ACME should support certificate issuance where payment is involved, but that does not have an architectural impact on the protocol. Payment is by nature out of band (since there's no standard for it), and most of the things you're asserting are necessary due to payment are really just, "the client should be able to know what the CA is going to issue". Happy to discuss on those technical grounds. As for undershooting: We should also not overshoot, by biting off more complexity than the baseline requires. The phrase Minimum Viable Product comes to mind. Let's start simple, with hooks to get more complex as needed. If we really want some sort of negotiation system, I would propose something like the following: 0. It is assumed that an ACME-enabled CA will issue certificates for names validated with ACME. 1. Spec defines the semantic of a CSR in the context of ACME: * Body of the certificate partly up to CA * SAN contains only identifiers authorized with CA * Other extensions in CSR must be directly copied to cert 2. If CSR is unacceptable with those rules, CA rejects request 3. CA rejection message can carry a description of what extensions is willing to issue for this cert body (~= set of identifiers) That way, you can build very basic CAs that do no negotiation (e.g., allow whatever CSR requests, allow a specific profile), or the CA can choose to negotiate. From a spec perspective, we can start with the basic, "reject if you don't like it" version, with a basic "i don't like it because" syntax, then elaborate more on the "what i would like" format later. --Richard On Tue, Dec 16, 2014 at 2:12 PM, Paul Hoffman wrote: > > On Dec 16, 2014, at 10:48 AM, Richard Barnes wrote: > > On Tue, Dec 16, 2014 at 1:39 PM, Paul Hoffman > wrote: > > On Dec 16, 2014, at 9:05 AM, Richard Barnes wrote: > > > The challenge is making sure there's no ambiguity. That has pretty > much been worked out with PKCS#10. > > > > No, no it hasn't. There is little agreement about which fields in a CSR > should appear in the issued cert, which fields in the issued cert that the > CA can add, and which fields from the CSR that the CA can change in the > cert. Enrollment protocols that use CSRs handwave. > > > > They also don't negotiate the above. If your CSR has two identities and > three key usages in it, and you can show proof of possession for both > identities at all three usages, but the CA issues a cert with just one of > each, should you have to pay for that cert? It would have been nice if the > CA could say "Given that CSR, I'm going to issue this cert, do you agree?". > > > > Fair enough. It seems pretty doubtful that you're ever going to get much > resolution on this negotiation, since ultimately, the CA gets to do what it > wants*. > > Disagree. It wants to be paid and it wants your repeat business. If our > enrollment protocol doesn't build that, you'll have a bunch of pissed-off > customers. > > > At least CSR has a clear syntax for talking about these things. > > No, it really doesn't. In today's CSR, there is no way to say "I would > like a cert for this set of things, but I won't accept one that doesn't at > least have this set of things". It also does not have a clear way of > indicating wildcards in identities: that is done by vague mutual agreement. > > I understand the desire not to do the hard work here. It's fine to say "we > can live with CSRs", but not fine to say that the do things well that we > know they don't. > > > Trying to build a full negotiation protocol seems like an infinite well > of complexity. > > Not to some of us. > > > In the context of ACME, which is oriented around name validation, it > seems like you could solve it partially. For example, you could say that > the CA is expected to issue a certificate that contains SANs for all names > from the CSR for which the client has proved possession. > > That seems fine as long as a response with no cert can also say "I didn't > issue the cert because I could not validate name X which you asked for" and > "I didn't issue the cert because you asked for too many names". > > > And probably draw some boxes around subject/issuer/validity with regard > to which ones the CA needs to respect and which the client should assume > the CA will change. > > That is good, but not enough. Expectations about key usage turns out to be > a huge problem. The location of the subject in the cert (subject vs. > subjectAltName) is a huge issue. The format of some of the subjects (FQDN > vs. DC for domain names) is a a huge issue. > > > It only really gets fiddly when you start talking about key usages and > other extensions, which are secondary to the authentication function of the > cert, and honestly probably inappropriate for most ACME contexts. > > Fully disagree: they are not "secondary" at all, certainly not for PKIX. > > > If my only relationship to you is that you proved possession of > example.com, how should I decide what uses I grant you over that domain? > Seems very CA-specific. > > That would be fine in a protocol that was not trying to include payment, > but I thought ACME was going to try that (and I think it should). > > Please don't undershoot here. The sooner we start to deal with all the > issues CSRs have, and enrollment has, the sooner we can be sure which bits > we don't want to do. Assuming from the beginning that we are going to do > some under-specified minimum is not a good way to design a protocol that we > hope will have a huge impact on the security of the web. > > --Paul Hoffman --001a1135e298e9c87f050a5aa56a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Please do not get hung = up on payment.=C2=A0 ACME should support certificate issuance where payment= is involved, but that does not have an architectural impact on the protoco= l.=C2=A0 Payment is by nature out of band (since there's no standard fo= r it), and most of the things you're asserting are necessary due to pay= ment are really just, "the client should be able to know what the CA i= s going to issue".=C2=A0 Happy to discuss on those technical grounds.<= br>

As for undershooting: We should also not overshoot, by bi= ting off more complexity than the baseline requires.=C2=A0 The phrase Minim= um Viable Product comes to mind.=C2=A0 Let's start simple, with hooks t= o get more complex as needed.

If we really want som= e sort of negotiation system, I would propose something like the following:=

0. It is assumed that an ACME-enabled CA will issue certificates = for names validated with ACME.

1. Spec defines the semantic o= f a CSR in the context of ACME:

=C2=A0 * Body of the certificate p= artly up to CA

=C2=A0 * SAN contains only identifiers authori= zed with CA

=C2=A0 * Other extensions in CSR must be directly copi= ed to cert

2. If CSR is unacceptable with those rules, CA rejects = request

3. CA rejection message can carry a description of what e= xtensions is willing to issue for this cert body (~=3D set of identifiers)<= br>

That way, you can build very basic CAs that do no negotiation = (e.g., allow whatever CSR requests, allow a specific profile), or the CA ca= n choose to negotiate.=C2=A0 From a spec perspective, we can start with the= basic, "reject if you don't like it" version, with a basic &= quot;i don't like it because" syntax, then elaborate more on the &= quot;what i would like" format later.

--Richard

On Tue, Dec 16, 2014 at 2:1= 2 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:On Dec 16, 2014, at 10:48 AM, Rich= ard Barnes <rlb@ipv.sx> wrote:
> On Tue, Dec 16, 2014 at 1:39 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On Dec 16, 2014, at 9:05 AM, Richard Barnes <rlb@ipv.sx> wrote:<= br> > > The challenge is making sure there's no ambiguity.=C2=A0 That= has pretty much been worked out with PKCS#10.
>
> No, no it hasn't. There is little agreement about which fields in = a CSR should appear in the issued cert, which fields in the issued cert tha= t the CA can add, and which fields from the CSR that the CA can change in t= he cert. Enrollment protocols that use CSRs handwave.
>
> They also don't negotiate the above. If your CSR has two identitie= s and three key usages in it, and you can show proof of possession for both= identities at all three usages, but the CA issues a cert with just one of = each, should you have to pay for that cert? It would have been nice if the = CA could say "Given that CSR, I'm going to issue this cert, do you= agree?".
>
> Fair enough. It seems pretty doubtful that you're ever going to ge= t much resolution on this negotiation, since ultimately, the CA gets to do = what it wants*.

Disagree. It wants to be paid and it wants your repeat business. If = our enrollment protocol doesn't build that, you'll have a bunch of = pissed-off customers.

>=C2=A0 =C2=A0At least CSR has a clear syntax for talking about these th= ings.

No, it really doesn't. In today's CSR, there is no way to sa= y "I would like a cert for this set of things, but I won't accept = one that doesn't at least have this set of things". It also does n= ot have a clear way of indicating wildcards in identities: that is done by = vague mutual agreement.

I understand the desire not to do the hard work here. It's fine to say = "we can live with CSRs", but not fine to say that the do things w= ell that we know they don't.

> Trying to build a full negotiation protocol seems like an infinite wel= l of complexity.

Not to some of us.

>=C2=A0 In the context of ACME, which is oriented around name validation= , it seems like you could solve it partially.=C2=A0 For example, you could = say that the CA is expected to issue a certificate that contains SANs for a= ll names from the CSR for which the client has proved possession.

That seems fine as long as a response with no cert can also say &quo= t;I didn't issue the cert because I could not validate name X which you= asked for" and "I didn't issue the cert because you asked fo= r too many names".

> And probably draw some boxes around subject/issuer/validity with regar= d to which ones the CA needs to respect and which the client should assume = the CA will change.

That is good, but not enough. Expectations about key usage turns out= to be a huge problem. The location of the subject in the cert (subject vs.= subjectAltName) is a huge issue. The format of some of the subjects (FQDN = vs. DC for domain names) is a a huge issue.

> It only really gets fiddly when you start talking about key usages and= other extensions, which are secondary to the authentication function of th= e cert, and honestly probably inappropriate for most ACME contexts.

Fully disagree: they are not "secondary" at all, certainly= not for PKIX.

> If my only relationship to you is that you proved possession of example.com, how should I de= cide what uses I grant you over that domain?=C2=A0 Seems very CA-specific.<= br>
That would be fine in a protocol that was not trying to include paym= ent, but I thought ACME was going to try that (and I think it should).

Please don't undershoot here. The sooner we start to deal with all the = issues CSRs have, and enrollment has, the sooner we can be sure which bits = we don't want to do. Assuming from the beginning that we are going to d= o some under-specified minimum is not a good way to design a protocol that = we hope will have a huge impact on the security of the web.

--Paul Hoffman

--001a1135e298e9c87f050a5aa56a-- From nobody Tue Dec 16 12:04:34 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73621A875B for ; Tue, 16 Dec 2014 12:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jTVCcMLsML8 for ; Tue, 16 Dec 2014 12:04:32 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 02B981A8752 for ; Tue, 16 Dec 2014 12:04:31 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id B252F584064; Tue, 16 Dec 2014 12:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=xnmx0U2ZQ96iym pIynUBx1QU29I=; b=JQCdEHxUnf2546b1tPfSzhYPb6CFI+2PhsXxpPHKPWxnWy hcDGWA3I6uTbOUmPEKhiClRQuKbO+riKXWoB72XqG1pHs4w85MnRPi9lRhAuL2RH C67WHF8/FSpl/pX/uyFNmMkFkOv957wMvNyUSh7RfrlXhh1bQv2TuKgcbfaYI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 54AA3584059; Tue, 16 Dec 2014 12:04:31 -0800 (PST) Date: Tue, 16 Dec 2014 14:04:30 -0600 From: Nico Williams To: Paul Hoffman Message-ID: <20141216200426.GF3241@localhost> References: <54900F5C.2000809@gmail.com> <20141216164740.GV3241@localhost>

<7EFE41CA-5976-4FF6-8A71-874733890DCC@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7EFE41CA-5976-4FF6-8A71-874733890DCC@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/acme/cRq4p_pTx3IhQW_5OAyoC6J61u0 Cc: Richard Barnes , "acme@ietf.org" Subject: Re: [Acme] CSR in JSON X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 20:04:33 -0000 On Tue, Dec 16, 2014 at 11:12:11AM -0800, Paul Hoffman wrote: > On Dec 16, 2014, at 10:48 AM, Richard Barnes wrote: > > At least CSR has a clear syntax for talking about these things. > > No, it really doesn't. In today's CSR, there is no way to say "I would > like a cert for this set of things, but I won't accept one that > doesn't at least have this set of things". It also does not have a > clear way of indicating wildcards in identities: that is done by vague > mutual agreement. Well now, more attributes can be defined to convey such semantics. It's not easy to deal with though. > > Trying to build a full negotiation protocol seems like an infinite > > well of complexity. > > Not to some of us. We do need to negotiate a variety of things here. > > In the context of ACME, which is oriented around name validation, > > it seems like you could solve it partially. For example, you could > > say that the CA is expected to issue a certificate that contains > > SANs for all names from the CSR for which the client has proved > > possession. > > That seems fine as long as a response with no cert can also say "I > didn't issue the cert because I could not validate name X which you > asked for" and "I didn't issue the cert because you asked for too many > names". Yes, nice error codes (and strings) would be... nice. > > It only really gets fiddly when you start talking about key usages > > and other extensions, which are secondary to the authentication > > function of the cert, and honestly probably inappropriate for most > > ACME contexts. > > Fully disagree: they are not "secondary" at all, certainly not for > PKIX. Well, some of this could be profiled. It depends on how general this protocol needs to be. Ideally I'd like both, a general protocol that has reasonable profiles that make implementation easier for common uses. Nico -- From nobody Tue Dec 16 13:14:48 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4451A876F for ; Tue, 16 Dec 2014 13:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64dDX4z9W5UF for ; Tue, 16 Dec 2014 13:14:43 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509A31A70FD for ; Tue, 16 Dec 2014 13:14:43 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so11534757lbg.5 for ; Tue, 16 Dec 2014 13:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MGu4Sk82fK/+K9w3VlYzmYmWF7idtyZuZK8sZcSPLrk=; b=C378J7SoW80LKNUyncupsCOMat38HUwrl8KWc0mP27jOEawuLcZcdVS0qcgBmJwhTF WTqBxhTt3olNblLUdmaEU/b3PqbtSnFuBw2GuvWuzeP5FrofdME4zcbYbxe6lN2bRcMY WXqVcyPcN9GYZrYszi7V29Pa/xVOMRL8yftIHv0Is5SDAAmc7u1duS06kmmwq7qnfk+j tPMvxpKQ0EWa3v4pUQBT5VAC5bY8b+jfcesSD40kx0U3Al4FR1ooYjTAqlZ3ENNP/k/6 7/oxKj5pT+eDxgv7aYWdVmhMditdUqn/k/ofaVv9xt55jwFkEvqtn9kIvXV1CLXmeyxM LdMw== MIME-Version: 1.0 X-Received: by 10.112.162.226 with SMTP id yd2mr4669405lbb.1.1418764481690; Tue, 16 Dec 2014 13:14:41 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Tue, 16 Dec 2014 13:14:41 -0800 (PST) In-Reply-To: <7EFE41CA-5976-4FF6-8A71-874733890DCC@vpnc.org> References: <54900F5C.2000809@gmail.com> <20141216164740.GV3241@localhost>

<7EFE41CA-5976-4FF6-8A71-874733890DCC@vpnc.org> Date: Tue, 16 Dec 2014 16:14:41 -0500 X-Google-Sender-Auth: FUgi78Wn1m3dPE39l7fAzuVo8Ic Message-ID: From: Phillip Hallam-Baker

--089e0112c86cf38514050a5bd86e-- From nobody Tue Dec 16 20:53:51 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B5A1A1BED for ; Tue, 16 Dec 2014 20:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFAFPZZKBuxq for ; Tue, 16 Dec 2014 20:53:47 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2BE1A1BCF for ; Tue, 16 Dec 2014 20:53:47 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so19268798wgh.16 for ; Tue, 16 Dec 2014 20:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aKb35QcuCSGjc7SduwGuPI7hzs8UpKfSz6K6hgSo6Es=; b=XXEWqU9EdAdbRDJ6653kkCqaVYOxD6MQxhGZ/e6mD5Ove5LXocA/vvwcCRBwbL5sGk oRo0IhKWuecwyM7b3KPYq47QmWE7Vdpd/Fvy/+yqkab+7hRm2mh0zYgWUYydLQhZ6q+N 0+vWXMkBZV8YZ1TFLMmN6UvnjRcJ5hbCaInLYwVkCyniyvTcA3R2fRYbLSrX2A/OXwI7 aBu4zd2MDf3zkr/CvPBccXkcFAI3ePyNLaIy5574DL346xIQ3J5mVOGQqq1lf10x0I1Q Of2bjU1QE/bEczoNEVcO/gShFdwPb1TafEpcmrmJ/W6KJ4/aXaxWgW4kJcefmEN8Z6+2 STJw== X-Received: by 10.180.20.106 with SMTP id m10mr10614860wie.1.1418792026243; Tue, 16 Dec 2014 20:53:46 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id t6sm3514927wjf.49.2014.12.16.20.53.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 20:53:45 -0800 (PST) Message-ID: <54910C53.7000107@gmail.com> Date: Wed, 17 Dec 2014 05:53:39 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Richard Barnes References: <548FF9E3.1020703@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/FO2_JoMh_h5voUqQBsN9PKaOIMs Cc: "acme@ietf.org" Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 04:53:50 -0000 On 2014-12-16 17:27, Richard Barnes wrote: > I think there might be a middle way here. I've been musing about making a "Content-Signature" header that just carries a JWS signature over the payload (no HTTP headers). Since HTTP has to carry the payload bit-exact, there's no c14n nonsense, so this could be much simpler than other HTTP signing proposals. It's sort of like JCS, except that there is actually a guarantee that the payload stays the same ;) I see. This looks possible but is also a bit of a hack since such signatures can only be verified in a HTTP context. I would stick to your original JWS transition plan. BTW, JCS does not depend on any c14n nonsense; it only requires that JSON property order is respected by the serializer/deserializer while whitespace is entirely insignificant. You can even verify pretty-printed signatures! > > That said, if your concern is really human readability, I don't think it's a tragedy to make someone copy/paste into a base64 decoder. Human readability happens on several levels from documentation to debugging. That headers and payload are disjunct makes these things slightly less appealing. It also means that you can't make a unified JSON schema for a message object. But it surely isn't a show-stopper :-) For KeyGen2 and my payment related work-items the situation is different since these schemes use multiple and wrapping signatures which JWS doesn't handle in a way that I feel would be acceptable. If the CSR would be rewritten in JSON, ACME would be in a comparable position... Cheers, Anders > > On Tue, Dec 16, 2014 at 4:22 AM, Anders Rundgren > wrote: > > When the transition to JWS has been made, human-readable ACME messages like > > { > "type": "certificateRequest", > "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P", > "signature": { > "alg": "RS256", > "nonce": "h5aYpWVkq-xlJh6cpR-3cw", > "sig": "KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ", > "jwk": { > "kty":"RSA", > "e":"AQAB", > "n":"KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ" > } } } > > will rather look like > > { > "payload":"", > "protected":"", > "header":, > "signature":"" > } > > Which apart from being ugly JWS also requires a JSON schema validator (or similar > mechanism) to work on separate, unpacked parts of the message. > > Although I don't expect this to change, you may (or may not) want to know that > clear-text JSON signatures (without the complexity of XML DSig), is not black magic, > you only have to use JSON parsers that doesn't "manipulate" input data: > https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Sample_Signature > > Cheers > AndersR > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Wed Dec 17 02:07:28 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD931A1BBB for ; Wed, 17 Dec 2014 02:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzx035uxrZ7o for ; Wed, 17 Dec 2014 02:07:26 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337FF1A8788 for ; Wed, 17 Dec 2014 02:07:25 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so15452561wiv.1 for ; Wed, 17 Dec 2014 02:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/gAZR42ZjZwoUNByseU3F+k+y9Pw+tn+RLKPCpXKH/Q=; b=zxy2ty8QYYZpqqQp/0Ar/tic7IXMq2uzzcQs9iWjUYlmf6wp54oagDfI5Z54wWwO9j jCxI3xHnwOSRbln5DtcAgCC+St8Rr5jDqfk7L74TYHqTE7CfF4gZQPyhnfGZBSTFqjBj AhRDJ1WgIFU/PhYUfw/Lk3RwpmbRBzmgO/6BhJaOSi8OuQHroxP/LbBUqDvwfJBDe5g1 UIg+UMOeGUB8e82UAk85jXR7YTtg+PgOb6p6GLDbG7qqfdbty9tzyyoWb/ZQu5Gy3ze/ /n/a8dm5aYDPAwVHrywFJWMm+H5wryz9tElCKXB0Hm31QljVFmUbrFJxfP/cJUV8po9H RKFg== X-Received: by 10.180.88.33 with SMTP id bd1mr12851707wib.10.1418810843946; Wed, 17 Dec 2014 02:07:23 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id 18sm4426994wjr.46.2014.12.17.02.07.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 02:07:23 -0800 (PST) Message-ID: <549155D4.80605@gmail.com> Date: Wed, 17 Dec 2014 11:07:16 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Richard Barnes References: <548FF9E3.1020703@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/Dot8jK_GmFIGSoTZMJnjT8USXPs Cc: "acme@ietf.org" Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 10:07:27 -0000 FWIW, it seems that Python can do JCS with floating point data as the (expected) exception: import json import collections jcs_signed_data = ( '{ ' ' "now": "2014-12-08T10:25:17Z", ' ' "escapeMe": "\\u20ac$\\u000F\\u000aA\'\\u0042\\u0022\\u005c\\\\\\"\\/", ' ' "numbers": [1e0, 4.50, 6], ' ' "signature": ' ' { ' ' "algorithm": "ES256", ' ' "publicKey": ' ' { ' ' "type": "EC", ' ' "curve": "P-256", ' ' "x": "lNxNvAUEE8t7DSQBft93LVSXxKCiVjhbWWfyg023FCk", ' ' "y": "LmTlQxXB3LgZrNLmhOfMaCnDizczC_RfQ6Kx8iNwfFA" ' ' }, ' ' "value": "MEYCIQDGP3HL5aCGaMlgNlqqnPbq-Dhkli4SkfV_ZoGlhGroowIhAPlPhXOsjpPHgQ8E8M-jUQo8lfgO_GRZUJKsg_-u-aJO" ' ' } ' '}' ) jsonObject = json.loads(jcs_signed_data, object_pairs_hook=collections.OrderedDict) parsed_signature = json.dumps(jsonObject,separators=(',',':'),ensure_ascii=False) print parsed_signature #get all but the signature value jsonObject['signature'].pop('value') normalized_result = json.dumps(jsonObject,separators=(',',':'),ensure_ascii=False) print normalized_result expected_result_adjusted_for_FP = ( u'{"now":"2014-12-08T10:25:17Z","escapeMe":"\u20ac$\\u000f\\nA\'B\\"\\\\\\\\\\"/","numbers":[1.0,4.5,6],"signature":' u'{"algorithm":"ES256","publicKey":{"type":"EC","curve":"P-256","x":"lNxNvAUEE8t7DSQBft93LVSXxKCiVjhbWW' u'fyg023FCk","y":"LmTlQxXB3LgZrNLmhOfMaCnDizczC_RfQ6Kx8iNwfFA"}}}' ) print expected_result_adjusted_for_FP == normalized_result From nobody Wed Dec 17 08:04:39 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C457C1A8AE4 for ; Wed, 17 Dec 2014 08:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKicEwQ4Yztx for ; Wed, 17 Dec 2014 08:04:34 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5963B1A8AF3 for ; Wed, 17 Dec 2014 08:04:07 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 354332006D30F; Wed, 17 Dec 2014 08:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=KvKV1eTL+Mpsvw HuCr/AqCN1nAQ=; b=dH/c515OM152QLP8fLBcyOFYJfsMZqjEjIn9MBOKf8FsEt 77WeNZWuMbp5Yx/tJk6VV5p6AHpPU8ow90kUs+YPha9WLahpfSYjqKQl/usO3aLj tsjlhRwsrAD1e7l/0TwelUIda+QTsJxPtQUQkyFukwTPi8C61J9hU0Lz+DBfA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id CA0CA2006D30A; Wed, 17 Dec 2014 08:04:06 -0800 (PST) Date: Wed, 17 Dec 2014 10:04:06 -0600 From: Nico Williams To: Anders Rundgren Message-ID: <20141217160401.GT3241@localhost> References: <548FF9E3.1020703@gmail.com> <54910C53.7000107@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54910C53.7000107@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/acme/_Oxg_zfbSdgDl6p5IACih-LK6R0 Cc: Richard Barnes , "acme@ietf.org" Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 16:04:35 -0000 On Wed, Dec 17, 2014 at 05:53:39AM +0100, Anders Rundgren wrote: > On 2014-12-16 17:27, Richard Barnes wrote: > >I think there might be a middle way here. I've been musing about > >making a "Content-Signature" header that just carries a JWS signature > >over the payload (no HTTP headers). Since HTTP has to carry the > >payload bit-exact, there's no c14n nonsense, so this could be much > >simpler than other HTTP signing proposals. It's sort of like JCS, > >except that there is actually a guarantee that the payload stays the > >same ;) > > [...] > > BTW, JCS does not depend on any c14n nonsense; it only requires that > JSON property order is respected by the serializer/deserializer while > whitespace is entirely insignificant. You can even verify > pretty-printed signatures! You lost me. If whitespace is insignificant, then you must be canonicalizing. Also, I assume you mean object name order by "property order", but this is not required to be preserved by JSON parsers. > >That said, if your concern is really human readability, I don't think > >it's a tragedy to make someone copy/paste into a base64 decoder. I don't either. Nico -- From nobody Wed Dec 17 08:05:49 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571021A8AE4 for ; Wed, 17 Dec 2014 08:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMZ1HY9Ss9sN for ; Wed, 17 Dec 2014 08:05:33 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E8B7F1A8AF0 for ; Wed, 17 Dec 2014 08:05:01 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id C47752C806D; Wed, 17 Dec 2014 08:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=xhZF16Dv8jns9n dhvby8p/6L0I0=; b=mGCkIRf9yF4KkU2riInhkM05thWxTwV3tz0XU71ggSd1AO mwfpIBVZjFBv0xsfMShH2AtqhZSUbQLDuNela5fbvpQ2Y+Fpf8NMtBUo37I6DDHA vcf4wLEL+RSbspXW4nNT/uCW9MvkEKDGqRtPkl1dnGXoQ4dCh5KNl3gklsHTY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 636852C806B; Wed, 17 Dec 2014 08:05:01 -0800 (PST) Date: Wed, 17 Dec 2014 10:05:00 -0600 From: Nico Williams To: Anders Rundgren Message-ID: <20141217160456.GU3241@localhost> References: <548FF9E3.1020703@gmail.com> <549155D4.80605@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <549155D4.80605@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/acme/JTvdsUFHkbsXPmABe8o-l-asRb8 Cc: Richard Barnes , "acme@ietf.org" Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 16:05:43 -0000 On Wed, Dec 17, 2014 at 11:07:16AM +0100, Anders Rundgren wrote: > FWIW, it seems that Python can do JCS with floating point data as the > (expected) exception: JSON parsers are not required to preserve number form. Nico -- From nobody Wed Dec 17 08:38:55 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6A61A8AF5 for ; Wed, 17 Dec 2014 08:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xweo1ezm_kcq for ; Wed, 17 Dec 2014 08:38:51 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EBF1A8AD8 for ; Wed, 17 Dec 2014 08:38:51 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so17572809wib.3 for ; Wed, 17 Dec 2014 08:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JqMxnCSJ11x4Hm1u7VyIh0ShmOyfYMAwsUgGi0D+cWE=; b=idHfcDPZ9NwWNvTIQlyWtj1mNcSAaxanVVFhV9M5J1fbbwNueWaadzhHDRCZlwquC5 lsqD4TfB8T6roE3XnjsqJuQKktiR1laRuo1bLvFgocKTyclXdVAykMF/lwjSmB0vXhkq 7vtobLs/xYSeYns5YSU4cBGdhYIU0JmpFNtRU0x93n/G7MSQYiVTAID4uDSaZilupQE4 adUsUGqAR5wnv2JyKIRf2Nw7UY8BBYy5jKfMBvIZFmeQG0ncrRaNEVbUgLZrzJUx19GL 4wxEpfVEaMtcFm/Yph6rddv6vpVkk3MEO6croAJzhXtRe1I0/cjo7dLDWjib3DCyYkrs kDHQ== X-Received: by 10.180.75.199 with SMTP id e7mr16368140wiw.21.1418834329985; Wed, 17 Dec 2014 08:38:49 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id cz3sm5720300wjb.23.2014.12.17.08.38.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 08:38:49 -0800 (PST) Message-ID: <5491B192.4090208@gmail.com> Date: Wed, 17 Dec 2014 17:38:42 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams References: <548FF9E3.1020703@gmail.com> <549155D4.80605@gmail.com> <20141217160456.GU3241@localhost> In-Reply-To: <20141217160456.GU3241@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/c_MszZ1uF9sUvgGTBiLkcE5DvPg Cc: Richard Barnes , "acme@ietf.org" Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 16:38:53 -0000 On 2014-12-17 17:05, Nico Williams wrote: > On Wed, Dec 17, 2014 at 11:07:16AM +0100, Anders Rundgren wrote: >> FWIW, it seems that Python can do JCS with floating point data as the >> (expected) exception: > > JSON parsers are not required to preserve number form. Correct. That's hardly a problem since many real-world JSON-using applications must anyway "emulate" missing JS number features like big decimals for money and certificate serial numbers for PKI: https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Data_Types Anders > > Nico > From nobody Wed Dec 17 09:02:47 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E0E1A900B for ; Wed, 17 Dec 2014 09:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-5tKngsN7au for ; Wed, 17 Dec 2014 09:02:39 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E441A9028 for ; Wed, 17 Dec 2014 09:02:12 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so12778974lbd.20 for ; Wed, 17 Dec 2014 09:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IbKR9gQPswvC6AaRMM+3MhPOZQPK1Udcix1Xkfa2z+0=; b=0EHm6XS35PYzyOgNI74UPBb0Hjub3W32ljKZPqKWSSSsGKghTNS/as2EXMyd3CdnFm GzBSZs56qQx697SKKUKoNn5OT4OUHJr/2H+UjpIv4iOU38PI9aTMO3z/5Ht7bxwH+/ip hZZuh+HTmujEkrvIqGsweQA3AEy/k6spCtwgZxgWchDEINqx70Cf13H5CSbKyLE+zWwV 6iSYiE04uSr+4i9W3NCnOJh5cjLXB9ZiQNKo5Y+9fgt8ZqQTTHO6ZuNvIrmCxCpYbPPJ svoBN+RVDB35s4m0qNVgKz367a2MgIh622YMmC53IDy+rsLoRL5pLLE7MWezAn49ucF+ t+BA== MIME-Version: 1.0 X-Received: by 10.152.8.225 with SMTP id u1mr40093360laa.21.1418835730925; Wed, 17 Dec 2014 09:02:10 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Wed, 17 Dec 2014 09:02:10 -0800 (PST) In-Reply-To: References: <548FF9E3.1020703@gmail.com> Date: Wed, 17 Dec 2014 12:02:10 -0500 X-Google-Sender-Auth: Joc-ekOMxqJahzcW_GpF3_93C3E Message-ID: From: Phillip Hallam-Baker To: Richard Barnes Content-Type: multipart/alternative; boundary=089e0158b79ebc8ea0050a6c6f93 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/LYzeVYSZ5tS6CxjbQ-b9Ynt-1uU Cc: "acme@ietf.org" , Anders Rundgren Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:02:41 -0000 --089e0158b79ebc8ea0050a6c6f93 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 11:27 AM, Richard Barnes wrote: > > I think there might be a middle way here. I've been musing about making a > "Content-Signature" header that just carries a JWS signature over the > payload (no HTTP headers). Since HTTP has to carry the payload bit-exact, > there's no c14n nonsense, so this could be much simpler than other HTTP > signing proposals. It's sort of like JCS, except that there is actually a > guarantee that the payload stays the same ;) > > That said, if your concern is really human readability, I don't think it's > a tragedy to make someone copy/paste into a base64 decoder. > I do. If we are going to write protocols that can't be easily interpreted in wireline form then why not go binary with JSON-B, CBOR or what have you. I like the idea of using a header like container for the signature. It makes good architectural sense and it is easy to code. A signature is logically meta-data and so it should be expressed as a header. I don't see any value in the 'protected' or 'header' slots. They just confuse the issue. We should have ONE JSON blob that has all the data that we need and sigh that. All the data that is the case shall be signed and any data that is not signed shall be ignored. So the running example would be written thus: Signature: alg=RS256; nonce=h5aYpWVkq-xlJh6cpR-3cw; sig=KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ; KeyID=???TBS { "certificateRequest" : { "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P", } } The "certificateRequest" object contains exactly the sequence of octets that is signed. No moving bits round, no splicing, no complications at all. What is in the signature scope and what is not is clear and unambiguous. The only objection I can see to this approach is that it makes JOSE pretty much redundant. That does leave two open issues to be decided though: 1 Should the signature header be part of the HTTP header or the payload? 2 How to encode the KeyID? I have a marginal preference for making the signature header part of the HTTP header because that is how most Web servers and support libraries are designed to work. They make it really easy to pull data out of a header. On many platforms the RFC822 tag value pairs are automatically mapped to corresponding data structures. There is an argument for making the signature part of the payload though. It is not a HTTP protocol header, it is content metadata and these should have always been kept separate. The second one is a little bit more subtle as we definitely need a way to identify which key is used and I don't like the way it is done in the example because we end up specifying the key twice and relying on some party to check they are the same. There lies the path to tears, weeping and gnashing of teeth. I would rather make the KeyID implicit in the case and require the application to ferret it out from whatever CSR type object it is using. It would be perfectly OK in my view to define a parallel JSON structure to allow an all-JSON certificate issue path as an alternative to PKCS#10. It would also be OK to use a combination of both to allow additional information to be provided. But presenting security critical information through redundant paths without a means of forcing cross checking is a bad plan. --089e0158b79ebc8ea0050a6c6f93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 16, 2014 at 11:27 AM, Richard Barnes <= rlb@ipv.sx> w= rote:

I think there might be a middle= way here.=C2=A0 I've been musing about making a "Content-Signatur= e" header that just carries a JWS signature over the payload (no HTTP = headers).=C2=A0 Since HTTP has to carry the payload bit-exact, there's = no c14n nonsense, so this could be much simpler than other HTTP signing pro= posals.=C2=A0 It's sort of like JCS, except that there is actually a gu= arantee that the payload stays the same ;)

That sai= d, if your concern is really human readability, I don't think it's = a tragedy to make someone copy/paste into a base64 decoder.

I do. If we are going to write protocols that can= 9;t be easily interpreted in wireline form then why not go binary with JSON= -B, CBOR or what have you.

I like the idea of usin= g a header like container for the signature. It makes good architectural se= nse and it is easy to code. A signature is logically meta-data and so it sh= ould be expressed as a header.

I don't see any= value in the 'protected' or 'header' slots. They just conf= use the issue. We should have ONE JSON blob that has all the data that we n= eed and sigh that. All the data that is the case shall be signed and any da= ta that is not signed shall be ignored.

So the run= ning example would be written thus:

Signature:=C2=A0alg=3DRS256;= =C2=A0nonce=3Dh5aYpWVkq= -xlJh6cpR-3cw;=C2=A0sig= =3DKxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ; KeyID=3D???TBS

<= span style=3D"font-size:12.8000001907349px">=C2=A0{=C2=A0"certificateRequest" : {=
=C2=A0 =C2=A0 =C2= =A0"csr": "5jNudRx6Ye4HzKEqT5...FS6aK= dZeGsysoCo4H9P",
=C2=A0 }=C2=A0 } =C2=A0

The=C2=A0"certificateRequest" object con= tains exactly the sequence of octets that is signed. No moving bits round, = no splicing, no complications at all. What is in the signature scope and wh= at is not is clear and unambiguous.

The onl= y objection I can see to this approach is that it makes JOSE pretty much re= dundant.

That does leave two open i= ssues to be decided though:

1 Should the signature= header be part of the HTTP header or the payload?
2 How to encod= e the KeyID?

I have a marginal pref= erence for making the signature header part of the HTTP header because that= is how most Web servers and support libraries are designed to work. They m= ake it really easy to pull data out of a header. On many platforms the RFC8= 22 tag value pairs are automatically mapped to corresponding data structure= s.

There is an argument for making the signature p= art of the payload though. It is not a HTTP protocol header, it is content = metadata and these should have always been kept separate.

The second one is a little bit more subtle as we def= initely need a way to identify which key is used and I don't like the w= ay it is done in the example because we end up specifying the key twice and= relying on some party to check they are the same. There lies the path to t= ears, weeping and gnashing of teeth.

I would rathe= r make the KeyID implicit in the case and require the application to ferret= it out from whatever CSR type object it is using. It would be perfectly OK= in my view to define a parallel JSON structure to allow an all-JSON certif= icate issue path as an alternative to PKCS#10. It would also be OK to use a= combination of both to allow additional information to be provided. But pr= esenting security critical information through redundant paths without a me= ans of forcing cross checking is a bad plan.

--089e0158b79ebc8ea0050a6c6f93-- From nobody Wed Dec 17 09:19:30 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850BC1A1BD7 for ; Wed, 17 Dec 2014 09:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acgdgQVLJBM3 for ; Wed, 17 Dec 2014 09:19:21 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B93561A1BD4 for ; Wed, 17 Dec 2014 09:19:21 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 92AB8200B9999; Wed, 17 Dec 2014 09:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=VWk8RCI+R2XpFk KYUAT7UExnkaU=; b=eEYTMocWDxxG2h8OZexemlOzhB18wYDYOu8hMof3Es8QXT rKo4D4ihPnoani/vjpk25oNzPhmumf7HGCA2D1Fn5qui9YmUwG9LNA5EWOjWACni l1sT+dSRrcr24rBqioMysadhcf98SZH5TYddIF9inUgNcTbqoSQapkHi/y4hQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id 25A7F200B999E; Wed, 17 Dec 2014 09:19:21 -0800 (PST) Date: Wed, 17 Dec 2014 11:19:20 -0600 From: Nico Williams To: Phillip Hallam-Baker Message-ID: <20141217171915.GX3241@localhost> References: <548FF9E3.1020703@gmail.com>

MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/acme/v4pZeMUvRRRzL_nmxjc4w4sy8mU Cc: Richard Barnes , "acme@ietf.org" , Anders Rundgren Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:19:23 -0000 On Wed, Dec 17, 2014 at 12:02:10PM -0500, Phillip Hallam-Baker wrote: > On Tue, Dec 16, 2014 at 11:27 AM, Richard Barnes wrote: > > That said, if your concern is really human readability, I don't think it's > > a tragedy to make someone copy/paste into a base64 decoder. > > I do. If we are going to write protocols that can't be easily interpreted > in wireline form then why not go binary with JSON-B, CBOR or what have you. Well, it does mean having to implement one of those... > I don't see any value in the 'protected' or 'header' slots. They just > confuse the issue. We should have ONE JSON blob that has all the data that > we need and sigh that. All the data that is the case shall be signed and > any data that is not signed shall be ignored. I'd rather have the signature in a JSON text and the signed text encoded as a string in the same text as bears the signature. > The only objection I can see to this approach is that it makes JOSE pretty > much redundant. And that it uses new headers. > That does leave two open issues to be decided though: > > 1 Should the signature header be part of the HTTP header or the payload? The payload. And then you've created a new MIME type. > I have a marginal preference for making the signature header part of the > HTTP header because that is how most Web servers and support libraries are > designed to work. They make it really easy to pull data out of a header. On > many platforms the RFC822 tag value pairs are automatically mapped to > corresponding data structures. I'd rather it be in the payload because then you have less dependence on the transport. E.g., if you're using an IPC mechanism in your server implementation, with a less-privileged front-end passing validated payloads to a more-privileged back-end. > There is an argument for making the signature part of the payload though. > It is not a HTTP protocol header, it is content metadata and these should > have always been kept separate. Exactly. Nico -- From nobody Wed Dec 17 09:27:18 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CE11A1B27 for ; Wed, 17 Dec 2014 09:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLhwcDmVZiUX for ; Wed, 17 Dec 2014 09:27:11 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E961A1F73 for ; Wed, 17 Dec 2014 09:27:10 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so16927978wiv.7 for ; Wed, 17 Dec 2014 09:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2BRV9KmPkxzoLjyXrQxtwUVrMf8i/xppv2IgosEvh5A=; b=u29m/dfwgJA4nV9bdYK9ZzNGCQr596qGHTwDAaRe3FBAIa+Y9nJZq0GGxNPTgSxGX3 MAEOoy8ucLjVprPJp0yac97n+hEaz+m3LrVNc89QVGoc09hzv0X/2CdIomtSXNarb4wi E4SkhA7e1Naa4bzJ1Sa64Sk1p8hZ+qClJitIlohhzyBi7VIm9JjllKGvaDUR+Kc3+/Yd uttxzx237KU/nRb/2vngFAmNzupTd9rBCvaIzSnfjDhn5tdfUNKRPUl+Cb0gIN7uC1NU sn8drCgEHkZYW/V0bLLWyY5DYtOxHv438X1h/mbcUEP65MSDZOeXGb6xOlDC0j0izT/f lFkA== X-Received: by 10.194.63.229 with SMTP id j5mr74654148wjs.23.1418837229281; Wed, 17 Dec 2014 09:27:09 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id w10sm5890202wje.10.2014.12.17.09.27.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 09:27:08 -0800 (PST) Message-ID: <5491BCE5.9010002@gmail.com> Date: Wed, 17 Dec 2014 18:27:01 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams , Phillip Hallam-Baker , Richard Barnes References: <548FF9E3.1020703@gmail.com>

<20141217171915.GX3241@localhost> In-Reply-To: <20141217171915.GX3241@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/6kC6cY_5l0Sk_gNcCELMtxVP1sQ Cc: "acme@ietf.org" Subject: [Acme] Integrated with CSR. Re: ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:27:12 -0000 The "csr" object holds a public key and an associated signature that goes over the public key and a hypothetical attribute. This is a bare-bones CSR. The counter/attestation-signature goes over the entire package. { "type": "certificateRequest", "csr": { "domain": "acme.com", "signature": { "algorithm": "ES256", "publicKey": { "type": "EC", "curve": "P-256", "x": "vlYxD4dtFJOp1_8_QUcieWCW-4KrLMmFL2rpkY1bQDs", "y": "fxEF70yJenP3SPHM9hv-EnvhG6nXr3_S-fDqoj-F6yM" }, "value": "MEUCIF8p4ZY7YGJFaG8X41S-7ZCv...zesjHVc_pUqAa-IcbqefCTR9AvwivtbKA" } }, "signature": { "algorithm": "RS256", "certificatePath": [ "MIIETTCCAjWgAwIBAgIGAUoqo740MA0GCS...s9Zi90RyQ7UzWNrQjoLERGLkuetIw", "MIIFOjCCAyKgAwIBAgIBATANBgkqhkiG9w...O4Zfwjxug_CkeRb2m2sKaBNgCpJig" ], "value": "EmEcktZ2gyG639-vzCf_3b3A6CF8N_...gXLy-zDCUnXVv_P7kqkJlABNgnNRbeLmtFgw" } } From nobody Wed Dec 17 11:53:56 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F61A6FF0 for ; Wed, 17 Dec 2014 11:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29n3X7nnzwm4 for ; Wed, 17 Dec 2014 11:53:49 -0800 (PST) Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B1E1A1B9C for ; Wed, 17 Dec 2014 11:53:49 -0800 (PST) Received: from Den (c-24-17-210-106.hsd1.wa.comcast.net [24.17.210.106]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NGQ00065SLLTE00@mr11p24im-asmtp002.me.com> for acme@ietf.org; Wed, 17 Dec 2014 19:53:48 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-17_06:2014-12-17,2014-12-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1412170192 From: Trevor Freeman To: 'Phillip Hallam-Baker' , 'Richard Barnes' References: <548FF9E3.1020703@gmail.com>

In-reply-to: Date: Wed, 17 Dec 2014 11:53:44 -0800 Message-id: <006c01d01a33$2b086890$811939b0$@icloud.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_006D_01D019F0.1CEA7FC0" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQKP4NJlmAveeRXosKJTRtRnsZde3wH5Z8HOAZKX1t2a+D8cYA== Content-language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/acme/4ZNBjkeFGnBro6iek34WasW_C0E Cc: acme@ietf.org, 'Anders Rundgren' Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:53:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006D_01D019F0.1CEA7FC0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard, =20 There is an alternative to using PKCS#10 as the CSR structure. The ACME = request is using TLS as a transport. You could use the client = certificate portion of TLS to send an X.509 certificate containing the = ACME client public key to the ACME server. All the data the ACME server = needs is in the X.509 structure. You can sign the X.509 certificate = containing the leaf certificate with the authorization public key in the = normal X.509 way. There is just as much X.509 certificate creation code = out there as pkcs#10 creation code so I don=E2=80=99t see that as a big = issue. An upside to this is you also get a meaningful POP in that the = ACME client submitting the request has to use the private key as part of = the TLS negotiation which is a better proof they actually have the = private key. Also all of the ASN.1 structures and the signatures for the = request would be part of the TLS protocol.=20 =20 Trevor =20 From: Acme [mailto:acme-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker Sent: Wednesday, December 17, 2014 9:02 AM To: Richard Barnes Cc: acme@ietf.org; Anders Rundgren Subject: Re: [Acme] ACME signature mechanics =20 =20 =20 On Tue, Dec 16, 2014 at 11:27 AM, Richard Barnes wrote: I think there might be a middle way here. I've been musing about making = a "Content-Signature" header that just carries a JWS signature over the = payload (no HTTP headers). Since HTTP has to carry the payload = bit-exact, there's no c14n nonsense, so this could be much simpler than = other HTTP signing proposals. It's sort of like JCS, except that there = is actually a guarantee that the payload stays the same ;) =20 That said, if your concern is really human readability, I don't think = it's a tragedy to make someone copy/paste into a base64 decoder. =20 I do. If we are going to write protocols that can't be easily = interpreted in wireline form then why not go binary with JSON-B, CBOR or = what have you. =20 I like the idea of using a header like container for the signature. It = makes good architectural sense and it is easy to code. A signature is = logically meta-data and so it should be expressed as a header. =20 I don't see any value in the 'protected' or 'header' slots. They just = confuse the issue. We should have ONE JSON blob that has all the data = that we need and sigh that. All the data that is the case shall be = signed and any data that is not signed shall be ignored. =20 So the running example would be written thus: =20 =20 Signature: alg=3DRS256; nonce=3Dh5aYpWVkq-xlJh6cpR-3cw; = sig=3DKxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ; KeyID=3D???TBS =20 { "certificateRequest" : { "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P", } } =20 =20 The "certificateRequest" object contains exactly the sequence of octets = that is signed. No moving bits round, no splicing, no complications at = all. What is in the signature scope and what is not is clear and = unambiguous. =20 The only objection I can see to this approach is that it makes JOSE = pretty much redundant. =20 =20 That does leave two open issues to be decided though: =20 1 Should the signature header be part of the HTTP header or the payload? 2 How to encode the KeyID? =20 =20 I have a marginal preference for making the signature header part of the = HTTP header because that is how most Web servers and support libraries = are designed to work. They make it really easy to pull data out of a = header. On many platforms the RFC822 tag value pairs are automatically = mapped to corresponding data structures. =20 There is an argument for making the signature part of the payload = though. It is not a HTTP protocol header, it is content metadata and = these should have always been kept separate. =20 =20 The second one is a little bit more subtle as we definitely need a way = to identify which key is used and I don't like the way it is done in the = example because we end up specifying the key twice and relying on some = party to check they are the same. There lies the path to tears, weeping = and gnashing of teeth. =20 I would rather make the KeyID implicit in the case and require the = application to ferret it out from whatever CSR type object it is using. = It would be perfectly OK in my view to define a parallel JSON structure = to allow an all-JSON certificate issue path as an alternative to = PKCS#10. It would also be OK to use a combination of both to allow = additional information to be provided. But presenting security critical = information through redundant paths without a means of forcing cross = checking is a bad plan. ------=_NextPart_000_006D_01D019F0.1CEA7FC0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Richard,

There is an alternative to using PKCS#10 as the CSR structure. The = ACME request is using TLS as a transport. You could use the client = certificate portion of TLS to send an X.509 certificate containing the = ACME client public key to the ACME server. All the data the ACME server = needs is in the X.509 structure. You can sign the X.509 certificate = containing the leaf certificate with the authorization public key in the = normal X.509 way. =C2=A0There is just as much X.509 certificate creation = code out there as pkcs#10 creation code so I don=E2=80=99t see that as a = big issue. An upside to this is you also get a meaningful POP in that = the ACME client submitting the request has to use the private key as = part of the TLS negotiation which is a better proof they actually have = the private key. Also all of the ASN.1 structures and the signatures for = the request would be part of the TLS protocol.

Trevor

From:= = Acme [mailto:acme-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker
Sent: Wednesday, December 17, 2014 9:02 = AM
To: Richard Barnes
Cc: acme@ietf.org; Anders = Rundgren
Subject: Re: [Acme] ACME signature = mechanics

On Tue, = Dec 16, 2014 at 11:27 AM, Richard Barnes <rlb@ipv.sx> = wrote:

I think there might = be a middle way here. I've been musing about making a = "Content-Signature" header that just carries a JWS signature = over the payload (no HTTP headers). Since HTTP has to carry the = payload bit-exact, there's no c14n nonsense, so this could be much = simpler than other HTTP signing proposals. It's sort of like JCS, = except that there is actually a guarantee that the payload stays the = same ;)

That = said, if your concern is really human readability, I don't think it's a = tragedy to make someone copy/paste into a base64 = decoder.

I = do. If we are going to write protocols that can't be easily interpreted = in wireline form then why not go binary with JSON-B, CBOR or what have = you.

I = like the idea of using a header like container for the signature. It = makes good architectural sense and it is easy to code. A signature is = logically meta-data and so it should be expressed as a = header.

I = don't see any value in the 'protected' or 'header' slots. They just = confuse the issue. We should have ONE JSON blob that has all the data = that we need and sigh that. All the data that is the case shall be = signed and any data that is not signed shall be = ignored.

So the running example would be written = thus:

Signature: alg=3DRS256; nonce=3Dh5aYpWVkq-xlJh6cpR-3c= w; sig=3DKxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ; = KeyID=3D???TBS

{ "certificateRequest" : = {

"csr": = "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P",
} = }

The "certificateRequest" object contains = exactly the sequence of octets that is signed. No moving bits round, no = splicing, no complications at all. What is in the signature scope and = what is not is clear and unambiguous.

The only objection I can see to this approach is that = it makes JOSE pretty much redundant.

That does leave two open issues to be decided = though:

1 = Should the signature header be part of the HTTP header or the = payload?

2 How to encode = the KeyID?

I = have a marginal preference for making the signature header part of the = HTTP header because that is how most Web servers and support libraries = are designed to work. They make it really easy to pull data out of a = header. On many platforms the RFC822 tag value pairs are automatically = mapped to corresponding data structures.

There is an argument for making the signature part of = the payload though. It is not a HTTP protocol header, it is content = metadata and these should have always been kept = separate.

The second one is a little bit more subtle as we = definitely need a way to identify which key is used and I don't like the = way it is done in the example because we end up specifying the key twice = and relying on some party to check they are the same. There lies the = path to tears, weeping and gnashing of = teeth.

I = would rather make the KeyID implicit in the case and require the = application to ferret it out from whatever CSR type object it is using. = It would be perfectly OK in my view to define a parallel JSON structure = to allow an all-JSON certificate issue path as an alternative to = PKCS#10. It would also be OK to use a combination of both to allow = additional information to be provided. But presenting security critical = information through redundant paths without a means of forcing cross = checking is a bad = plan.

------=_NextPart_000_006D_01D019F0.1CEA7FC0-- From nobody Wed Dec 17 12:00:29 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116A31A8FD7 for ; Wed, 17 Dec 2014 12:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bprcLcy6grEI for ; Wed, 17 Dec 2014 12:00:16 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB621A8701 for ; Wed, 17 Dec 2014 11:59:57 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id va2so5585233obc.10 for ; Wed, 17 Dec 2014 11:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IGFPSRcd9QT2tdCiGl0disY/X+WnPVMY0nGqUaGgfgg=; b=p9aIwBs8MrEeXsJLY63ZKYYLkqGuRDmY6SJj3MfOkafZV77J2Bear5cWhFsxqc7HM1 e7W1Aejl2eaYDj6P1D/z1wk4cvADjlY/dMYQIainL9tdTfRtyrXnNoJ4S98o6oYZA+xE fsnydN3F4lYuf9G4cup+eQWvXyj92afYiiDaOxpcthxf3EWg2OoS/D6B/CkZiUHLBm6K FhcV2t7u8KHcJ1YlJLCnUuXBC7y3Fp2AH595kwIZoMiLGFv3RDASv/R48OfJ5s+DHS2A FEK/ObWDBKeZAWp3TY2UyvPi+zS6Gxn/ngrpZCf9NH5qJ2OtTPUc8QnQMp72GIvpYGxF iJBA== MIME-Version: 1.0 X-Received: by 10.202.212.82 with SMTP id l79mr25635331oig.12.1418846396279; Wed, 17 Dec 2014 11:59:56 -0800 (PST) Received: by 10.202.49.203 with HTTP; Wed, 17 Dec 2014 11:59:56 -0800 (PST) In-Reply-To: <006c01d01a33$2b086890$811939b0$@icloud.com> References: <548FF9E3.1020703@gmail.com>

<006c01d01a33$2b086890$811939b0$@icloud.com> Date: Wed, 17 Dec 2014 11:59:56 -0800 Message-ID: From: Martin Thomson To: Trevor Freeman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/acme/ULm5Iop5f0SiwAxV_PNh73ehgjI Cc: Richard Barnes , Phillip Hallam-Baker , "acme@ietf.org" , Anders Rundgren

--001a1133b04a43e108050a7cceac-- From nobody Thu Dec 18 04:49:49 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA481A888D for ; Thu, 18 Dec 2014 04:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzw6FsTtgY-K for ; Thu, 18 Dec 2014 04:49:43 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 353CE1A8879 for ; Thu, 18 Dec 2014 04:49:42 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E20BA47621; Thu, 18 Dec 2014 12:49:41 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CB0484761C; Thu, 18 Dec 2014 12:49:41 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 62478202F; Thu, 18 Dec 2014 12:49:41 +0000 (GMT) Received: from usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 18 Dec 2014 07:49:40 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.15]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Thu, 18 Dec 2014 07:49:40 -0500 From: "Salz, Rich" To: Iban Eguia , Josh Aas Date: Thu, 18 Dec 2014 07:49:39 -0500 Thread-Topic: [Acme] ACME and Let's Encrypt Thread-Index: AdAakYS6nyz0lt3IS0yQOmycP3B//gAL2mQg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F844@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/engCqHhbjbfXULeiQ6GT6_nrchA Cc: "acme@ietf.org" Subject: Re: [Acme] ACME and Let's Encrypt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 12:49:45 -0000 PiBob3cgaXMgZ29pbmcgdG8gYmUgdXBkYXRlZCBpZiB0aGVyZSBpcyBhIG1ham9yIGNoYW5nZSBp biB0aGUgZHJhZnQ/IGlzIHRoZXJlIGdvaW5nIHRvIGJlIGEgbmVlZCB0byBiZSBjaGFuZ2luZyB0 aGUgc29mdHdhcmUgYXMgdGhlIGRyYWZ0IGNoYW5nZXM/DQoNClllcy4NCg0KTm8gZGlmZmVyZW50 IHRoYW4gYW55IG90aGVyIHNvZnR3YXJlL3N0YW5kYXJkIGludGVyYWN0aW9uLCBzdWNoIGFzIFRM UyAxLjMsIEhUVFAvMiwgYW5kIHNvIG9uLg0KDQo= From nobody Thu Dec 18 04:57:16 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA731A8891 for ; Thu, 18 Dec 2014 04:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FhIdeZYC5j7 for ; Thu, 18 Dec 2014 04:57:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5901A888D for ; Thu, 18 Dec 2014 04:57:11 -0800 (PST) Received: from [192.168.131.138] ([80.92.123.25]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M03qC-1Xn4Yu1BF6-00uIEB; Thu, 18 Dec 2014 13:57:04 +0100 Message-ID: <5492CF1B.7010508@gmx.net> Date: Thu, 18 Dec 2014 13:56:59 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , Anders Rundgren References: <548FF9E3.1020703@gmail.com>

<006c01d01a33$2b086890$811939b0$@icloud.com> <004901d01a94$55e9ebe0$01bdc3a0$@icloud.com> <54928827.9030009@gmail.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ABs5MMDmX4OaHL1wSqk4BiR9hCoHkvj2e" X-Provags-ID: V03:K0:UJqnHRTA+49lZYT0koe4es9+JkhLdIcSO3Dgz1mR0yjsSjdc8tS 5lInvp5h0MQBLEz2ypIPbQVSoQvc6FDwuP7TSAEWckoVDf47fJacUsmI2/Wx8iWH2+i1ceW 9VpTIGRwgOHICwt3xq/gIcxbRkp/WeZuTMVG/g34zAJZmFoRZj4QbGm1plVnaWwSg4urvvv Ur5jkX+YB0PJ/O7NPnuug== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/acme/PdpLDlXzOY2lrEDPYmO_ULmeuP8 Cc: Richard Barnes , Trevor Freeman , "acme@ietf.org" , Martin Thomson Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 12:57:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ABs5MMDmX4OaHL1wSqk4BiR9hCoHkvj2e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Phillip, this statement caught my attention: On 12/18/2014 01:33 PM, Phillip Hallam-Baker wrote: > Minimal TLS stacks for embedded devices don't typically do client auth.= > See 'minimal'. It depends what devices you are talking about, for what purpose they use TLS/DTLS, and what the overall design pattern of the device is. With the work we are doing in other working groups, such as DICE, we are trying to give guidance on how to use TLS/DTLS for use with Internet of Things (=3Dsmall embedded devices) in an effort to bring more (standardized) security protocols into those devices. With that work we are heavily relying on mutual authentication at the DTLS/TLS level. Ciao Hannes PS: I also don't think that the discussion on this list is relevant to embedded devices. --ABs5MMDmX4OaHL1wSqk4BiR9hCoHkvj2e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUks8cAAoJEGhJURNOOiAt1KkH/iXwo3VfanjVv2aDSO/FTNrs NqSbVQQ9yk3T4nXnB1RwVwtoRj333Ceyi3EWO40yByf7s9oKarpV/Q7saYcdfbTJ eT3IOkdzxHHD3wAFRuOIJi3JA6LxJkZtm+SHa7n25xW+0ltQBDfx9Rep9ZxxzUcQ HhT+QsXNVhiTTVw4T14qMTCoUbWp6fPV/wk7Ic7VMeQNRdTr8zJMBg4MO6Hz3JOY LU9RfkeYZbvjLqpLEdY1224bDYsOoKtvLuwBEGmzVFrHNlDGshnUK6xr+/slwgI0 ZF8da0cTy7D+sFoqWm5qsLDjyp0ywBkmNNxFXRJGehD1uR3jk5QTLr1w5Uprhkc= =pVzz -----END PGP SIGNATURE----- --ABs5MMDmX4OaHL1wSqk4BiR9hCoHkvj2e-- From nobody Thu Dec 18 05:18:06 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645781A88C7 for ; Thu, 18 Dec 2014 05:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRr2-W4WXRkU for ; Thu, 18 Dec 2014 05:17:59 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42A31A88C6 for ; Thu, 18 Dec 2014 05:17:58 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so981637lab.18 for ; Thu, 18 Dec 2014 05:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+USD/3JWpVxk3MXaKEwy0bRvWavkRmi151vTANcrmy8=; b=pGe+AOcPW5iMy6gEyIqZ1sO8xtrBiie3xaZ6oyUotDuZmPxNoacs4T/mptO59j79vo u8qP4RHq0lfoL8Ee93jaczMd+9JJ2ure2Y/vtg4Gjq+Qdz/NSHdG/TjTi0hU3UeBRWnp 2OUNIFa5fifVmvwZ3Q7HWpsRTNVMcjG1r/zxBjisd/23OzM16iypkIsCnwDAAw04k+SI r5ywYlm21mdYf9Ovn+IQNMLjMOdteWlk/j4jVnmJuZnXIHpxvXAP70aI+DfXvLUIC2Rh qWILriOcNSGs0fQXNBiTYTMmVCee5JxcLlnB+C5iNwZtjPveCVpSapMHH0De4AMRfjPY TIgQ== MIME-Version: 1.0 X-Received: by 10.112.119.201 with SMTP id kw9mr2129739lbb.99.1418908677334; Thu, 18 Dec 2014 05:17:57 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Thu, 18 Dec 2014 05:17:57 -0800 (PST) In-Reply-To: <5492CF1B.7010508@gmx.net> References: <548FF9E3.1020703@gmail.com>

<006c01d01a33$2b086890$811939b0$@icloud.com> <004901d01a94$55e9ebe0$01bdc3a0$@icloud.com> <54928827.9030009@gmail.com> <5492CF1B.7010508@gmx.net> Date: Thu, 18 Dec 2014 08:17:57 -0500 X-Google-Sender-Auth: ep9m_E_AsEHZk62z1AxWX5XoPDQ Message-ID: From: Phillip Hallam-Baker To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7bae49daae6b28050a7d6b75 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/weHZLdG4Y6io_wFtPLKVy0ssra0 Cc: Richard Barnes , Trevor Freeman , "acme@ietf.org" , Martin Thomson , Anders Rundgren Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 13:18:05 -0000 --047d7bae49daae6b28050a7d6b75 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 18, 2014 at 7:56 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > > Hi Phillip, > > this statement caught my attention: > > On 12/18/2014 01:33 PM, Phillip Hallam-Baker wrote: > > Minimal TLS stacks for embedded devices don't typically do client auth. > > See 'minimal'. > > It depends what devices you are talking about, for what purpose they use > TLS/DTLS, and what the overall design pattern of the device is. > > With the work we are doing in other working groups, such as DICE, we are > trying to give guidance on how to use TLS/DTLS for use with Internet of > Things (=small embedded devices) in an effort to bring more > (standardized) security protocols into those devices. > > With that work we are heavily relying on mutual authentication at the > DTLS/TLS level. > > Ciao > Hannes > > PS: I also don't think that the discussion on this list is relevant to > embedded devices. > Why not? Support for embedded devices and the cloud is the main forcing function here. We already have mechanisms that support automated certificate management, there are dozens. There is little need for these when a customer only has one cert and no need for standardization unless the customer has multiple CAs which is very rare except for the very largest customers. The best justification for making ACME an IETF standard as opposed to LetsEncrypt going off and doing their own thing like every CA to date is that we want to move to an environment where every device uses TLS all the time. Internet of Things and Cloud computing are the two forcing factors that make a standardized, automated issue scheme essential. I want to be able to unpack my Nest thermostat, plug it in and have it grab a certificate from my local cert issue point as part of the mechanism by which I grant it access to my home network. This is an application layer protocol. It should have authentication at the application layer. The reason TLS client auth isn't very useful is that client authentication is an application layer concern, not a transport layer concern. --047d7bae49daae6b28050a7d6b75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 18, 2014 at 7:56 AM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:

Hi Phil= lip,

this statement caught my attention:

On 12/18/2014 01:33 PM, Phillip Hallam-Baker wrote:
> Minimal TLS stacks for embedded devices don't typically do client = auth.
> See 'minimal'.

It depends what devices you are talking about, for what purpose they= use
TLS/DTLS, and what the overall design pattern of the device is.

With the work we are doing in other working groups, such as DICE, we are trying to give guidance on how to use TLS/DTLS for use with=C2=A0 Internet = of
Things (=3Dsmall embedded devices) in an effort to bring more
(standardized) security protocols into those devices.

With that work we are heavily relying on mutual authentication at the
DTLS/TLS level.

Ciao
Hannes

PS: I also don't think that the discussion on this list is relevant to<= br> embedded devices.

Why not?=C2=A0

<= div>

Support for embedded devices and the cloud is the main f= orcing function here. We already have mechanisms that support automated cer= tificate management, there are dozens. There is little need for these when = a customer only has one cert and no need for standardization unless the cus= tomer has multiple CAs which is very rare except for the very largest custo= mers.

The best justification for making ACME an IE= TF standard as opposed to LetsEncrypt going off and doing their own thing l= ike every CA to date is that we want to move to an environment where every = device uses TLS all the time. Internet of Things and Cloud computing are th= e two forcing factors that make a standardized, automated issue scheme esse= ntial.=C2=A0

I want to be able to u= npack my Nest thermostat, plug it in and have it grab a certificate from my= local cert issue point as part of the mechanism by which I grant it access= to my home network.

This is an application layer = protocol. It should have authentication at the application layer. The reaso= n TLS client auth isn't very useful is that client authentication is an= application layer concern, not a transport layer concern.

--047d7bae49daae6b28050a7d6b75-- From nobody Thu Dec 18 05:23:41 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F351A88AB for ; Thu, 18 Dec 2014 05:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZSLXk-q-B_v for ; Thu, 18 Dec 2014 05:23:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405241A1EFF for ; Thu, 18 Dec 2014 05:23:38 -0800 (PST) Received: from [192.168.131.138] ([80.92.123.25]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M1F72-1Xm04P1eg4-00tCFK; Thu, 18 Dec 2014 14:23:21 +0100 Message-ID: <5492D548.4010709@gmx.net> Date: Thu, 18 Dec 2014 14:23:20 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <548FF9E3.1020703@gmail.com>

--001a11c3f16a0ae989050a7f3f23-- From nobody Thu Dec 18 10:50:42 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658CA1A6FD9 for ; Thu, 18 Dec 2014 10:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7d7WNJaaB7T for ; Thu, 18 Dec 2014 10:50:35 -0800 (PST) Received: from mr11p24im-asmtp001.me.com (mr11p24im-asmtp001.me.com [17.110.78.41]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA481A1B57 for ; Thu, 18 Dec 2014 10:50:35 -0800 (PST) Received: from Den (c-24-17-210-106.hsd1.wa.comcast.net [24.17.210.106]) by mr11p24im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NGS000NDKC76Y10@mr11p24im-asmtp001.me.com> for acme@ietf.org; Thu, 18 Dec 2014 18:50:34 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-18_06:2014-12-18,2014-12-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1412180179 From: Trevor Freeman To: 'Phillip Hallam-Baker' , 'Anders Rundgren' References: <548FF9E3.1020703@gmail.com>

<006c01d01a33$2b086890$811939b0$@icloud.com> <004901d01a94$55e9ebe0$01bdc3a0$@icloud.com> <54928827.9030009@gmail.com> In-reply-to: Date: Thu, 18 Dec 2014 10:50:30 -0800 Message-id: <009d01d01af3$8013a2d0$803ae870$@icloud.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_009E_01D01AB0.71F17440" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQKP4NJlmAveeRXosKJTRtRnsZde3wH5Z8HOAZKX1t0Cmu8+3QIalcPVAimVL9sDJZsK6gG7JfCEmpvBfJA= Content-language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/acme/y00dskosA621L9wiiy8uaGgehXo Cc: 'Richard Barnes' , acme@ietf.org, 'Martin Thomson' Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 18:50:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009E_01D01AB0.71F17440 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Acme [mailto:acme-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker Sent: Thursday, December 18, 2014 4:34 AM To: Anders Rundgren Cc: Richard Barnes; Martin Thomson; acme@ietf.org; Trevor Freeman Subject: Re: [Acme] ACME signature mechanics =20 On Thu, Dec 18, 2014 at 2:54 AM, Anders Rundgren = wrote: Having worked with Europe's EAC (e-passport biometric data protection = PKI), which works as described below, I would strongly recommend NOT using = HTTPS client-certificate authentication because it doesn't fit a normal = installation with an external security-proxy. [TF] Strange, I have worked with similar constraints with cloud based = services and this model worked just fine. =20 =20 =20 +1 =20 Part of the objective here should be to put the end customer in control = by running their own issue point that is a proxy to a CA or another = proxy. Binding the authentication to the transport means that the proof = of possession can only be verified by the proxy which breaks the model. [TF] If you trust the proxy enough to terminal the TLS then you trust it = enough to pass a flag to indicate authentication succeeded Have you considered what value the POP on a pkcs#10 actually delivers? = It does not show the subject submitting the request is the same as the = one in control of the key pair. It just proves to the CA the key pair is = functional.=20 =20 On top of which, it is really yucky to implement. The less time spent = traveling unimplemented, unexplored and un-debugged code paths, the = better. =20 =20 Minimal TLS stacks for embedded devices don't typically do client auth. = See 'minimal'. ------=_NextPart_000_009E_01D01AB0.71F17440 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

From:= = Acme [mailto:acme-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker
Sent: Thursday, December 18, 2014 4:34 = AM
To: Anders Rundgren
Cc: Richard Barnes; Martin = Thomson; acme@ietf.org; Trevor Freeman
Subject: Re: [Acme] = ACME signature mechanics

On Thu, Dec 18, 2014 at 2:54 AM, Anders Rundgren = <anders.rundgren.net@gmail.com> = wrote:

Having worked with Europe's = EAC (e-passport biometric data protection PKI),
which works as = described below, I would strongly recommend NOT using = HTTPS
client-certificate authentication because it doesn't fit a = normal installation
with an external security-proxy.

[TF] Strange, I have worked with similar constraints with cloud based = services and this model worked just = fine.

Part of the objective here should be to put the end = customer in control by running their own issue point that is a proxy to = a CA or another proxy. Binding the authentication to the transport means = that the proof of possession can only be verified by the proxy which = breaks the model.

[TF] If you trust the proxy enough to terminal the TLS then you trust = it enough to pass a flag to indicate authentication = succeeded

Have you considered what value the POP on a pkcs#10 actually = delivers? It does not show the subject submitting the request is the = same as the one in control of the key pair. It just proves to the CA the = key pair is functional.

On top of which, it is really yucky to implement. The = less time spent traveling unimplemented, unexplored and un-debugged code = paths, the better.

Minimal TLS stacks for embedded devices don't = typically do client auth. See = 'minimal'.

------=_NextPart_000_009E_01D01AB0.71F17440-- From nobody Thu Dec 18 11:24:48 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78561A9232 for ; Thu, 18 Dec 2014 11:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4wilnvgv2E7 for ; Thu, 18 Dec 2014 11:24:45 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD991A909E for ; Thu, 18 Dec 2014 11:24:40 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id 10so1556451lbg.1 for ; Thu, 18 Dec 2014 11:24:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pToiWjJBv7aWDZFpaAz2HZnZtr23T4q0l1cRUmPOOok=; b=SjFOx8/WqOXxaxtd9ltRcXTJBnBXXJ1H3gMZqRD1KuqyvDqTf1K5Bn0HDnEHCSBlLy xUadHOOfKkpAsw9QFIW11T6hmm4R4tDMb77aeItL4IG65xqzqwIHS7YUvsOeEXm3paNJ pnmgOxy5uYQwYGU0IH1MzxGqCNRgMR0B7PS+Oq4zv6OtDkym2L/z25HyUzbq0KS5By4e OQWWDOdARzjy73+Eh9CpgnERUTj2gpWgGX6HzGV68XONQ+aT0riXgGRf0+xs5Bo7D6lv aOXOELullKfXINE3WJcnvXYzlynbXH+fRYBlekOR8jr8b9L3AF+q/iLz2OBLuDj8h9wl DuVw== MIME-Version: 1.0 X-Received: by 10.153.11.170 with SMTP id ej10mr3979925lad.24.1418930679122; Thu, 18 Dec 2014 11:24:39 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Thu, 18 Dec 2014 11:24:38 -0800 (PST) In-Reply-To: <009d01d01af3$8013a2d0$803ae870$@icloud.com> References: <548FF9E3.1020703@gmail.com>

<006c01d01a33$2b086890$811939b0$@icloud.com> <004901d01a94$55e9ebe0$01bdc3a0$@icloud.com> <54928827.9030009@gmail.com> <009d01d01af3$8013a2d0$803ae870$@icloud.com> Date: Thu, 18 Dec 2014 14:24:38 -0500 X-Google-Sender-Auth: 3h4TCiINuTTTiNs-q73xglBn6PE Message-ID: From: Phillip Hallam-Baker To: Trevor Freeman Content-Type: multipart/alternative; boundary=001a11347914171370050a828b4c Archived-At: http://mailarchive.ietf.org/arch/msg/acme/KiuhEOrpU9dnApgL7TugCm51Fro Cc: Richard Barnes , "acme@ietf.org" , Martin Thomson , Anders Rundgren Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:24:47 -0000 --001a11347914171370050a828b4c Content-Type: text/plain; charset=UTF-8 On Thu, Dec 18, 2014 at 1:50 PM, Trevor Freeman wrote: > > > > > > Part of the objective here should be to put the end customer in control by > running their own issue point that is a proxy to a CA or another proxy. > Binding the authentication to the transport means that the proof of > possession can only be verified by the proxy which breaks the model. > > *[TF] If you trust the proxy enough to terminal the TLS then you trust it > enough to pass a flag to indicate authentication succeeded* > > *Have you considered what value the POP on a pkcs#10 actually delivers? It > does not show the subject submitting the request is the same as the one in > control of the key pair. It just proves to the CA the key pair is > functional.* > That is really fuzzy argument there Trevor. Who do you mean by 'you'? In my model there are two parties, the CA and the Subscriber. Both can have a proxy but the proxy is trusted by exactly one party. A proxy deployed by the subscriber for their convenience is not going to be trustworthy as far as the CA is concerned for proof of possession purposes. The only circumstance in which the proxy is trusted by both is where they are the same party. And that is not the main application for ACME. If this was a transport layer concern then it would have been added to TLS as an option in 1995. It is an application layer concern, hence the need for an application layer spec. --001a11347914171370050a828b4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 18, 2014 at 1:50 PM, Trevor Freeman <<= a href=3D"mailto:trevor.freeman99@icloud.com" target=3D"_blank">trevor.free= man99@icloud.com> wrote:

=C2=A0
=C2=A0
Part of the objective here should be to put the end customer in control b= y running their own issue point that is a proxy to a CA or another proxy. B= inding the authentication to the transport means that the proof of possessi= on can only be verified by the proxy which breaks the model.<= /p>
[TF] If y= ou trust the proxy enough to terminal the TLS then you trust it enough to p= ass a flag to indicate authentication succeeded
Have you consi= dered what value the POP on a pkcs#10 actually delivers? It does not show t= he subject submitting the request is the same as the one in control of the = key pair. It just proves to the CA the key pair is functional.

Tha= t is really fuzzy argument there Trevor. Who do you mean by 'you'?<= /div>

In my model there are two parties, the CA and the = Subscriber. Both can have a proxy but the proxy is trusted by exactly one p= arty. A proxy deployed by the subscriber for their convenience is not going= to be trustworthy as far as the CA is concerned for proof of possession pu= rposes.

The only circumstance in which the proxy i= s trusted by both is where they are the same party. And that is not the mai= n application for ACME.

If this was= a transport layer concern then it would have been added to TLS as an optio= n in 1995. It is an application layer concern, hence the need for an applic= ation layer spec.

<= /div>

--001a11347914171370050a828b4c-- From nobody Thu Dec 18 11:30:50 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F14A1A9253 for ; Thu, 18 Dec 2014 11:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Kyyz2eDO1QE for ; Thu, 18 Dec 2014 11:30:37 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7FA1A1BD1 for ; Thu, 18 Dec 2014 11:30:37 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so2889046wiv.6 for ; Thu, 18 Dec 2014 11:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=AmcKLgXbAxuo3NU82GpZqiXk+zqF3t/ZueghlTENxSE=; b=URv8hoWXGdYoz8DaBX3hqAIooim/RIR3WDNNevwmwOvAZpt/5W/smkwLxiW4Hut7ij meX5CnW7u6B7RACzmbP9sNhJOSDZHvzfls0HAjNf4j74qO2VVudqQ4TxIOmh29xOw9Nx //O9oFrZSNTsVpVOWCO8XtTZ02+zgFOfBqQcx2sHoh+oetApJyOa6VHdCoMFhj0xQo6t zClBoe9r+uiK97ln7YIHw/DtErjAhP8m+qedkvg1g8uI6ZZ67zFkvALsC1frKBV88Z78 iylxt3C8o4DvO8T8fk3j67Lvaiatz9butDHFlpmn1fVpGZPOITxe7iwhqaxWSFtQWeAV d8yg== X-Received: by 10.180.108.205 with SMTP id hm13mr8292135wib.5.1418931032502; Thu, 18 Dec 2014 11:30:32 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id e7sm10056980wjf.18.2014.12.18.11.30.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 11:30:31 -0800 (PST) Message-ID: <54932B50.8060405@gmail.com> Date: Thu, 18 Dec 2014 20:30:24 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Trevor Freeman , 'Phillip Hallam-Baker' References: <548FF9E3.1020703@gmail.com> <006c01d01a33$2b086890$811939b0$@icloud.com> <004901d01a94$55e9ebe0$01bdc3a0$@icloud.com> <54928827.9030009@gmail.com> <009d01d01af3$8013a2d0$803ae870$@icloud.com> In-Reply-To: <009d01d01af3$8013a2d0$803ae870$@icloud.com> Content-Type: multipart/alternative; boundary="------------040005020402030605050803" Archived-At: http://mailarchive.ietf.org/arch/msg/acme/fAJ-59eBf9Qp8-LTDE-aAP4dJVk Cc: 'Richard Barnes' , acme@ietf.org, 'Martin Thomson' Subject: Re: [Acme] ACME signature mechanics X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:30:48 -0000 This is a multi-part message in MIME format. --------------040005020402030605050803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2014-12-18 19:50, Trevor Freeman wrote: > > *From:*Acme [mailto:acme-bounces@ietf.org] *On Behalf Of *Phillip Hallam-Baker > *Sent:* Thursday, December 18, 2014 4:34 AM > *To:* Anders Rundgren > *Cc:* Richard Barnes; Martin Thomson; acme@ietf.org; Trevor Freeman > *Subject:* Re: [Acme] ACME signature mechanics > > On Thu, Dec 18, 2014 at 2:54 AM, Anders Rundgren > wrote: > > Having worked with Europe's EAC (e-passport biometric data protection PKI), > which works as described below, I would strongly recommend NOT using HTTPS > client-certificate authentication because it doesn't fit a normal installation > with an external security-proxy. > > */[TF] Strange, I have worked with similar constraints with cloud based services and this model worked just fine./* > It is possibly that I didn't completely understood the scenario you described but you also need a trust anchor in the proxy end, don't you? This seems to not work with a CSR unless you already have a certificate. What am I missing here? > *//* > > *//* > > +1 > > Part of the objective here should be to put the end customer in control by running their own issue point that is a proxy to a CA or another proxy. Binding the authentication to the transport means that the proof of possession can only be verified by the proxy which breaks the model. > > */[TF] If you trust the proxy enough to terminal the TLS then you trust it enough to pass a flag to indicate authentication succeeded/* > > */Have you considered what value the POP on a pkcs#10 actually delivers? It does not show the subject submitting the request is the same as the one in control of the key pair. It just proves to the CA the key pair is functional. /* > I agree that the PoP provided by PKCS #10 is essentially useless. I got the impression that AMCE relies on other data to authenticate the request. In the proxy systems I have worked with messages were checked for sanity before transferred to the secure world. Related question: http://www.ietf.org/mail-archive/web/acme/current/msg00143.html Anders > On top of which, it is really yucky to implement. The less time spent traveling unimplemented, unexplored and un-debugged code paths, the better. > > Minimal TLS stacks for embedded devices don't typically do client auth. See 'minimal'. > --------------040005020402030605050803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2014-12-18 19:50, Trevor Freeman wrote:

From: Acme [mailto:acme-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, December 18, 2014 4:34 AM
To: Anders Rundgren
Cc: Richard Barnes; Martin Thomson; acme@ietf.org; Trevor Freeman
Subject: Re: [Acme] ACME signature mechanics

On Thu, Dec 18, 2014 at 2:54 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

Having worked with Europe's EAC (e-passport biometric data protection PKI),
which works as described below, I would strongly recommend NOT using HTTPS
client-certificate authentication because it doesn't fit a normal installation
with an external security-proxy.

[TF] Strange, I have worked with similar constraints with cloud based services and this model worked just fine.

It is possibly that I didn't completely understood the scenario you described but
you also need a trust anchor in the proxy end, don't you? This seems to not work
with a CSR unless you already have a certificate.

What am I missing here?

+1

Part of the objective here should be to put the end customer in control by running their own issue point that is a proxy to a CA or another proxy. Binding the authentication to the transport means that the proof of possession can only be verified by the proxy which breaks the model.

[TF] If you trust the proxy enough to terminal the TLS then you trust it enough to pass a flag to indicate authentication succeeded

Have you considered what value the POP on a pkcs#10 actually delivers? It does not show the subject submitting the request is the same as the one in control of the key pair. It just proves to the CA the key pair is functional.

I agree that the PoP provided by PKCS #10 is essentially useless.
I got the impression that AMCE relies on other data to authenticate the request.

In the proxy systems I have worked with messages were checked for sanity before transferred to the secure world.

Related question:
http://www.ietf.org/mail-archive/web/acme/current/msg00143.html

Anders

On top of which, it is really yucky to implement. The less time spent traveling unimplemented, unexplored and un-debugged code paths, the better.

Minimal TLS stacks for embedded devices don't typically do client auth. See 'minimal'.

--------------040005020402030605050803-- From nobody Thu Dec 18 11:53:28 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461AD1A6F6F for ; Thu, 18 Dec 2014 11:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3xvvNvhFdGU for ; Thu, 18 Dec 2014 11:53:25 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C2C1A1B16 for ; Thu, 18 Dec 2014 11:53:25 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id h136so874643oig.33 for ; Thu, 18 Dec 2014 11:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VXpKXLhPnExhvs39Lswq0HmzKFtxxyxW7HJ0+bbS/uk=; b=JK7pDgGyCEOLr/O2zJse/boZMCy4HQI4i0642OO6pMB0jdRoy/G8HUjKks7Ij+PIQl Nn0pB+SxYwldBk1OvrUtiLqwFkVcHwsgY5QN9b1E0NidBuVt+zFnjl+x38Yt4T8uZMqs 0z06a7/FTO5TdT0zA19WN1n6Ybd1ksyTNZk0fwuyIXwEiUIxo1SDa8Jg6zkoIrH1TTpl K1vVIv0ML/9viWbXEaCObFNc2Xssiw/hPGihg5L74GrR+5tYf5Czh6RZJJyyVA3AcuUX aggTTR81zoCKqXcdoojHYEWHoG2nNLG3/a9RTcaW/A8f1EgN+J5T5n7j0nBkTIwO4vlm NDNQ== MIME-Version: 1.0 X-Received: by 10.60.146.231 with SMTP id tf7mr2449830oeb.48.1418932404347; Thu, 18 Dec 2014 11:53:24 -0800 (PST) Received: by 10.202.49.203 with HTTP; Thu, 18 Dec 2014 11:53:24 -0800 (PST) In-Reply-To: <5492B595.6020605@gmail.com> References: <5492B595.6020605@gmail.com> Date: Thu, 18 Dec 2014 11:53:24 -0800 Message-ID: From: Martin Thomson To: Anders Rundgren Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/N2lsE2Cvpr3TW3ix2P9-gR6-NsY Cc: "acme@ietf.org" Subject: Re: [Acme] Message Type/Version Identifiers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:53:26 -0000 On 18 December 2014 at 03:08, Anders Rundgren wrote: > I have "backported" these things to JSON because I think they were good. A > system like > ACME could also use such a scheme since there will undoubtedly be revisions > over time. I can appreciate the attraction, but this is a big "no" for me. Absence of these features is one of the reasons that JSON has proven successful over XML. If you need versioning at that level, I'd recommend defining a content type instead. From nobody Thu Dec 18 11:55:16 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07411A1B94 for ; Thu, 18 Dec 2014 11:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFCteHSQcSxQ for ; Thu, 18 Dec 2014 11:55:14 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D126F1A6F17 for ; Thu, 18 Dec 2014 11:55:13 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id nt9so5616809obb.5 for ; Thu, 18 Dec 2014 11:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u64PfATBdx79J0cmIYKpNmcGQV43lfJW49Tkq+3hMXQ=; b=N4bPhlf7KA8yTPcLlkGnoD/GZT6viabBrVcdLIRjE6hVJRLjJZNy7SjMdGn3jdDy+K HzKrAQWbWkCFg4Vulpu1WTkXPz8eN8jiS93IMMsK4O33rl5htIHRC1hOkQ/wcDK7jghm LqlBIJChrKH11bP2RJO+xiG68PFKPu2SsQP42IlYfFZ5nXgQg1BUV8dgZb+Bj3n5zh4B Ma0QTi8csXZ3NCkeqM3XDsvaevWL6orO276meAtPt406IK3CiDoUdqkFz1r/ZdjB1MGg DPFBtZHHUEy/aXZXaqucj5rkhaqC86wLzniBEu+nIriXkOzfAQR73IMQfpOBQHtQ6Som nNhg== MIME-Version: 1.0 X-Received: by 10.202.219.198 with SMTP id s189mr2340362oig.72.1418932513140; Thu, 18 Dec 2014 11:55:13 -0800 (PST) Received: by 10.202.49.203 with HTTP; Thu, 18 Dec 2014 11:55:13 -0800 (PST) In-Reply-To: <5492C4AF.3050708@gmail.com> References: <5492C4AF.3050708@gmail.com> Date: Thu, 18 Dec 2014 11:55:13 -0800 Message-ID: From: Martin Thomson To: Anders Rundgren Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/wO7xnfWRH1WtV2kLejF-Oi6mejw Cc: "acme@ietf.org" Subject: Re: [Acme] "authorized key pair" vs CSR keys X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:55:15 -0000 On 18 December 2014 at 04:12, Anders Rundgren wrote: > Does/can the CSR use another key-pair than the "authorized key pair"? > > If not the outer signature seems a bit odd since the CSR itself should > contain a signature. The signature in the CSR isn't enough to bind the CSR to the ACME protocol process. Without that, the information that appears in the ACME context couldn't be properly attributed to the private key owner. From nobody Thu Dec 18 11:58:27 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D681A6F2C for ; Thu, 18 Dec 2014 11:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUP_JgYX06eD for ; Thu, 18 Dec 2014 11:58:24 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095731A3BA9 for ; Thu, 18 Dec 2014 11:58:23 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so3033354wiw.3 for ; Thu, 18 Dec 2014 11:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GwGav/xH9/DueaK5seBQ6r9SAd8wpebM/sRbX2MTMn4=; b=Gl2EGJGZe0bFBT6Mht6/WHpfu9VVxbx+tVpbs4Jaxs+RE2kVwIYgeLTOPES+hxrczJ XQ9LKclPjamkmVdJaBsB+LTlDRs28LcExu81go5QOt+zFt+YjLBKUuYA21uq6hRn5AbB 0js1EPwELnw9sE1JvnzesDJxAuEuyk6ebYZwJZfr4UZWl4OvX6BBcBHxP1y70OMEbLsy /zEWcnzYT9q7IcX4CKPFGj1P/q5QRj9AkD3K3C8wDUqfLKNA2QP1JZncsp7iKJns5wBR j7VH48pj1n2wR55XNdzcfg5e5icMyUBrF/xiUg2o3zwCGzhYCLxC6oQ5UlH9BauWluRR uK+g== X-Received: by 10.180.75.42 with SMTP id z10mr8304386wiv.70.1418932702808; Thu, 18 Dec 2014 11:58:22 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id gy8sm25951984wib.23.2014.12.18.11.58.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 11:58:22 -0800 (PST) Message-ID: <549331D7.7030302@gmail.com> Date: Thu, 18 Dec 2014 20:58:15 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson References: <5492C4AF.3050708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/OmyEawMhNGBkLg-w1Id_nTUNV4E Cc: "acme@ietf.org" Subject: Re: [Acme] "authorized key pair" vs CSR keys X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:58:25 -0000 On 2014-12-18 20:55, Martin Thomson wrote: > On 18 December 2014 at 04:12, Anders Rundgren > wrote: >> Does/can the CSR use another key-pair than the "authorized key pair"? >> >> If not the outer signature seems a bit odd since the CSR itself should >> contain a signature. > > The signature in the CSR isn't enough to bind the CSR to the ACME > protocol process. Without that, the information that appears in the > ACME context couldn't be properly attributed to the private key owner. > The authorized key pair mentioned in the spec is *another* key-pair than used for the CSR? If not, the design appears strange to me at least. Anders From nobody Thu Dec 18 12:04:18 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A3E1A86FB for ; Thu, 18 Dec 2014 12:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU-fsKtSHFph for ; Thu, 18 Dec 2014 12:04:04 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512D21A1B94 for ; Thu, 18 Dec 2014 12:03:07 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so5146148obc.1 for ; Thu, 18 Dec 2014 12:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SW6xikw4Cue2VhKqEYlBui9U91ytpQCUthNz9cTUClg=; b=qCupTr6T4ngGk6ybtZt7tEuL8FjbQcUBYrroHesfI7cnKXiVV7REdRKxFOKq59uQ6X QoxiFnGRU1exesOMSmVSSCodvzJ6c9CFotHfyIaqATbVOTE1qrKBLpO9J4B3k/Wg1f2O 0K2RAZ83gmgW5fqzJuL8Loq8uK29axfy0XE04WExPxOJhTIzavw9gfAAHZx4uQii456D Eo6m5VaB6VWvvvrZlSchIxn8HyzxCjWO9MpJaIbTFlTCs06VsypoHgvsPQNHfEZ2uOgd 0H8kFaklq/GN/NsRr/IMs7G2bxyDQIG/25xu4SmYvlYr04mDet7H722LkJee5wBv9L9z 8frg== MIME-Version: 1.0 X-Received: by 10.60.131.232 with SMTP id op8mr490157oeb.59.1418932986544; Thu, 18 Dec 2014 12:03:06 -0800 (PST) Received: by 10.202.49.203 with HTTP; Thu, 18 Dec 2014 12:03:06 -0800 (PST) In-Reply-To: <549331D7.7030302@gmail.com> References: <5492C4AF.3050708@gmail.com> <549331D7.7030302@gmail.com> Date: Thu, 18 Dec 2014 12:03:06 -0800 Message-ID: From: Martin Thomson To: Anders Rundgren Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/oGChTZs1mLUZc7QbH6H_XdZ8f2E Cc: "acme@ietf.org" Subject: Re: [Acme] "authorized key pair" vs CSR keys X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 20:04:14 -0000 On 18 December 2014 at 11:58, Anders Rundgren wrote: > The authorized key pair mentioned in the spec is *another* key-pair than > used for the CSR? > If not, the design appears strange to me at least. They are the same. From nobody Thu Dec 18 12:08:12 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE061A6F17 for ; Thu, 18 Dec 2014 12:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfEXKbnhP0QE for ; Thu, 18 Dec 2014 12:08:01 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5948C1A1B94 for ; Thu, 18 Dec 2014 12:08:01 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so2614169wgg.28 for ; Thu, 18 Dec 2014 12:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Fbon7NfNCg3OwJzf0SNbpSDAz6uOXia+DAcq07vSmOM=; b=eTIl0X5LQ+idcXBtpPUNWfRSi8V84Skodomsy8ieMHfy6iTZlQKUaEJ7dT8gH3qyIJ oprhYJTjYUJFr+dnk3EI3ACz7z4alx7JzdMyo7JJnciDonFFEDgm2sfCodbz2SuzC68Z lM/a8NmJ5wC1fDgI+DTJkdbPF2a9OdtALN2Xv6e8k1Ph0NveB5/UtkNW+nwNa0qdWFPf BBcEvkyLD2wMRG6RTCxyiImMfX7cXn3v6txR+ThgsoU3LNSYNf6kAG+gJ1/HH3Obkq+a VjbGhjTqnjcC2H9Pjg82JU5B3BVdoMNFjLQvvBY0gOPzj9+mvpp2l3V+JMiafUxw+Ozc kt6A== X-Received: by 10.194.85.197 with SMTP id j5mr7582665wjz.106.1418933279815; Thu, 18 Dec 2014 12:07:59 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id je12sm11176242wic.22.2014.12.18.12.07.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 12:07:59 -0800 (PST) Message-ID: <54933418.6020408@gmail.com> Date: Thu, 18 Dec 2014 21:07:52 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson References: <5492C4AF.3050708@gmail.com> <549331D7.7030302@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/hoeGloUZXYI-0wCGbF2FHfKCe0M Cc: "acme@ietf.org" Subject: Re: [Acme] "authorized key pair" vs CSR keys X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 20:08:09 -0000 On 2014-12-18 21:03, Martin Thomson wrote: > On 18 December 2014 at 11:58, Anders Rundgren > wrote: >> The authorized key pair mentioned in the spec is *another* key-pair than >> used for the CSR? >> If not, the design appears strange to me at least. > > They are the same. Then it is time dropping PKCS #10 and create the CSR that ACME actually needs. Anders From nobody Thu Dec 18 12:11:15 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19FF1A6FC7 for ; Thu, 18 Dec 2014 12:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7p4nbwIqeB0 for ; Thu, 18 Dec 2014 12:11:10 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100B61A1B94 for ; Thu, 18 Dec 2014 12:11:10 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so2618203wgg.19 for ; Thu, 18 Dec 2014 12:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iuCp+Uak6cJA3W9qVItnBVMSPwBHhKZZxCh9zI/LUfY=; b=aW3cXLfRCN1wk/IQD0tX6pa2xUKEmVIATmE44NRzol3ZbEXQxxTBMffLWFLZJAO8KR YGQFFSW3Z5/JOHhk3sTD+Rg762JYHmnpIb35FqBI6mMuVwO0au3NskKoiQUGzNbXJhYI 30DZfHLgIUVCIKXchS9XO8VPyFqgcEf/1vAsVqiTFqbOsI8xw4rfC1eStD6AW4oj/hbI 22QiR8DMzsRLLS2/i2Mmjk4I7J0ZVeSLXzAzWls05oH8sQl61omKqjLpQ8LguqJ4Lc8v YJs2GPt5JBZRg8YNsQD2gLuuhwDbHOI7nHzjB1SwZNulrUp1Fbhjd39jxjes6ja3k3im hX4A== X-Received: by 10.194.61.168 with SMTP id q8mr7588838wjr.53.1418933468125; Thu, 18 Dec 2014 12:11:08 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id ec2sm11182489wib.23.2014.12.18.12.11.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 12:11:07 -0800 (PST) Message-ID: <549334D4.6040204@gmail.com> Date: Thu, 18 Dec 2014 21:11:00 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson References: <5492B595.6020605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/FsgTJuWazUDVyVvqDUkBlKDztNQ Cc: "acme@ietf.org" Subject: Re: [Acme] Message Type/Version Identifiers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 20:11:12 -0000 On 2014-12-18 20:53, Martin Thomson wrote: > On 18 December 2014 at 03:08, Anders Rundgren > wrote: >> I have "backported" these things to JSON because I think they were good. A >> system like >> ACME could also use such a scheme since there will undoubtedly be revisions >> over time. > > I can appreciate the attraction, but this is a big "no" for me. > Absence of these features is one of the reasons that JSON has proven > successful over XML. > > If you need versioning at that level, I'd recommend defining a content > type instead. The ACME folks have their freedom to select, I just found it quite useful: https://openkeystore.googlecode.com/svn/wcpp-payment-demo/trunk/docs/messages.html Anders From nobody Thu Dec 18 12:53:38 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E069A1A8704 for ; Thu, 18 Dec 2014 12:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOALwxYbnXN5 for ; Thu, 18 Dec 2014 12:53:34 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323D71A6FD6 for ; Thu, 18 Dec 2014 12:53:32 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so2830433wib.5 for ; Thu, 18 Dec 2014 12:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=WnecCYgy7q6gCRV1OPEXRzGqLh97HJDxFNTU7FMp+rI=; b=cro/LotJg2387Z3F+CBd+kpcAqvZEAmN3LOLLS7XU7f3QWps1hzxnqHSGb4jTfyNp8 Sz4lvzPIrJFQVJqeoJM8yfuE0CgZWmEVt3DsNVIObnAFjPcFr/KPWA1+AbRF/Ue6y8sL GR+73QrgDjtMcLS3ilksgEaeyxFnNGJGALKi/Q8laGYFSFO9azYuWz4+ANfKJz5UVMxK tCwzQ7Cc4sDIwjhIxn1fo2TNLzUHN8SJs3UGx3lVe7bEmIauYasysASdsqUOg6NNLE2c OC1JYlQAsiauG7NPLVFJdezU0ZhDru2qkLL/Lnenmc12yrcvhBIILoyxxSewdVsqkkwr 5HLw== X-Received: by 10.195.12.35 with SMTP id en3mr8025305wjd.129.1418936011051; Thu, 18 Dec 2014 12:53:31 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id p1sm10287527wjy.22.2014.12.18.12.53.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 12:53:30 -0800 (PST) Message-ID: <54933EC2.3010104@gmail.com> Date: Thu, 18 Dec 2014 21:53:22 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "acme@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/iJiS_gNF0m3zj11-rv5OlLAbnK0 Subject: [Acme] key agility? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 20:53:37 -0000 With a multi-step protocol some kind of key agility should be possible to support. The client could for example start with telling its preferences/capabilities. Anders From nobody Thu Dec 18 13:43:51 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCC01A8877 for ; Thu, 18 Dec 2014 13:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oShLPCB0eBox for ; Thu, 18 Dec 2014 13:43:49 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603641A8774 for ; Thu, 18 Dec 2014 13:43:48 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so1703328lbg.19 for ; Thu, 18 Dec 2014 13:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5TSu8KviP06fg2ZFo72zxw+zmQNRr89TC1mfm8VPZBU=; b=APB+aOzGWZzHe0b7h6hGgSnXf7FFyqOyx33e6HjCoJj1a0XseFFj87leaApN4lcJAC jaPOg/VcaPFHpMtSj+g7UkslFUqlWfJzjj/9mmHaqjTt8v+ajF6UT/HkOGXccwDpDBsf FQXh4UCcX6Ph+6+5V70U/xJGGFIEvesMS0OPPrVWRYhG2ZYx46ZQ9THyRpICSoT/NNiN WUD1wkq4lLeOPo06td7Oa7zCRt9g0FmDQiztsvPtS0VH7Cl7mI4dJRAkjo6l3HccOL2c Wn8tc4qExJpXmu2TEx0g/wIdTmkgpbV/n3RU2SfUGXoj97OAG1mnecnGeZeUPcB9B0md NELw== MIME-Version: 1.0 X-Received: by 10.152.87.67 with SMTP id v3mr4299730laz.97.1418939026823; Thu, 18 Dec 2014 13:43:46 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Thu, 18 Dec 2014 13:43:46 -0800 (PST) In-Reply-To: References: <5492B595.6020605@gmail.com> Date: Thu, 18 Dec 2014 16:43:46 -0500 X-Google-Sender-Auth: o5N8F8FEOG6MzFnwohBjXnc9Y8w Message-ID: From: Phillip Hallam-Baker To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c3510aa6dfd4050a847c3d Archived-At: http://mailarchive.ietf.org/arch/msg/acme/flLH70oB-xgMZQ-o0zCyGUr02XM Cc: "acme@ietf.org" , Anders Rundgren Subject: Re: [Acme] Message Type/Version Identifiers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 21:43:51 -0000 --001a11c3510aa6dfd4050a847c3d Content-Type: text/plain; charset=UTF-8 +1 We are doing an IETF spec, not a W3C spec. I have a lot of experience in using URIs as protocol identifiers, I originally proposed using them in the PICS spec them and I don't think they work at all. In the PICS spec the specific objective was to drive a wedge between the Dworkin/Mackinon supporters of censorship and the Religious Right supporters. If there had been one control lever they would have been forced to work together to agree on its use. Giving each their own lever collapsed their coalition. In that particular instance it was essential to provide a mechanism that allowed anyone to fork at any time. So it could not use a protocol registry. Here we have a Web Service spec and the objective is to end up with a common spec. So the starting point should be an IANA registration. Since we are doing Web Services, the obvious registry is the SRV registry. It would also be rather convenient to have a .well-known default URI. I see no reason not to use the prefix ACME for both. So initial discovery would be via SRV record: _acme._ws.example.com SRV 1 1 443 acmehost.example.com The host is acmehost.example.com, so the service URI is: http://acmehost.example.com/.well-known/acme/ That leaves two other questions, one is protocol version and the other is service feature set. These are independent. There might be a 1.0 service that supports the issue of both server and client certs and a 3.0 service that only supports server. We discussed this earlier, but one of the features many folk have suggested for the ACME protocol is a mechanism that allows a client to interrogate it to ask what it supports. I think this can be described as an instance of a general mechanism that can be copied by other specs. For versioning, the usual Major.Minor convention works fine. For feature sets, an IANA registry of text keywords using the RFC20 subset of UTF8 (as we now refer to US-ASCII). So I would see a conversation of the following sort: http/1.1 GET http://acmehost.example.com/.well-known/acme/ .. headers .. { "Describe" {} } Responses might be { "Versions" : ["1.0"] } { "Versions" :["1.0"], "Supports" : [ {"ACME" : ["Server", "Client"] }] } { "Versions" : ["1.0", "2.0"] "Supports" : [ {"ACME" : ["Server"] }, { "Versions" :["2.0"], "ACME" : ["Server", "Client"] }] } So the first only supports the default features. The second supports Client and Server cert issue. The third supports the 2.0 version of the protocol as well as 1.0 but only supports client cert issue for 2.0. Specifying the Feature and Version numbers as strings allows for a lot of flexibility. So for example, a service might support version 1.0 and 3.0 but not 2.0 which turned out to be a doofus version (think X.509v2 certs). If we do this in a well defined fashion we can eventually push the same attributes out into the DNS as part of the service registration interface and publish them via some new RR that is TBS which would allow them to be used for host selection. Using the SRV/WKS label for the features tag identifies these as attributes that would be defined in the ACME registry. this allows for better reuse of code points in the case that we were to use this for other negotiation dimensions. An ACME service that does not support the Describe method would only support the 0.0 version of the service by definition. Like the signature scheme outlined earlier, this is a module that can be reused very easily. On Thu, Dec 18, 2014 at 2:53 PM, Martin Thomson wrote: > > On 18 December 2014 at 03:08, Anders Rundgren > wrote: > > I have "backported" these things to JSON because I think they were > good. A > > system like > > ACME could also use such a scheme since there will undoubtedly be > revisions > > over time. > > I can appreciate the attraction, but this is a big "no" for me. > Absence of these features is one of the reasons that JSON has proven > successful over XML. > > If you need versioning at that level, I'd recommend defining a content > type instead. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a11c3510aa6dfd4050a847c3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

We are doing an IETF spec, not a W3C= spec.=C2=A0

I have a lot of experience in using U= RIs as protocol identifiers, I originally proposed using them in the PICS s= pec them and I don't think they work at all. In the PICS spec the speci= fic objective was to drive a wedge between the Dworkin/Mackinon supporters = of censorship and the Religious Right supporters. If there had been one con= trol lever they would have been forced to work together to agree on its use= . Giving each their own lever collapsed their coalition.

In that particular instance it was essential to provide a mechanism = that allowed anyone to fork at any time. So it could not use a protocol reg= istry.

Here we have a Web Service s= pec and the objective is to end up with a common spec. So the starting poin= t should be an IANA registration. Since we are doing Web Services, the obvi= ous registry is the SRV registry. It would also be rather convenient to hav= e a .well-known default URI.=C2=A0

I see no reason= not to use the prefix ACME for both. So initial discovery would be via SRV= record:

_acme._= ws.example.com SRV 1 1 443 acme= host.example.com

The host is acmehost.example.com, so the serv= ice URI is:

http://acmehost.example.com/.well-known/acme/
=

That leaves two other questions, one is = protocol version and the other is service feature set. These are independen= t. There might be a 1.0 service that supports the issue of both server and = client certs and a 3.0 service that only supports server.

We discussed this earlier, but one of the features many folk have s= uggested for the ACME protocol is a mechanism that allows a client to inter= rogate it to ask what it supports. I think this can be described as an inst= ance of a general mechanism that can be copied by other specs.
For versioning, the usual Major.Minor convention works fine.
For feature sets, an IANA registry of text keywords using the RFC2= 0 subset of UTF8 (as we now refer to US-ASCII).

So I would see a conversation of the following sort:

http/1.1 GET http://acmehost.example.com/.well-known/acme/
.. = headers ..

{ "Describe" {} }
<= br>

Responses might be=C2=A0

<= div>{ "Versions" : ["1.0"] }

<= div>{ "Versions" :["1.0"],=C2=A0
=C2=A0 "= ;Supports" : [
=C2=A0 =C2=A0 =C2=A0{"ACME" : [&quo= t;Server", "Client"] }] }

{=C2=A0"Versions" :=C2=A0["1.0", "2.0"]
=C2=A0 "Supports" : [
=C2=A0 =C2=A0 =C2=A0{"= ;ACME" : ["Server"] },
=C2=A0 =C2=A0 =C2=A0{=C2=A0= "Versions" :["2.0"],=C2=A0"ACME" : ["Ser= ver", "Client"] }] }

So the f= irst only supports the default features. The second supports Client and Ser= ver cert issue. The third supports the 2.0 version of the protocol as well = as 1.0 but only supports client cert issue for 2.0.

Specifying the Feature and Version numbers as strings allows for a lot of= flexibility. So for example, a service might support version 1.0 and 3.0 b= ut not 2.0 which turned out to be a doofus version (think X.509v2 certs).

If we do this in a well defined fash= ion we can eventually push the same attributes out into the DNS as part of = the service registration interface and publish them via some new RR that is= TBS which would allow them to be used for host selection.

Using the SRV/WKS label for the features tag identifies these as a= ttributes that would be defined in the ACME registry. this allows for bette= r reuse of code points in the case that we were to use this for other negot= iation dimensions.

An ACME service = that does not support the Describe method would only support the 0.0 versio= n of the service by definition.

Lik= e the signature scheme outlined earlier, this is a module that can be reuse= d very easily.

On Thu, Dec 18, 2014 at 2:53 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 18 December 2014 at 03:08, Anders Rundgren
<ander= s.rundgren.net@gmail.com> wrote:
> I have "backported" these things to JSON because I think the= y were good.=C2=A0 A
> system like
> ACME could also use such a scheme since there will undoubtedly be revi= sions
> over time.

I can appreciate the attraction, but this is a big "no" fo= r me.
Absence of these features is one of the reasons that JSON has proven
successful over XML.

If you need versioning at that level, I'd recommend defining a content<= br> type instead.

_______________________________________________
Acme mailing list
Acme@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/acme

--001a11c3510aa6dfd4050a847c3d-- From nobody Thu Dec 18 15:41:24 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244551A87AD for ; Thu, 18 Dec 2014 15:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJU2NuQZeOlX for ; Thu, 18 Dec 2014 15:41:13 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05AD1A9165 for ; Thu, 18 Dec 2014 15:41:12 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so1926141lab.1 for ; Thu, 18 Dec 2014 15:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=b1iYpN3mR/swtjOA39iIm5OPsKV3PjVvRP6dj8Bmgpg=; b=sqiWtORlhAK6QiPNQ86av9WJbN3qT1IewNIv8DpQU5HCIRf+vT//gB+zbhfb8yQVsI MAHUH+ac1isHddyfugroWGIhp9i9ylISL/qX+iHZmPo9oPjrctrU9fzRW5ihNgz5jKoj kle8eSwrshnAnVAmg5G4mXegXgEB1qycNC8owKQqhS9ZaO1diFaB8NGUsv+FX5MuiHo1 Uyh4QOANr4WAANyhGbluvI7r+cMONfkKU1pAZMCQ2hRZ+TkqEALVDJuStVr14B3bBdCy 9VgvXEjc/Huml+xRF/ewK/DJqtb5GZHTls8br7Uixu1x0ztcD4qArudZyvXqWPbmJkQL iu6A== MIME-Version: 1.0 X-Received: by 10.112.51.44 with SMTP id h12mr4875855lbo.5.1418946071306; Thu, 18 Dec 2014 15:41:11 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Thu, 18 Dec 2014 15:41:11 -0800 (PST) In-Reply-To: <54933EC2.3010104@gmail.com> References: <54933EC2.3010104@gmail.com> Date: Thu, 18 Dec 2014 18:41:11 -0500 X-Google-Sender-Auth: nV8qYi23Ajsm7Z3W0iEgYnwMbPk Message-ID: From: Phillip Hallam-Baker To: Anders Rundgren Content-Type: multipart/alternative; boundary=001a113339288928e3050a862061 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/qdXOPhu9y8F5lOggFYj_FxNHypg Cc: "acme@ietf.org" Subject: Re: [Acme] key agility? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 23:41:23 -0000 --001a113339288928e3050a862061 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > > With a multi-step protocol some kind of key agility should be possible to > support. > The client could for example start with telling its > preferences/capabilities. > > Anders > I do not know what you mean here. --001a113339288928e3050a862061 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 18, 2014 at 3:53 PM, Anders Rundgren <anders.rundgren= .net@gmail.com> wrote:
With a m= ulti-step protocol some kind of key agility should be possible to support.<= br> The client could for example start with telling its preferences/capabilitie= s.

Anders

I do not know what you mean here= .

=C2=A0
--001a113339288928e3050a862061-- From nobody Thu Dec 18 21:07:39 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A1F1ACCF2 for ; Thu, 18 Dec 2014 21:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB00fiwgaIzG for ; Thu, 18 Dec 2014 21:07:28 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7131ACC8D for ; Thu, 18 Dec 2014 21:07:28 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so575325wiv.2 for ; Thu, 18 Dec 2014 21:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=41BljCjiPXsIDgYF4pnKaNSx/J7/kg2H1CGVnGSzwHg=; b=UQkYPjFBdYig6y+eLSIEuH5S+uPtA0ZOREiBG01b7GicEw0q3uIS5docOc0pL5ZJxG J3T0RMRrs8CmQTNzumdLll49/yz+otkoX6h4HiRq9kFTudk+rfksLkJNea40pNLJ99UD eWVVWFwiKS/7MdSfBXdqzbu14NWnRaRyS2HTGD4DKcmbyEQhEljRauhVWQUYIpVOu9Ku 0FGcKN8Ng9ZPKfBFITxAQNanfvRCe1ymJzd9zCnavn+q7ie70lH5Saudoc02u+nQHoME 4nXBe5dQ5J2KJizJas0mMZsrDxl5XVk1dgSB1FCYHKtmXfbKUdos0rh24wFgULOe8r+d i+fQ== X-Received: by 10.180.108.235 with SMTP id hn11mr2161425wib.14.1418965646853; Thu, 18 Dec 2014 21:07:26 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id bj3sm980760wib.3.2014.12.18.21.07.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 21:07:26 -0800 (PST) Message-ID: <5493B286.4020001@gmail.com> Date: Fri, 19 Dec 2014 06:07:18 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , Martin Thomson References: <5492B595.6020605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/opdHJgGwxHAWSwRzTuUBEgOtpqc Cc: "acme@ietf.org" Subject: Re: [Acme] Message Type/Version Identifiers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 05:07:35 -0000 On 2014-12-18 22:43, Phillip Hallam-Baker wrote: > +1 > Just for the record, service discovery will in your opinion eliminate the need for explicit version information at the message object level (because this is really what I'm asking for)? I prefer URIs but of course traditional minor.major works as well. Anders > We are doing an IETF spec, not a W3C spec. > > I have a lot of experience in using URIs as protocol identifiers, I originally proposed using them in the PICS spec them and I don't think they work at all. In the PICS spec the specific objective was to drive a wedge between the Dworkin/Mackinon supporters of censorship and the Religious Right supporters. If there had been one control lever they would have been forced to work together to agree on its use. Giving each their own lever collapsed their coalition. > > In that particular instance it was essential to provide a mechanism that allowed anyone to fork at any time. So it could not use a protocol registry. > > > Here we have a Web Service spec and the objective is to end up with a common spec. So the starting point should be an IANA registration. Since we are doing Web Services, the obvious registry is the SRV registry. It would also be rather convenient to have a .well-known default URI. > > I see no reason not to use the prefix ACME for both. So initial discovery would be via SRV record: > > _acme._ws.example.com SRV 1 1 443 acmehost.example.com > > > The host is acmehost.example.com , so the service URI is: > > http://acmehost.example.com/.well-known/acme/ > > > That leaves two other questions, one is protocol version and the other is service feature set. These are independent. There might be a 1.0 service that supports the issue of both server and client certs and a 3.0 service that only supports server. > > We discussed this earlier, but one of the features many folk have suggested for the ACME protocol is a mechanism that allows a client to interrogate it to ask what it supports. I think this can be described as an instance of a general mechanism that can be copied by other specs. > > For versioning, the usual Major.Minor convention works fine. > For feature sets, an IANA registry of text keywords using the RFC20 subset of UTF8 (as we now refer to US-ASCII). > > > So I would see a conversation of the following sort: > > http/1.1 GET http://acmehost.example.com/.well-known/acme/ > .. headers .. > > { "Describe" {} } > > > Responses might be > > { "Versions" : ["1.0"] } > > { "Versions" :["1.0"], > "Supports" : [ > {"ACME" : ["Server", "Client"] }] } > > { "Versions" : ["1.0", "2.0"] > "Supports" : [ > {"ACME" : ["Server"] }, > { "Versions" :["2.0"], "ACME" : ["Server", "Client"] }] } > > So the first only supports the default features. The second supports Client and Server cert issue. The third supports the 2.0 version of the protocol as well as 1.0 but only supports client cert issue for 2.0. > > Specifying the Feature and Version numbers as strings allows for a lot of flexibility. So for example, a service might support version 1.0 and 3.0 but not 2.0 which turned out to be a doofus version (think X.509v2 certs). > > > If we do this in a well defined fashion we can eventually push the same attributes out into the DNS as part of the service registration interface and publish them via some new RR that is TBS which would allow them to be used for host selection. > > Using the SRV/WKS label for the features tag identifies these as attributes that would be defined in the ACME registry. this allows for better reuse of code points in the case that we were to use this for other negotiation dimensions. > > > An ACME service that does not support the Describe method would only support the 0.0 version of the service by definition. > > > Like the signature scheme outlined earlier, this is a module that can be reused very easily. > > > On Thu, Dec 18, 2014 at 2:53 PM, Martin Thomson > wrote: > > On 18 December 2014 at 03:08, Anders Rundgren > > wrote: > > I have "backported" these things to JSON because I think they were good. A > > system like > > ACME could also use such a scheme since there will undoubtedly be revisions > > over time. > > I can appreciate the attraction, but this is a big "no" for me. > Absence of these features is one of the reasons that JSON has proven > successful over XML. > > If you need versioning at that level, I'd recommend defining a content > type instead. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Thu Dec 18 21:09:26 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2C71A908B for ; Thu, 18 Dec 2014 21:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpp0SaL_xVhv for ; Thu, 18 Dec 2014 21:09:23 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CCD1A9163 for ; Thu, 18 Dec 2014 21:09:22 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so554894wiv.13 for ; Thu, 18 Dec 2014 21:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hxKNTljBgrSJNIGi6N/JK88YPRN4DEmNkzfd3O6Dygk=; b=ks8ix8xRioKWL1LvZ55BX6M89XJDpZydYkrC/D8O22UAicW025h7gW5xsyjayBbTkq 85ZLJYFWlnA+D7VitApGdHMQITKwEP2UzagxIQ3N91xQe1I6XOMAk/QmbiOy9rwe94P5 M6i2kU4dh83TAu49k5teyqb7ozp5pCkao0DskHZ80ZjZZNl9UJpkQUnFv9jVZfRS8G5N /ULmOnt391W6qbWulOsBQFi7D2qcuBonVQilLWCetTyWXKnSCALgvWcl++7/3bPiXSov EmkKK6TfXU9Wfsl3cfxFU02cFrS8glIS3xnk8JgmNGspsdmOMnxaRblj0E5AiyDpx2yD sh1g== X-Received: by 10.194.62.76 with SMTP id w12mr10891826wjr.5.1418965760940; Thu, 18 Dec 2014 21:09:20 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id ud4sm989816wib.0.2014.12.18.21.09.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 21:09:20 -0800 (PST) Message-ID: <5493B2F8.30308@gmail.com> Date: Fri, 19 Dec 2014 06:09:12 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <54933EC2.3010104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/ysVwwGgL-smYAaZTC73nXUI5mTc Cc: "acme@ietf.org" Subject: Re: [Acme] key agility? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 05:09:25 -0000 On 2014-12-19 00:41, Phillip Hallam-Baker wrote: > On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren > wrote: > > With a multi-step protocol some kind of key agility should be possible to support. > The client could for example start with telling its preferences/capabilities. > > Anders > > > I do not know what you mean here. > The ability to negotiate client key algorithm. Anders From nobody Thu Dec 18 22:01:26 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A88C1A9174 for ; Thu, 18 Dec 2014 22:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_rUiJ6yEmKe for ; Thu, 18 Dec 2014 22:01:22 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2EE1A9172 for ; Thu, 18 Dec 2014 22:01:22 -0800 (PST) Received: from [192.168.12.134] (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 6304EF984; Fri, 19 Dec 2014 01:01:18 -0500 (EST) Message-ID: <5493BF2F.3010607@fifthhorseman.net> Date: Fri, 19 Dec 2014 01:01:19 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Icedove/34.0 MIME-Version: 1.0 To: Anders Rundgren , Phillip Hallam-Baker References: <54933EC2.3010104@gmail.com> <5493B2F8.30308@gmail.com> In-Reply-To: <5493B2F8.30308@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gPdHMnl64lQmw1vAFSBdnqkH4aVPtcDU9" Archived-At: http://mailarchive.ietf.org/arch/msg/acme/jMxL0UkQWzNZkAuQaojoMfdoDqc Cc: "acme@ietf.org" Subject: Re: [Acme] key agility? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 06:01:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gPdHMnl64lQmw1vAFSBdnqkH4aVPtcDU9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/19/2014 12:09 AM, Anders Rundgren wrote: > On 2014-12-19 00:41, Phillip Hallam-Baker wrote: >> On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren >> >= >> wrote: >> >> With a multi-step protocol some kind of key agility should be >> possible to support. >> The client could for example start with telling its >> preferences/capabilities. >> >> Anders >> >> >> I do not know what you mean here. >> >=20 > The ability to negotiate client key algorithm. I think Anders is hinting at something like the following: * some TLS servers today have both RSA and ECDSA keys, and will offer a different cert depending on the capabilities offered by their clients. * this capacity (to support both key algorithms at once) is an important one to be able to do a transition when dealing with a heterogenous network. * acme should be able to support offering multiple certificates (with different key algorithms) to a single client which requests them. Anders, is that what you're talking about? --dkg --gPdHMnl64lQmw1vAFSBdnqkH4aVPtcDU9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUk78vXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcokIQAN2swnvb69bz0zKqJEAcTNmQ dz79OdGikw4MoM0+dNAdz97233pruge8fDAidmr0H861qtEMafP+415d10+/3qKH Uy/1UQBC54B/SiC/fw6iUlA9vkGuMbNp4PMgsr4/H5Etok3FgQE/R8zu/7lpXJOd /K/2oll8SXQc3cVCvkomafavDVTihtkPE00ye+fUeX4wvD/whTXCml8Fttbbl93X sUrd0BM2Kf4dtXcVcIUXbJ5jDPFVg3KlWMnVxDRciUpm8JPO2L6PoBcHs+E3Tg8E z95xYsEsJCJ5ehdxfOuf0J2cQwP1VTlwb7kE9CKE8lwRMvb1vmrFvUm/18WxA5FS 4u0xW2p9gygd8lk+4M7iw0FstdUkOGbFmixl3TV3EfMLCJpaHUfYfpyAH6P4EtRH 58yQd5B/NYkrrUvXdUbnM+eBsdZqNROX1C1MOF9Ca/3aCT+1E33uQ4Z3FDz3tkqO tiVwzIIHLsRs9wWb/SA5N1pqpMNzxgQ2hzqtaCzgghxp1J2edNgUiX7xI3s1xsYi ofkR6ZzAa8CZXUcBVWor3ZaCGOA4gMnHg5jeYJD1l+lG9YMvbOAEwgEd1DJzZ4sE +xw2qQzRySYJk37OPWWYRLjGwblqa3J2Zsw5MRjWZJpvauQJUDuUV24vX1OAnzns pRilPkzP6sb8a7YtKEsw =OeBP -----END PGP SIGNATURE----- --gPdHMnl64lQmw1vAFSBdnqkH4aVPtcDU9-- From nobody Thu Dec 18 22:03:01 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D981A9172 for ; Thu, 18 Dec 2014 22:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzgCSl2vfZ3U for ; Thu, 18 Dec 2014 22:02:57 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9AC1A9163 for ; Thu, 18 Dec 2014 22:02:57 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so411573wgh.36 for ; Thu, 18 Dec 2014 22:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GJnzpidKugLICG837EixzNum70wr4zj9J1A+Fh3vQ5g=; b=WgagS1ByoVYRQ89RZUHQNE7kRBq9yVNYRYIrLAB+MJPqbhmoGi0pRkyUaG3OQ649ni cWr7pAPBViEcGO788etqsmDnLiI7PRg+5Mh5l7QlVWjd547JNkT/cfJ/ckoGbWNE11lq FRxnL8/H8exKDdLAxo5BmomgzXB6BORd3IZrz+7AGdJOO4xKkWo33Eg1DRMV+athCvqU AW88VqvAi+o0odOpu3MXm+skj5wx8+GgaCFessL1JbDEnu77ygbYTwdNgez5CHNO87Fq bBUpFCHv5KUjnxc/ppgAurhMmx8nUZcFmQHf0lVIW3CSr/WC74V2jS9YygHFeCrZlgl+ DZNQ== X-Received: by 10.180.98.162 with SMTP id ej2mr2397200wib.39.1418968976146; Thu, 18 Dec 2014 22:02:56 -0800 (PST) Received: from [192.168.1.79] (52.16.14.81.rev.sfr.net. [81.14.16.52]) by mx.google.com with ESMTPSA id gl5sm4579498wib.0.2014.12.18.22.02.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 22:02:55 -0800 (PST) Message-ID: <5493BF87.6050107@gmail.com> Date: Fri, 19 Dec 2014 07:02:47 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Phillip Hallam-Baker References: <54933EC2.3010104@gmail.com> <5493B2F8.30308@gmail.com> <5493BF2F.3010607@fifthhorseman.net> In-Reply-To: <5493BF2F.3010607@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/acme/a7t5GwLnZrUI8du-z9eJmrUc0J8 Cc: "acme@ietf.org" Subject: Re: [Acme] key agility? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 06:02:59 -0000 On 2014-12-19 07:01, Daniel Kahn Gillmor wrote: > On 12/19/2014 12:09 AM, Anders Rundgren wrote: >> On 2014-12-19 00:41, Phillip Hallam-Baker wrote: >>> On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren >>> > >>> wrote: >>> >>> With a multi-step protocol some kind of key agility should be >>> possible to support. >>> The client could for example start with telling its >>> preferences/capabilities. >>> >>> Anders >>> >>> >>> I do not know what you mean here. >>> >> >> The ability to negotiate client key algorithm. > > I think Anders is hinting at something like the following: > > * some TLS servers today have both RSA and ECDSA keys, and will offer a > different cert depending on the capabilities offered by their clients. > > * this capacity (to support both key algorithms at once) is an > important one to be able to do a transition when dealing with a > heterogenous network. > > * acme should be able to support offering multiple certificates (with > different key algorithms) to a single client which requests them. > > Anders, is that what you're talking about? Indeed, pardon for being so unclear :-( Anders > > --dkg > From nobody Fri Dec 19 07:46:19 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79E21A8972 for ; Fri, 19 Dec 2014 07:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImQ4oPbsKNdI for ; Fri, 19 Dec 2014 07:46:05 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0D61A00E0 for ; Fri, 19 Dec 2014 07:46:05 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so1051992lab.14 for ; Fri, 19 Dec 2014 07:46:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jDqvY1XCg5CjbJ9Ugj04AOdi+bt8xXImArloPyQyRtE=; b=fk9OCgdyl91vPBZ0PdVQwasqj7sGkitkn3HqcGZaY4gWpDl6QubyCEOfBsApTZtXhm 4Q7KEVQMf6PkMLBI0xrhtrG59BI2BicI1LFsUILncFKN2WVqxT1W+kXVUyKs08cfAjKR WMiSu4ylmsKGS/omstW/7eUNxWuSECxfu7ncuHV7lo2yYu+kcVT+incpspAzpOAA+XNR gzz/gaxIy5XYni/XHOVrxzglu8Pc9uunep2icsR1o8gfJCB8+3z8Hps2coQoGRD2zmoB KVHsQICwJAS6ZEZHvQKdLEQRLlZ/PAj8HMW14LIFi9yR3oaEmQfzbd/eHyEw3/PF10S+ cmGA== MIME-Version: 1.0 X-Received: by 10.112.51.44 with SMTP id h12mr8527867lbo.5.1419003963356; Fri, 19 Dec 2014 07:46:03 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Fri, 19 Dec 2014 07:46:03 -0800 (PST) In-Reply-To: <5493BF2F.3010607@fifthhorseman.net> References: <54933EC2.3010104@gmail.com> <5493B2F8.30308@gmail.com> <5493BF2F.3010607@fifthhorseman.net> Date: Fri, 19 Dec 2014 10:46:03 -0500 X-Google-Sender-Auth: aJUzUKcc57nIl-padRMgvqq4csc Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a113339282bbcc6050a939bc0 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/BXDOP2V4Jpnuhnr4HEH-zbiix6s Cc: "acme@ietf.org" , Anders Rundgren Subject: Re: [Acme] key agility? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 15:46:17 -0000 --001a113339282bbcc6050a939bc0 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 19, 2014 at 1:01 AM, Daniel Kahn Gillmor wrote: > > On 12/19/2014 12:09 AM, Anders Rundgren wrote: > > On 2014-12-19 00:41, Phillip Hallam-Baker wrote: > >> On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren > >> > > >> wrote: > >> > >> With a multi-step protocol some kind of key agility should be > >> possible to support. > >> The client could for example start with telling its > >> preferences/capabilities. > >> > >> Anders > >> > >> > >> I do not know what you mean here. > >> > > > > The ability to negotiate client key algorithm. > > I think Anders is hinting at something like the following: > > * some TLS servers today have both RSA and ECDSA keys, and will offer a > different cert depending on the capabilities offered by their clients. > > * this capacity (to support both key algorithms at once) is an > important one to be able to do a transition when dealing with a > heterogenous network. > > * acme should be able to support offering multiple certificates (with > different key algorithms) to a single client which requests them. > > Anders, is that what you're talking about? This is still unclear to me. Are we talking about the client negotiating the provision of a certificate pair so as to be able to support dual RSA/ECC issue? Or are we talking about the client being able to select the use of an ECC or RSA key to authenticate the ACME protocol. If the first, I agree. If the second then I am very confused. As I see the ACME protocol, it is an upgrade to the traditional Cert issue protocol to support the new requirements of modern cert use including embedded devices and the cloud. Enabling the ECC transition is another important requirement. Fortunately it is pretty easy to support any of these if we support a service feature negotiation phase. The guts of the protocol is a request of the form: { "IssueRequest" : { "Version" : "1.0", "CSR" : , } While it is simplest and most straightforward to treat ECC and RSA as issue of two separate certs, combining them might simplify the management task and in particular integration with TRANS. --001a113339282bbcc6050a939bc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 19, 2014 at 1:01 AM, Daniel Kahn Gillmor = <dkg@fifthhor= seman.net> wrote:
On 12/19/2014 12:09 AM, Anders Rundgren wrote: > On 2014-12-19 00:41, Phillip Hallam-Baker wrote:
>> On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren
>> <anders.rundgr= en.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0With a multi-step protocol some kind of key agi= lity should be
>> possible to support.
>>=C2=A0 =C2=A0 =C2=A0The client could for example start with telling= its
>> preferences/capabilities.
>>
>>=C2=A0 =C2=A0 =C2=A0Anders
>>
>>
>> I do not know what you mean here.
>>
>
> The ability to negotiate client key algorithm.

I think Anders is hinting at something like the following:

=C2=A0* some TLS servers today have both RSA and ECDSA keys, and will offer= a
different cert depending on the capabilities offered by their clients.

=C2=A0* this capacity (to support both key algorithms at once) is an
important one to be able to do a transition when dealing with a
heterogenous network.

=C2=A0* acme should be able to support offering multiple certificates (with=
different key algorithms) to a single client which requests them.

Anders, is that what you're talking about?

<= div>This is still unclear to me.

Are we talking ab= out the client negotiating the provision of a certificate pair so as to be = able to support dual RSA/ECC issue?

Or are we talk= ing about the client being able to select the use of an ECC or RSA key to a= uthenticate the ACME protocol.

If t= he first, I agree. If the second then I am very confused.

As I see the ACME protocol, it is an upgrade to the traditional Cer= t issue protocol to support the new requirements of modern cert use includi= ng embedded devices and the cloud. Enabling the ECC transition is another i= mportant requirement.

Fortunately i= t is pretty easy to support any of these if we support a service feature ne= gotiation phase.

The guts of the protocol is a req= uest of the form:

<Signature Parameters>

{ "IssueRequest" : {
=C2=A0 =C2= =A0 "Version" : "1.0",
=C2=A0 =C2=A0 "CS= R" : <CSR in Base64>,
=C2=A0 =C2=A0 <other attribut= es>
=C2=A0 =C2=A0 }

While it is simpl= est and most straightforward to treat ECC and RSA as issue of two separate = certs, combining them might simplify the management task and in particular = integration with TRANS.=C2=A0

<= /div>
--001a113339282bbcc6050a939bc0-- From nobody Fri Dec 19 10:11:30 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB871A8A65 for ; Fri, 19 Dec 2014 10:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38pADMpRQ-EX for ; Fri, 19 Dec 2014 10:11:25 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8881ACCF9 for ; Fri, 19 Dec 2014 10:11:24 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id q1so1300198lam.19 for ; Fri, 19 Dec 2014 10:11:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iw6b+iCFBsonc4x4RSmpouGBmSupfPmf5CAGvrra0GU=; b=Ethe5mIj2zkthSUuzkuXyRt5oBheDq4AvFcOnP4iHDuxfVqVmIrmsISfl5CoDLWnAF sNYXsP3yybHqVAfldF3ocapIyg3BAUxmYGBHRX9L9KfmSr3Bhzlt7DPWdP4okkPUsf9z zzSj1tKT9VG7bmE9Lf5B2s6Bi7i4cIYfiYn7N1oUg/nWfjOVy8/yVaa1B6fnYJNPhefu NI3CDYIX/2LJBYM47DhvYzyZKtsZSon7mrpw+RiIDUJDkXrCIPZ4Mqxmh1V9xQnD3GRw vX1oEqaSU4pcyVkAA/NFJyI9zkImGTFDpdZ53fw6zYuvG/gvvwLNcLs+GZaFJJhyhSxq yehA== X-Gm-Message-State: ALoCoQlM3yAi9XsjCFbL0KYpqujVbkKpBfjoG6hWVYUAC7iDOuO6ygtQbmQcTDdMrJDFhHLYTDJE MIME-Version: 1.0 X-Received: by 10.112.47.135 with SMTP id d7mr2538368lbn.54.1419012683453; Fri, 19 Dec 2014 10:11:23 -0800 (PST) Received: by 10.25.12.215 with HTTP; Fri, 19 Dec 2014 10:11:23 -0800 (PST) In-Reply-To: <5493BF87.6050107@gmail.com> References: <54933EC2.3010104@gmail.com> <5493B2F8.30308@gmail.com> <5493BF2F.3010607@fifthhorseman.net> <5493BF87.6050107@gmail.com> Date: Fri, 19 Dec 2014 13:11:23 -0500 Message-ID: From: Richard Barnes To: Anders Rundgren Content-Type: multipart/alternative; boundary=001a1134d2e6eded48050a95a285 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/wFD-9cfIhQh7_-MSXyGbLvqbWO8 Cc: "acme@ietf.org" , Phillip Hallam-Baker , Daniel Kahn Gillmor Subject: Re: [Acme] key agility? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 18:11:27 -0000 --001a1134d2e6eded48050a95a285 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 19, 2014 at 1:02 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > > On 2014-12-19 07:01, Daniel Kahn Gillmor wrote: > >> On 12/19/2014 12:09 AM, Anders Rundgren wrote: >> >>> On 2014-12-19 00:41, Phillip Hallam-Baker wrote: >>> >>>> On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren >>>> > >>>> wrote: >>>> >>>> With a multi-step protocol some kind of key agility should be >>>> possible to support. >>>> The client could for example start with telling its >>>> preferences/capabilities. >>>> >>>> Anders >>>> >>>> >>>> I do not know what you mean here. >>>> >>>> >>> The ability to negotiate client key algorithm. >>> >> >> I think Anders is hinting at something like the following: >> >> * some TLS servers today have both RSA and ECDSA keys, and will offer a >> different cert depending on the capabilities offered by their clients. >> >> * this capacity (to support both key algorithms at once) is an >> important one to be able to do a transition when dealing with a >> heterogenous network. >> >> * acme should be able to support offering multiple certificates (with >> different key algorithms) to a single client which requests them. >> >> Anders, is that what you're talking about? >> > > Indeed, pardon for being so unclear :-( > > Thanks for clarifying. ACME incorporates the idea of multiple certificates for the same identifier, even for different clients. That's the reason for the separation between the "authorized key pair" (~= client) and the "subject key pair" (~= certificate). An authorized key pair can be used to issue any number of certificates for any combination of names that it is authorized for. That general framework includes the kind of flexibility you're looking for. --Richard > Anders > > >> --dkg >> >> > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a1134d2e6eded48050a95a285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 19, 2014 at 1:02 AM, Anders Rundgren <= anders.r= undgren.net@gmail.com> wrote:
<= div class=3D"HOEnZb">
On 2014-12-19 07:01, Daniel Kahn Gil= lmor wrote:

On 12/19/2014 12:09 AM, Anders Rundgren wrote:

On 2014-12-19 00:41, Phillip Hallam-Baker wrote:

On Thu, Dec 18, 2014 at 3:53 PM, Anders Rundgren
<ande= rs.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com&g= t;>
wrote:

=C2=A0 =C2=A0 =C2=A0With a multi-step protocol some kind of key agility sho= uld be
possible to support.
=C2=A0 =C2=A0 =C2=A0The client could for example start with telling its
preferences/capabilities.

=C2=A0 =C2=A0 =C2=A0Anders

I do not know what you mean here.

The ability to negotiate client key algorithm.

I think Anders is hinting at something like the following:

=C2=A0 * some TLS servers today have both RSA and ECDSA keys, and will offe= r a
different cert depending on the capabilities offered by their clients.

=C2=A0 * this capacity (to support both key algorithms at once) is an
important one to be able to do a transition when dealing with a
heterogenous network.

=C2=A0 * acme should be able to support offering multiple certificates (wit= h
different key algorithms) to a single client which requests them.

Anders, is that what you're talking about?

Indeed, pardon for being so unclear :-(

Thanks for clarifying.=C2=A0 ACME inco= rporates the idea of multiple certificates for the same identifier, even fo= r different clients.=C2=A0 That's the reason for the separation between= the "authorized key pair" (~=3D client) and=C2=A0 the "subj= ect key pair" (~=3D certificate).=C2=A0 An authorized key pair can be = used to issue any number of certificates for any combination of names that = it is authorized for.

That general framework includes the= kind of flexibility you're looking for.

--Richard

=C2=A0
Anders

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg

_______________________________________________
Acme mailing list
Acme@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/acme

--001a1134d2e6eded48050a95a285-- From nobody Fri Dec 19 10:12:57 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF621ACD04 for ; Fri, 19 Dec 2014 10:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVaxZ-UGhZRf for ; Fri, 19 Dec 2014 10:12:53 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEFE1ACD02 for ; Fri, 19 Dec 2014 10:12:52 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id a141so2082701oig.8 for ; Fri, 19 Dec 2014 10:12:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l5+GiQhmDR/cyR+qafdeU0n2EsffOMjHdowC3e3m7Y0=; b=Dh8KwsMsyXy1VzXfxfZ08AZluRrvu19zM8EbyrkGqOwiG7H+Q+/LsNJz/RWGqtPXM4 E+UQ19GPuZh4v9qjwIcOITQM1WL2PySqK/Pbi9DJn6QhcIjBUjNuF8m0aprmZWesDYAx 8kpHs40P4gaYKqTK93O7IsTSjzlYNbww2NBsERTYCJknZOHiQYsNv4JjZnDEpQeWNUdJ cjEbfpReQZdAsf//9MGhJWOTkbg2coYMQVG1/73HN65rWRQPHAlWxHQDbs8DXbLFQwHQ loIegZRrBXAogm5G7FhWxZg6NLDYybFS1NxiEHV+oJQnapZPSBMoLU5fXDBBelfh0TdO EJHg== MIME-Version: 1.0 X-Received: by 10.182.46.134 with SMTP id v6mr5567227obm.34.1419012772064; Fri, 19 Dec 2014 10:12:52 -0800 (PST) Received: by 10.202.49.203 with HTTP; Fri, 19 Dec 2014 10:12:51 -0800 (PST) In-Reply-To: <5493B286.4020001@gmail.com> References: <5492B595.6020605@gmail.com> <5493B286.4020001@gmail.com> Date: Fri, 19 Dec 2014 10:12:51 -0800 Message-ID: From: Martin Thomson To: Anders Rundgren Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/SV6d3Cfjv7zILiM_QwVe7CxHb9k Cc: Phillip Hallam-Baker , "acme@ietf.org" Subject: Re: [Acme] Message Type/Version Identifiers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 18:12:54 -0000 On 18 December 2014 at 21:07, Anders Rundgren wrote: > Just for the record, service discovery will in your opinion eliminate the > need for explicit version information at the message object level (because > this is > really what I'm asking for)? > > I prefer URIs but of course traditional minor.major works as well. I think that you are both over-engineering it. Identify this as "acme". If you need to make changes that aren't backward compatible, call it "acmi". From nobody Fri Dec 19 10:34:17 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2B31ACCEB for ; Fri, 19 Dec 2014 10:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTdgApyH2xb5 for ; Fri, 19 Dec 2014 10:34:15 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06A51ACC8F for ; Fri, 19 Dec 2014 10:34:14 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id w7so1303705lbi.16 for ; Fri, 19 Dec 2014 10:34:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NkfinFaVxTJRrbN9xIKdMWf72ew3IpDMk/ttkkjA0Oc=; b=fiIwyQi8j7jNdJ2aJD6fnsYHd2/j7x6xZIbzQsShsfJPM2o7sqwYQzkvgNNWJafC2M niTMduXF46HynK4va74bO96yMBGLZhktJ9ZZf1QfnOS+NClYUMGvZ570WNx36ZTrlZ4t fdEdfKcnBTUYVpl8mpNfjPEFwOtKp9InOgibNuQQOwJR1w8smM+Ns08q2BhUtv4LdB/h QK4w1mkT9tUh/TYHpRQ4/GL2l2/fEjBekVev8InYe3+CwJ9+8HqOC2KMo8B4lhhAI0n3 QwkBrwP6XRVnKGCJtWq6qgwsAHy9Y1Kp2QzOgf0BAGmEtYS7EpZ447lKFm77a7xKsSqT u68A== X-Gm-Message-State: ALoCoQknymDpZC6a2WYYxDILE6J6OxYL5qWETkwyRQUOp7Sqo+6eN6+liZbMYs09HLuCQ6cUvF+n MIME-Version: 1.0 X-Received: by 10.112.101.100 with SMTP id ff4mr9160286lbb.94.1419014053422; Fri, 19 Dec 2014 10:34:13 -0800 (PST) Received: by 10.25.12.215 with HTTP; Fri, 19 Dec 2014 10:34:13 -0800 (PST) In-Reply-To: References: <5492B595.6020605@gmail.com> <5493B286.4020001@gmail.com> Date: Fri, 19 Dec 2014 13:34:13 -0500 Message-ID: From: Richard Barnes To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1135e2989601c8050a95f4b8 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/lQJJ_azS-dvp90mZuH81ZJB8vd4 Cc: Phillip Hallam-Baker , "acme@ietf.org" , Anders Rundgren Subject: Re: [Acme] Message Type/Version Identifiers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 18:34:16 -0000 --001a1135e2989601c8050a95f4b8 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 19, 2014 at 1:12 PM, Martin Thomson wrote: > > On 18 December 2014 at 21:07, Anders Rundgren > wrote: > > Just for the record, service discovery will in your opinion eliminate the > > need for explicit version information at the message object level > (because > > this is > > really what I'm asking for)? > > > > I prefer URIs but of course traditional minor.major works as well. > > I think that you are both over-engineering it. Identify this as > "acme". If you need to make changes that aren't backward compatible, > call it "acmi". > And then, "acmii", "acmiii", "acmiv", ...? :) I think the idea of separating things by URI is the right track. That punts the versioning question to discovery/configuration. --Richard > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a1135e2989601c8050a95f4b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 19, 2014 at 1:12 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 18 Decemb= er 2014 at 21:07, Anders Rundgren
<ander= s.rundgren.net@gmail.com> wrote:
> Just for the record, service discovery will in your opinion eliminate = the
> need for explicit version information at the message object level (bec= ause
> this is
> really what I'm asking for)?
>
> I prefer URIs but of course traditional minor.major works as well.

I think that you are both over-engineering it.=C2=A0 Identify this a= s
"acme".=C2=A0 If you need to make changes that aren't backwar= d compatible,
call it "acmi".

And then, &qu= ot;acmii", "acmiii", "acmiv", ...?=C2=A0 :)
I think the idea of separating things by URI is the right track= .=C2=A0 That punts the versioning question to discovery/configuration.
<= br>
--Richard

=C2=A0

_______________________________________________
Acme mailing list
Acme@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/acme

--001a1135e2989601c8050a95f4b8-- From nobody Fri Dec 19 10:46:32 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F66F1A8AF7 for ; Fri, 19 Dec 2014 10:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FazaOnC6bco for ; Fri, 19 Dec 2014 10:46:30 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096411A8AD4 for ; Fri, 19 Dec 2014 10:46:30 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so1370004lab.9 for ; Fri, 19 Dec 2014 10:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lyP/s5Mgq/cONcdmP1J/UHIbU1Ay0N9cEsBS535gd7Q=; b=yibK1ZayE/o+L+/SaP7vUj9/lOpRDCnbPBLTFINwROMFiqNXSVYgqYercmveVHwunB UPDxRM1aimA5ZZVfxMlHK8AY+I0Q/YxMu81nhvQzpr8dt4SUX6Ry5MFu3TWdxCglvHQs QLZzis6N5WTtlXPhLabzLvL8rSUwYtoUpA9vgfMiwoel7PKtTkJACLJ8384T2poOsmeT +eFlVlwxhDda+aEDsFmB8iDRWikaKwMsNPruTL8rh1YPMCchtQpsnLy+Hcv03rjbroTy rDMHZdkkXK8I7tNXPpIGYZyEA/RXM7mdZXm183jB958SKbiSxnx3dXRgwnTlKn8sA8c6 yCMg== MIME-Version: 1.0 X-Received: by 10.112.162.226 with SMTP id yd2mr9303996lbb.1.1419014788550; Fri, 19 Dec 2014 10:46:28 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Fri, 19 Dec 2014 10:46:28 -0800 (PST) In-Reply-To: References: <5492B595.6020605@gmail.com> <5493B286.4020001@gmail.com> Date: Fri, 19 Dec 2014 13:46:28 -0500 X-Google-Sender-Auth: WmFzh3bxHl5K8Psv287ukMBXz8w Message-ID: From: Phillip Hallam-Baker To: Richard Barnes Content-Type: multipart/alternative; boundary=089e0112c86c6718f9050a9620f5 Archived-At: http://mailarchive.ietf.org/arch/msg/acme/xYJbTrNMi_k27VfJBjLcLTkOzAU Cc: "acme@ietf.org" , Martin Thomson , Anders Rundgren Subject: Re: [Acme] Message Type/Version Identifiers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 18:46:31 -0000 --089e0112c86c6718f9050a9620f5 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 19, 2014 at 1:34 PM, Richard Barnes wrote: > > > > On Fri, Dec 19, 2014 at 1:12 PM, Martin Thomson > wrote: >> >> On 18 December 2014 at 21:07, Anders Rundgren >> wrote: >> > Just for the record, service discovery will in your opinion eliminate >> the >> > need for explicit version information at the message object level >> (because >> > this is >> > really what I'm asking for)? >> > >> > I prefer URIs but of course traditional minor.major works as well. >> >> I think that you are both over-engineering it. Identify this as >> "acme". If you need to make changes that aren't backward compatible, >> call it "acmi". >> > > And then, "acmii", "acmiii", "acmiv", ...? :) > > I think the idea of separating things by URI is the right track. That > punts the versioning question to discovery/configuration. > Noooooo The URI that the Web Service is provided from has no connection to the unique identifier for the specification. I am not wedged on the Major.Minor version thing. We could just as easily use keywords for both and that is a little simpler. We very rarely make backwards incompatible changes in any case and we don't add features monotonically so minor version numbers don't add anything that can't be said in a feature tag. SMTP has worked fine with a Feature tag approach. We have POP3 and IMAP4. Whether we structure them as tags or URIs the structure is exactly the same. The URI is an opaque identifier. Defining semantics on the internal syntax of a URI is bad juju. So the difference is POP3 urn:ietf:service-names-port-numbers:TCP:POP3 The second does not provide anything the first does not. All it does is make the protocol longer and harder to read. --089e0112c86c6718f9050a9620f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 19, 2014 at 1:34 PM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wr= ote:

On Fri, Dec 19, 2014 at 1:1= 2 PM, Martin Thomson <martin.thomson@gmail.com> wrote= :
On 18 December 2014 at 21:07, Anders Rundgren
<anders.rundgren.net@gmail.com> wrote:
> Just for the record, service discovery will in your opinion eliminate = the
> need for explicit version information at the message object level (bec= ause
> this is
> really what I'm asking for)?
>
> I prefer URIs but of course traditional minor.major works as well.

I think that you are both over-engineering it.=C2=A0 Identify this a= s
"acme".=C2=A0 If you need to make changes that aren't backwar= d compatible,
call it "acmi".

A= nd then, "acmii", "acmiii", "acmiv", ...?=C2= =A0 :)

I think the idea of separating things by URI is th= e right track.=C2=A0 That punts the versioning question to discovery/config= uration.

Nooooo= o

The URI that the Web Service is provided from ha= s no connection to the unique identifier for the specification.
<= br>
I am not wedged on the Major.Minor version thing. We could ju= st as easily use keywords for both and that is a little simpler. We very ra= rely make backwards incompatible changes in any case and we don't add f= eatures monotonically so minor version numbers don't add anything that = can't be said in a feature tag.

SMTP has worked fine with a Feature tag approach. We have POP3 and IMAP4.<= /div>

Whether we structure them as tags or URIs the stru= cture is exactly the same. The URI is an opaque identifier. Defining semant= ics on the internal syntax of a URI is bad juju.

So the difference is

POP3
<= div>urn:ietf:service-names-port-numbers:TCP:POP3

<= br>
The second does not provide anything the first does not. All = it does is make the protocol longer and harder to read.

--089e0112c86c6718f9050a9620f5-- From nobody Fri Dec 19 11:02:53 2014 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A31AC44D for ; Fri, 19 Dec 2014 11:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPcEdftSp3Dn for ; Fri, 19 Dec 2014 11:02:49 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EB31A87BE for ; Fri, 19 Dec 2014 11:02:49 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so1427063lbj.23 for ; Fri, 19 Dec 2014 11:02:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9mjAYryZ3j+JJcTvdUPeGgiS0dEI0NOdSTpLm5Hv/dA=; b=nIOEdkB5uwHcIswDYUVWkq1frhX/8eEgbsjLGpVfamunc4IeLuu5WXzWM0FsSs1Xjn GcvNCCS/5PeOh1OCFvl3SRpTQ5qYp2EsAZ9DTE6wBxx3G/pzRErLNTtG9cczT/elnmyY Lcrgywb7CxbolU0pbv5FLEtrIjTU+uHjTMfdozq3Y1q2pGupmN88aGdy1Zm9kC5QIgpy k6QNNflRotSk5zO/Z14honhQ+ONQWoAcX5Q86IW/tonM/rglNhGIduNPktaaPCH2RCvq p4Sc03bXERdf7X5KD2Whh2wx7+oA53HdjLi/ZDUQ54uQEX4bYnyJ08o6ZmnyK2hk61nR khiQ== X-Gm-Message-State: ALoCoQnSlcrjXCNMWXTmfVxTXVehkXrqK3z3USKh/vd145u8F2VQXu7J9phPfpowTNp7SbzHsUxW MIME-Version: 1.0 X-Received: by 10.112.138.137 with SMTP id qq9mr9291747lbb.80.1419015767493; Fri, 19 Dec 2014 11:02:47 -0800 (PST) Received: by 10.25.12.215 with HTTP; Fri, 19 Dec 2014 11:02:47 -0800 (PST) In-Reply-To: References: <5492B595.6020605@gmail.com> <5493B286.4020001@gmail.com> Date: Fri, 19 Dec 2014 14:02:47 -0500 Message-ID: From: Richard Barnes To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=089e0112cc54c0a578050a965a2f Archived-At: http://mailarchive.ietf.org/arch/msg/acme/Tw6_EXTtkjkLSQdw_3K75R9KWmk Cc: "acme@ietf.org" , Martin Thomson , Anders Rundgren Subject: Re: [Acme] Message Type/Version Identifiers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 19:02:50 -0000 --089e0112cc54c0a578050a965a2f Content-Type: text/plain; charset=UTF-8 On Fri, Dec 19, 2014 at 1:46 PM, Phillip Hallam-Baker wrote: > > > > On Fri, Dec 19, 2014 at 1:34 PM, Richard Barnes wrote: >> >> >> >> On Fri, Dec 19, 2014 at 1:12 PM, Martin Thomson > > wrote: >>> >>> On 18 December 2014 at 21:07, Anders Rundgren >>> wrote: >>> > Just for the record, service discovery will in your opinion eliminate >>> the >>> > need for explicit version information at the message object level >>> (because >>> > this is >>> > really what I'm asking for)? >>> > >>> > I prefer URIs but of course traditional minor.major works as well. >>> >>> I think that you are both over-engineering it. Identify this as >>> "acme". If you need to make changes that aren't backward compatible, >>> call it "acmi". >>> >> >> And then, "acmii", "acmiii", "acmiv", ...? :) >> >> I think the idea of separating things by URI is the right track. That >> punts the versioning question to discovery/configuration. >> > > Noooooo > > The URI that the Web Service is provided from has no connection to the > unique identifier for the specification. > Yeeeeees :) You're missing my point. The version identifier is not in band to the protocol. We can define a protocol that says "We assume you have a URL as a starting point for this protocol." That URL only has to provide one version of the protocol, so there's no need for the protocol itself to have a notion of version. Then the question is just how you find the URL for the version you want. That's a question for a separate discovery protocol. --Richard > I am not wedged on the Major.Minor version thing. We could just as easily > use keywords for both and that is a little simpler. We very rarely make > backwards incompatible changes in any case and we don't add features > monotonically so minor version numbers don't add anything that can't be > said in a feature tag. > > > SMTP has worked fine with a Feature tag approach. We have POP3 and IMAP4. > > Whether we structure them as tags or URIs the structure is exactly the > same. The URI is an opaque identifier. Defining semantics on the internal > syntax of a URI is bad juju. > > > So the difference is > > POP3 > urn:ietf:service-names-port-numbers:TCP:POP3 > > > The second does not provide anything the first does not. All it does is > make the protocol longer and harder to read. > --089e0112cc54c0a578050a965a2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 19, 2014 at 1:46 PM, Phillip Hallam-Baker <phill@halla= mbaker.com> wrote:

On Fri, Dec 19, 2014 at 1:34 PM, Richard Barnes = <rlb@ipv.sx> wrote:

<= br>
On Fri, Dec 19, 2014 at 1:12 PM, Ma= rtin Thomson <martin.thomson@gmail.com> wrote:On 18 December 2014 at 21:07, Anders Rundgren
<anders.rundgren.net@gmail.com> wrote:
> Just for the record, service discovery will in your opinion eliminate = the
> need for explicit version information at the message object level (bec= ause
> this is
> really what I'm asking for)?
>
> I prefer URIs but of course traditional minor.major works as well.

I think that you are both over-engineering it.=C2=A0 Identify this a= s
"acme".=C2=A0 If you need to make changes that aren't backwar= d compatible,
call it "acmi".

A= nd then, "acmii", "acmiii", "acmiv", ...?=C2= =A0 :)

I think the idea of separating things by URI is th= e right track.=C2=A0 That punts the versioning question to discovery/config= uration.

Noooooo

The URI that the Web Service is provided = from has no connection to the unique identifier for the specification.

Yeeeeees :)

You're missing my point.=C2=A0 The version identi= fier is not in band to the protocol.

We can define a prot= ocol that says "We assume you have a URL as a starting point for this = protocol."=C2=A0 That URL only has to provide one version of the proto= col, so there's no need for the protocol itself to have a notion of ver= sion.

Then the question is just how you find the URL for = the version you want.=C2=A0 That's a question for a separate discovery = protocol.

--Richard

=C2=A0
I am not wedged on the Major.Minor version th= ing. We could just as easily use keywords for both and that is a little sim= pler. We very rarely make backwards incompatible changes in any case and we= don't add features monotonically so minor version numbers don't ad= d anything that can't be said in a feature tag.

SMTP has worked fine with a Feature tag approach. We have = POP3 and IMAP4.

Whether we structure them as tags = or URIs the structure is exactly the same. The URI is an opaque identifier.= Defining semantics on the internal syntax of a URI is bad juju.
<= div>

So the difference is

=
POP3
urn:ietf:service-names-port-numbers:TCP:POP3
=

The second does not provide anything the firs= t does not. All it does is make the protocol longer and harder to read.