Re: [Acme] New Version Notification for draft-ietf-acme-acme-15.txt

2018-09-25 Thread Adam Roach 
The new text looks great. Thanks for the work that everyone has done to 
address the privacy concerns I highlighted.


I do worry that implementors are likely to overlook the new text when 
the examples so clearly do not follow the recommendations in section 
10.5. Please note that this was explicitly point (3) of my DISCUSS. For 
avoidance of doubt, I'll highlight the minimal set of examples that need 
to be updated. It would be ideal if the other examples that use 
constructs like "1234" and "4321" were similarly updated, but they are 
less likely to lead to the confusion that will be caused by the ones I 
cite below, which use single digits where section 10.5 calls for "large 
unpredictable components".


One minor nit (since you're going to need a new draft): 
s/concatinates/concatenates/


Problem 1:

{
  "status": "valid",
  "contact": [
"mailto:cert-ad...@example.com;,
"mailto:ad...@example.com;
  ],
  "termsOfServiceAgreed": true,
  "orders": "https://example.com/acme/acct/1/orders;
}


Problem 2:

{
  "orders": [
"https://example.com/acme/acct/1/order/1;,
"https://example.com/acme/acct/1/order/2;,
/* 47 more URLs not shown for example brevity */
"https://example.com/acme/acct/1/order/50;
  ]
}


Problem 3:

{
  "status": "valid",
  "expires": "2015-03-01T14:09:07.99Z",

  "identifiers": [
{ "type": "dns", "value": "example.com" },
{ "type": "dns", "value": "www.example.com" }
  ],

  "notBefore": "2016-01-01T00:00:00Z",
  "notAfter": "2016-01-08T00:00:00Z",

  "authorizations": [
"https://example.com/acme/authz/1234;,
"https://example.com/acme/authz/2345;
  ],

  "finalize": "https://example.com/acme/acct/1/order/1/finalize;,

  "certificate": "https://example.com/acme/cert/1234;
}
(at least the "finalize" URLs, and arguable the "certificate" and 
"authorizations" URLs)



Problem 4:


HTTP/1.1 201 Created
Content-Type: application/json
Replay-Nonce: D8s4D2mLs8Vn-goWuPQeKA
Location: https://example.com/acme/acct/1
Link: ;rel="index"

{
  "status": "valid",

  "contact": [
"mailto:cert-ad...@example.com;,
"mailto:ad...@example.com;
  ],

  "orders": "https://example.com/acme/acct/1/orders;
}

(Both the Link header field and the "orders" URL)

Problem 5:

POST /acme/acct/1 HTTP/1.1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/1;,
"nonce": "ax5RnthDqp_Yf4_HZnFLmA",
"url": "https://example.com/acme/acct/1;
  }),
  "payload": base64url({
"contact": [
  "mailto:certifica...@example.com;,
  "mailto:ad...@example.com;
]
  }),
  "signature": "hDXzvcj8T6fbFbmn...rDzXzzvzpRy64N0o"
}

(The Request-URI and both URLs in the body)


Problem 6:


{
  "protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/1;,
"nonce": "S9XaOcxP5McpnTcWPIhYuB",
"url": "https://example.com/acme/key-change;
  }),
  "payload": base64url({
"protected": base64url({
  "alg": "ES256",
  "jwk": /* new key */,
  "url": "https://example.com/acme/key-change;
}),
"payload": base64url({
  "account": "https://example.com/acme/acct/1;,
  "oldKey": /* old key */
}),
"signature": "Xe8B94RD30Azj2ea...8BmZIRtcSKPSd8gU"
  }),
  "signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4"
}


Problem 7:


POST /acme/acct/1 HTTP/1.1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/1;,
"nonce": "ntuJWWSic4WVNSqeUmshgg",
"url": "https://example.com/acme/acct/1;
  }),
  "payload": base64url({
"status": "deactivated"
  }),
  "signature": "earzVLd3m5M4xJzR...bVTqn7R08AKOVf3Y"
}


Problem 8:


{
  "protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/1;,
"nonce": "5XJ1L3lEkMG7tR6pA00clA",
"url": "https://example.com/acme/new-order;
  }),
  "payload": base64url({
"identifiers": [
  { "type": "dns", "value": "example.com" }
],
"notBefore": "2016-01-01T00:04:00+04:00",
"notAfter": "2016-01-08T00:04:00+04:00"
  }),
  "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}


Problem 9:


{
  "protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/1;,
"nonce": "MSF2j2nawWHPxxkE3ZJtKQ",
"url": "https://example.com/acme/order/asdf/finalize;
  }),
  "payload": base64url({
"csr":

Re: [Acme] New Version Notification for draft-ietf-acme-acme-15.txt

2018-09-25 Thread Salz, Rich 
  *   This version incorporates the feedback from the IESG, most notably moving 
from to GET to POST-as-GET.


  *   Chairs / ADs - Where to from here?

@ekr, can you put this on the agenda again?  Or whatever is appropriate?

We did the WG review of all post-IESG changes.


On Tue, Sep 25, 2018 at 11:02 PM Richard Barnes  wrote:
This version incorporates the feedback from the IESG, most notably moving from 
to GET to POST-as-GET.

Chairs / ADs - Where to from here?

On Tue, Sep 25, 2018 at 10:50 PM 
mailto:internet-dra...@ietf.org>> wrote:

A new version of I-D, draft-ietf-acme-acme-15.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:   draft-ietf-acme-acme
Revision:   15
Title:  Automatic Certificate Management Environment (ACME)
Document date:  2018-09-25
Group:  acme
Pages:  89
URL:
https://www.ietf.org/internet-drafts/draft-ietf-acme-acme-15.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
Htmlized:   
https://tools..ietf.org/html/draft-ietf-acme-acme-15
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-15

Abstract:
   Public Key Infrastructure X.509 (PKIX) certificates are used for a
   number of purposes, the most significant of which is the
   authentication of domain names.  Thus, certification authorities
   (CAs) in the Web PKI are trusted to verify that an applicant for a
   certificate legitimately represents the domain name(s) in the
   certificate.  Today, this verification is done through a collection
   of ad hoc mechanisms.  This document describes a protocol that a CA
   and an applicant can use to automate the process of verification and
   certificate issuance.  The protocol also provides facilities for
   other certificate management functions, such as certificate
   revocation.

   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
   this draft is maintained in GitHub.  Suggested changes should be
   submitted as pull requests at 
https://github.com/ietf-wg-acme/acme
   [1].  Instructions are on that page as well.  Editorial changes can
   be managed in GitHub, but any substantive change should be discussed
   on the ACME mailing list (acme@ietf.org).




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] New Version Notification for draft-ietf-acme-acme-15.txt

2018-09-25 Thread Richard Barnes 
This version incorporates the feedback from the IESG, most notably moving
from to GET to POST-as-GET.

Chairs / ADs - Where to from here?

On Tue, Sep 25, 2018 at 11:02 PM Richard Barnes  wrote:

> This version incorporates the feedback from the IESG, most notably moving
> from to GET to POST-as-GET.
>
> Chairs / ADs - Where to from here?
>
> On Tue, Sep 25, 2018 at 10:50 PM  wrote:
>
>>
>> A new version of I-D, draft-ietf-acme-acme-15.txt
>> has been successfully submitted by Richard Barnes and posted to the
>> IETF repository.
>>
>> Name:   draft-ietf-acme-acme
>> Revision:   15
>> Title:  Automatic Certificate Management Environment (ACME)
>> Document date:  2018-09-25
>> Group:  acme
>> Pages:  89
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-acme-acme-15.txt
>> Status: https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
>> Htmlized:   https://tools.ietf.org/html/draft-ietf-acme-acme-15
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme
>> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-15
>>
>> Abstract:
>>Public Key Infrastructure X.509 (PKIX) certificates are used for a
>>number of purposes, the most significant of which is the
>>authentication of domain names.  Thus, certification authorities
>>(CAs) in the Web PKI are trusted to verify that an applicant for a
>>certificate legitimately represents the domain name(s) in the
>>certificate.  Today, this verification is done through a collection
>>of ad hoc mechanisms.  This document describes a protocol that a CA
>>and an applicant can use to automate the process of verification and
>>certificate issuance.  The protocol also provides facilities for
>>other certificate management functions, such as certificate
>>revocation.
>>
>>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
>>this draft is maintained in GitHub.  Suggested changes should be
>>submitted as pull requests at https://github.com/ietf-wg-acme/acme
>>[1].  Instructions are on that page as well.  Editorial changes can
>>be managed in GitHub, but any substantive change should be discussed
>>on the ACME mailing list (acme@ietf.org).
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] I-D Action: draft-ietf-acme-acme-15.txt

2018-09-25 Thread internet-drafts 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : Automatic Certificate Management Environment (ACME)
Authors : Richard Barnes
  Jacob Hoffman-Andrews
  Daniel McCarney
  James Kasten
Filename: draft-ietf-acme-acme-15.txt
Pages   : 89
Date: 2018-09-25

Abstract:
   Public Key Infrastructure X.509 (PKIX) certificates are used for a
   number of purposes, the most significant of which is the
   authentication of domain names.  Thus, certification authorities
   (CAs) in the Web PKI are trusted to verify that an applicant for a
   certificate legitimately represents the domain name(s) in the
   certificate.  Today, this verification is done through a collection
   of ad hoc mechanisms.  This document describes a protocol that a CA
   and an applicant can use to automate the process of verification and
   certificate issuance.  The protocol also provides facilities for
   other certificate management functions, such as certificate
   revocation.

   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
   this draft is maintained in GitHub.  Suggested changes should be
   submitted as pull requests at https://github.com/ietf-wg-acme/acme
   [1].  Instructions are on that page as well.  Editorial changes can
   be managed in GitHub, but any substantive change should be discussed
   on the ACME mailing list (acme@ietf.org).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-acme-15
https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme