Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Richard Barnes]

Thanks, Corey.  Updated the PR.

On Thu, Aug 30, 2018 at 9:01 AM Corey Bonnell 
wrote:

> Hello,
>
> I just wanted to point out that RFC 5234 defines a core set of production
> rules in Appendix B (https://tools.ietf.org/html/rfc5234#appendix-B) that
> define commonly used rules such as “DIGIT”, “ALPHA”, etc. Using them would
> make the base64url rule clearer:
>
>
>
> base64url = ALPHA / DIGIT / “-“ / “_”
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From: *Acme  on behalf of Richard Barnes
> 
> *Date: *Thursday, August 30, 2018 at 8:21 AM
> *To: *"Manger, James H" 
> *Cc: *IETF ACME 
> *Subject: *Re: [Acme] Alexey Melnikov's No Objection on
> draft-ietf-acme-acme-14: (with COMMENT)
>
>
>
> Thanks, James.  Fixed in the PR.
>
>
>
> On Wed, Aug 29, 2018 at 10:41 PM Manger, James <
> james.h.man...@team.telstra.com> wrote:
>
> >> base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
>
> > base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"
>
>
>
> “A” is %x41 (not %x40)
>
>
>
> --
>
> James Manger
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Corey Bonnell]

Hello,
I just wanted to point out that RFC 5234 defines a core set of production rules 
in Appendix B (https://tools.ietf.org/html/rfc5234#appendix-B) that define 
commonly used rules such as “DIGIT”, “ALPHA”, etc. Using them would make the 
base64url rule clearer:

base64url = ALPHA / DIGIT / “-“ / “_”

Thanks,
Corey

From: Acme  on behalf of Richard Barnes 
Date: Thursday, August 30, 2018 at 8:21 AM
To: "Manger, James H" 
Cc: IETF ACME 
Subject: Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: 
(with COMMENT)

Thanks, James.  Fixed in the PR.

On Wed, Aug 29, 2018 at 10:41 PM Manger, James 
mailto:james.h.man...@team.telstra.com>> wrote:
>> base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

> base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"

“A” is %x41 (not %x40)

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

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Richard Barnes]

Thanks, James.  Fixed in the PR.

On Wed, Aug 29, 2018 at 10:41 PM Manger, James <
james.h.man...@team.telstra.com> wrote:

> >> base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
>
> > base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"
>
>
>
> “A” is %x41 (not %x40)
>
>
>
> --
>
> James Manger
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Tim Hollebeek]

For what it’s worth, there’s a discussion going on in the validation working 
group right now about how redirects should be handled.  The most likely outcome 
is either pretty severe restrictions around redirects, or completely 
disallowing them.  

 

In the interest of openness, CAs were asked to disclose their current redirect 
behavior as a basis for a discussion about what the requirements should be.  
Two CAs have done so.  Others are strongly encouraged to do so.

 

There is no explicit text allowing them, so it could be argued that the BRs 
currently don’t allow following redirects.  On the other hand, redirects are 
part of HTTP, so the argument can also be made that “retrieving a web page” can 
involve arbitrary redirects, including potentially things like meta refresh and 
javascript.  The fact that such a diverse range of interpretations are possible 
is something we’d love to fix.

 

In particular, non-HTTP redirects that involve parsing page content introduce a 
great deal of complexity and risk into the validation process, and I’d like to 
clarify that that definitely isn’t allowed.

 

Redirects to a location outside of the domain being validated are viewed with 
particular suspicion by many, including me.  Redirects within the same domain 
seem less problematic, and indeed useful for handling large numbers of domains. 
 Though it’s not clear this solves a use case that is not already handled by 
the ability to validate and Authorization Domain Name and use it for subdomains.

 

The main reason to allow redirects within a domain is if there is a unilateral 
redirect from example.com to www.example.com <http://www.example.com> , which 
is of course incredibly common.  It seems one should be able to validate 
example.com using that redirect.

 

At least one large CA supports the “no redirects at all” position.

 

-Tim

 

From: Acme  On Behalf Of Richard Barnes
Sent: Wednesday, August 29, 2018 7:10 PM
To: Salz, Rich 
Cc: Alexey Melnikov ; draft-ietf-acme-a...@ietf.org; 
IETF ACME ; Daniel McCarney ; Yoav Nir 
; The IESG ;  
; Alexey Melnikov 
Subject: Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: 
(with COMMENT)

 

I noticed that we already had some text in the security considerations about 
redirects, so I reverted to SHOULD and added a forward pointer.

 

> More limited forms of delegation can also lead to an unintended
> party gaining the ability to successfully complete a validation
> transaction. For example, suppose an ACME server follows HTTP
> redirects in HTTP validation and a website operator provisions a
> catch-all redirect rule that redirects requests for unknown
> resources to a different domain. Then the target of the redirect
> could use that to get a certificate through HTTP validation since
> the validation path will not be known to the primary server.

 

https://github.com/ietf-wg-acme/acme/pull/442/files#diff-8430e2aa241beb4ac49b252db20d4ee8R2492

 

Alexey: Can you live with this solution?  There is some residual interop risk, 
but (1) that's kind of unavoidable given the uncertainty here, and (2) 
redirects are an easy-ish thing to debug and adapt if there's a mismatch.  And 
at least the reasoning is pretty well documented now.

 

--Richard

 

On Wed, Aug 29, 2018 at 12:55 PM Salz, Rich mailto:rs...@akamai.com> > wrote:

I read the link you posted, thanks.

 

As long as we’re not breaking the HTTP spec, I agree that SHOULD seems to get 
the most interop.  As long as we’re getting signed reponses back, I don’t think 
it matters much where the redirect sends you.

 



smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Manger, James]

>> base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

> base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"

“A” is %x41 (not %x40)

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

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Alan Doherty]

At 17:07 29/08/2018  Wednesday, Daniel McCarney wrote:
>>Â I think SHOULD basically makes redirects non interoperable. I think a bit 
>>more text explaining why SHOULD or change this to MUST. Also, if there are 
>>some security issues related to redirects, adding a pointer here would be 
>>good.
>
>
>I'm slightly adverse to changing this to a MUST. There's been some recent 
>discussion[0] on redirects in domain validation by the CA/Browser Forum 
>validation working group that makes it pretty clear there isn't a universal 
>agreement on how CA's should handle redirects. While I disagree with the 
>proposals to ban following redirects outright 

I would hate if they ever do (as getting dumb devices to redirect 
http://whatever/.well-known/acme-callenge/* to smarter http server(running the 
acme client) and http://whatever/* to https://whatever/  for normal users

is a lot easier than getting them redeveloped to serve custom content 
(challenge response) or run native acme-client

(as all my dumb devices needing certs currently do with some tweaking, then 
acme-client just uploads/reconfigs new cert when done)

>there is a possibility that consensus goes that direction and a MUST for 
>processing redirects in ACME could be problematic.
>
>Unfortunately I think this is a case where some CAs will decide following 
>redirects in certain conditions is acceptable and where other CAs will decide 
>to never follow a redirect and ACME shouldn't prescribe CA policy. 
>
>I understand that this makes provisioning a challenge response such that it 
>will be inter-operable with all ACME CAs more difficult but there are a number 
>of ways I expect this would be challenging beyond support for redirects (e.g. 
>one CA may heed the recommendation to use DNSSEC and one may not. A challenge 
>response provisioned behind a domain with an invalid DNSSEC configuration 
>would not interoperate).
>
>
>[0] -Â 
>https://cabforum.org/pipermail/validation/2018-August/000990.html
>
>On Wed, Aug 29, 2018 at 11:26 AM, Alexey Melnikov 
><alexey.melni...@isode.com> wrote:
>
>Hi Richard,
>On 29/08/2018 16:03, Richard Barnes wrote:
>>Hi Alexey,
>>
>>Thanks for the comments.  A couple of replies are below; resulting edits are 
>>in this PR:
>>
>>https://github.com/ietf-wg-acme/acme/pull/442
>
>
>I deleted comments where we are in agreement. More comments below:
>>
>>--Richard
>>
>>
>>On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov 
>><aamelni...@fastmail.fm> wrote:
>>Alexey Melnikov has entered the following ballot position for
>>draft-ietf-acme-acme-14: No Objection
>>
>>When responding, please keep the subject line intact and reply to all
>>email addresses included in the To and CC lines. (Feel free to cut this
>>introductory paragraph, however.)
>>
>>
>>Please refer to 
>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>>for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>>The document, along with other ballot positions, can be found here:
>>https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
>>
>>
>>
>>--
>>COMMENT:
>>--
>>
>>Thank you for this very important document. I would like to switch to "Yes",
>>but please first review and respond to my comments:
>>
>>First mentions of JSON and HTTPS need references.
>>
>>6.4.1.  Replay-Nonce
>>
>>Â  Â The "Replay-Nonce" header field includes a server-generated value
>>Â  Â that the server can use to detect unauthorized replay in future
>>   client requests.  The server MUST generate the value provided in
>>Â  Â Replay-Nonce in such a way that they are unique to each message, with
>>   high probability.  For instance, it is acceptable to generate Replay-
>>Â  Â Nonces randomly.
>>
>>Â  Â The value of the Replay-Nonce field MUST be an octet string encoded
>>Â  Â according to the base64url encoding described in Section 2 of
>>   [RFC7515].  Clients MUST ignore invalid Replay-Nonce values.  The
>>Â  Â ABNF [RFC5234] for the Replay-Nonce header field follows:
>>
>>Â  Â  Â base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
>>
>>This is not correct ABNF. Change range syntax in Section 3.4 of RFC 5234
>>
>>
>>I've updated to try to fix this, but your review on the PR would be 
>>appreciated.
>
>The correct form is (I didn't check if you usxe correct hex values):
>
>base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"
>
>(I.e., don't include "%x" after "-" and don't have spaces before or after 
>"-".) BTW, you can use "BAP"on tools.ietf.org to verify 
>ABNF.
>
>
>>Â 
>>Please add normative references for Retry-After 

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Benjamin Kaduk]

On Wed, Aug 29, 2018 at 04:55:09PM +, Salz, Rich wrote:
> I read the link you posted, thanks.
> 
> As long as we’re not breaking the HTTP spec, I agree that SHOULD seems to get 
> the most interop.  As long as we’re getting signed reponses back, I don’t 
> think it matters much where the redirect sends you.

Maybe I just missed it, but are we getting a signed response back?  I
thought it was just the plaintext key authorization.

-Benjamin

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

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Richard Barnes]

I noticed that we already had some text in the security considerations
about redirects, so I reverted to SHOULD and added a forward pointer.

> More limited forms of delegation can also lead to an unintended
> party gaining the ability to successfully complete a validation
> transaction. For example, suppose an ACME server follows HTTP
> redirects in HTTP validation and a website operator provisions a
> catch-all redirect rule that redirects requests for unknown
> resources to a different domain. Then the target of the redirect
> could use that to get a certificate through HTTP validation since
> the validation path will not be known to the primary server.

https://github.com/ietf-wg-acme/acme/pull/442/files#diff-8430e2aa241beb4ac49b252db20d4ee8R2492

Alexey: Can you live with this solution?  There is some residual interop
risk, but (1) that's kind of unavoidable given the uncertainty here, and
(2) redirects are an easy-ish thing to debug and adapt if there's a
mismatch.  And at least the reasoning is pretty well documented now.

--Richard

On Wed, Aug 29, 2018 at 12:55 PM Salz, Rich  wrote:

> I read the link you posted, thanks.
>
>
>
> As long as we’re not breaking the HTTP spec, I agree that SHOULD seems to
> get the most interop.  As long as we’re getting signed reponses back, I
> don’t think it matters much where the redirect sends you.
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Salz, Rich]

I read the link you posted, thanks.

As long as we’re not breaking the HTTP spec, I agree that SHOULD seems to get 
the most interop.  As long as we’re getting signed reponses back, I don’t think 
it matters much where the redirect sends you.

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

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Daniel McCarney]

>
> > I think SHOULD basically makes redirects non interoperable. I think a
> bit more text explaining why SHOULD or change this to MUST. Also, if there
> are some security issues related to redirects, adding a pointer here would
> be good.
>

I'm slightly adverse to changing this to a MUST. There's been some recent
discussion[0] on redirects in domain validation by the CA/Browser Forum
validation working group that makes it pretty clear there isn't a universal
agreement on how CA's should handle redirects. While I disagree with the
proposals to ban following redirects outright there is a possibility that
consensus goes that direction and a MUST for processing redirects in ACME
could be problematic.

Unfortunately I think this is a case where some CAs will decide following
redirects in certain conditions is acceptable and where other CAs will
decide to never follow a redirect and ACME shouldn't prescribe CA policy.

I understand that this makes provisioning a challenge response such that it
will be inter-operable with all ACME CAs more difficult but there are a
number of ways I expect this would be challenging beyond support for
redirects (e.g. one CA may heed the recommendation to use DNSSEC and one
may not. A challenge response provisioned behind a domain with an invalid
DNSSEC configuration would not interoperate).


[0] - https://cabforum.org/pipermail/validation/2018-August/000990.html

On Wed, Aug 29, 2018 at 11:26 AM, Alexey Melnikov  wrote:

> Hi Richard,
> On 29/08/2018 16:03, Richard Barnes wrote:
>
> Hi Alexey,
>
> Thanks for the comments.  A couple of replies are below; resulting edits
> are in this PR:
>
> https://github.com/ietf-wg-acme/acme/pull/442
>
>
> I deleted comments where we are in agreement. More comments below:
>
>
> --Richard
>
>
> On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov 
> wrote:
>
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-acme-acme-14: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Thank you for this very important document. I would like to switch to
>> "Yes",
>> but please first review and respond to my comments:
>>
>> First mentions of JSON and HTTPS need references.
>>
>> 6.4.1.  Replay-Nonce
>>
>>The "Replay-Nonce" header field includes a server-generated value
>>that the server can use to detect unauthorized replay in future
>>client requests.  The server MUST generate the value provided in
>>Replay-Nonce in such a way that they are unique to each message, with
>>high probability.  For instance, it is acceptable to generate Replay-
>>Nonces randomly.
>>
>>The value of the Replay-Nonce field MUST be an octet string encoded
>>according to the base64url encoding described in Section 2 of
>>[RFC7515].  Clients MUST ignore invalid Replay-Nonce values.  The
>>ABNF [RFC5234] for the Replay-Nonce header field follows:
>>
>>  base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
>>
>> This is not correct ABNF. Change range syntax in Section 3.4 of RFC 5234
>>
>
> I've updated to try to fix this, but your review on the PR would be
> appreciated.
>
> The correct form is (I didn't check if you usxe correct hex values):
>
> base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"
>
> (I.e., don't include "%x" after "-" and don't have spaces before or after
> "-".) BTW, you can use "BAP"on tools.ietf.org to verify ABNF.
>
>
>
>
>> Please add normative references for Retry-After and Link header fields.
>>
>
> These already have normative references at their first appearance:
>
> https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.5
>
> Do you think those references are incorrect?
>
>
> I was reading out of order, so this is fine. But a new nit: "header" -->
> "header field". ("Header" is a collection of all HTTP header fields present
> in a request or response).
>
>
>
>
>> In 7.1.2:
>>
>>contact (optional, array of string):  An array of URLs that the
>>
>> Which URI schemes are allowed (or at least expected) here?
>>
>
> Basically, servers must support "mailto", and may support others; they can
> specify their requirements in an error message.
>
> You don't mention "mailto:; till later and you don't even mention "tel:".
> I appreciate that you don't want to have an exhaustive list here, but I
> think you should still provide a bit more guidance.
>
> 

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Alexey Melnikov]

Hi Richard,

On 29/08/2018 16:03, Richard Barnes wrote:

Hi Alexey,

Thanks for the comments.  A couple of replies are below; resulting 
edits are in this PR:


https://github.com/ietf-wg-acme/acme/pull/442



I deleted comments where we are in agreement. More comments below:



--Richard


On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov 
mailto:aamelni...@fastmail.fm>> wrote:


Alexey Melnikov has entered the following ballot position for
draft-ietf-acme-acme-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut
this
introductory paragraph, however.)


Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/



--
COMMENT:
--

Thank you for this very important document. I would like to switch
to "Yes",
but please first review and respond to my comments:

First mentions of JSON and HTTPS need references.

6.4.1.  Replay-Nonce

   The "Replay-Nonce" header field includes a server-generated value
   that the server can use to detect unauthorized replay in future
   client requests.  The server MUST generate the value provided in
   Replay-Nonce in such a way that they are unique to each
message, with
   high probability.  For instance, it is acceptable to generate
Replay-
   Nonces randomly.

   The value of the Replay-Nonce field MUST be an octet string encoded
   according to the base64url encoding described in Section 2 of
   [RFC7515].  Clients MUST ignore invalid Replay-Nonce values.  The
   ABNF [RFC5234] for the Replay-Nonce header field follows:

     base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

This is not correct ABNF. Change range syntax in Section 3.4 of
RFC 5234


I've updated to try to fix this, but your review on the PR would be 
appreciated.


The correct form is (I didn't check if you usxe correct hex values):

base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"

(I.e., don't include "%x" after "-" and don't have spaces before or 
after "-".) BTW, you can use "BAP"on tools.ietf.org to verify ABNF.





Please add normative references for Retry-After and Link header
fields.


These already have normative references at their first appearance:

https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.5

Do you think those references are incorrect?



I was reading out of order, so this is fine. But a new nit: "header" --> 
"header field". ("Header" is a collection of all HTTP header fields 
present in a request or response).




In 7.1.2:

   contact (optional, array of string):  An array of URLs that the

Which URI schemes are allowed (or at least expected) here?


Basically, servers must support "mailto", and may support others; they 
can specify their requirements in an error message.


You don't mention "mailto:; till later and you don't even mention 
"tel:". I appreciate that you don't want to have an exhaustive list 
here, but I think you should still provide a bit more guidance.



https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-7.3

The WG discussed this and decided not to have more negotiation here.  
See, e.g.:


https://mailarchive.ietf.org/arch/msg/acme/TW8sbspUIGDGbIldaqWW0k9jKYo


That is fine.




(Similar text in other sections!)


I don't see "sort order" anywhere else, or other relevant usage of 
"order".  Do you have other places in mind?


This might have existed in earlier versions. I will double check.



In 8.3:

   The server SHOULD follow redirects when dereferencing the URL.

Why only a SHOULD?


Some server operators wanted to have the option to require that the 
validation work on the first request.



I think SHOULD basically makes redirects non interoperable. I think a 
bit more text explaining why SHOULD or change this to MUST. Also, if 
there are some security issues related to redirects, adding a pointer 
here would be good.




9.6.  URN Sub-namespace for ACME (urn:ietf:params:acme)

   Repository:  URL-TBD

Who needs to fix this value?


There's a request to the RFC editor below.



Ok.



9.7.1.  Fields in Account Objects

   o  Field type: The type of value to be provided, e.g.., string,
      boolean, array of string

Here and in all similar registries: I think you should insert
"JSON" before
"type" to make it clear that types are only restricted to JSON
type choices.


It's a JSON object.  If you define a non-JSON type, you're gonna have 
a bad time.



Maybe I am dealing with too much 

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Richard Barnes]

Hi Alexey,

Thanks for the comments.  A couple of replies are below; resulting edits
are in this PR:

https://github.com/ietf-wg-acme/acme/pull/442

--Richard


On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov 
wrote:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-acme-acme-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for this very important document. I would like to switch to
> "Yes",
> but please first review and respond to my comments:
>
> First mentions of JSON and HTTPS need references.
>
> 6.4.1.  Replay-Nonce
>
>The "Replay-Nonce" header field includes a server-generated value
>that the server can use to detect unauthorized replay in future
>client requests.  The server MUST generate the value provided in
>Replay-Nonce in such a way that they are unique to each message, with
>high probability.  For instance, it is acceptable to generate Replay-
>Nonces randomly.
>
>The value of the Replay-Nonce field MUST be an octet string encoded
>according to the base64url encoding described in Section 2 of
>[RFC7515].  Clients MUST ignore invalid Replay-Nonce values.  The
>ABNF [RFC5234] for the Replay-Nonce header field follows:
>
>  base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
>
> This is not correct ABNF. Change range syntax in Section 3.4 of RFC 5234
>

I've updated to try to fix this, but your review on the PR would be
appreciated.



>  Replay-Nonce = *base64url
>
> You allow for empty nonce here. Should this be "1*base64url"?
>

Done.


Please add normative references for Retry-After and Link header fields.
>

These already have normative references at their first appearance:

https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.5

Do you think those references are incorrect?


In Section 6.6:
>
>   | unsupportedIdentifier   | Identifier is not supported, but may be |
>| | in future
>
> Do you mean "identifier type", not identifier?
>

Done.


   This list is not exhaustive.  The server MAY return errors whose
>"type" field is set to a URI other than those defined above.  Servers
>MUST NOT use the ACME URN namespace Section 9.6 for errors other than
>the standard types.
>
> I think this text is misleading, as you create a registry for these.
> I suggest you rephrase and add a reference to the registry.
>

Clarified that the MUST NOT means "don't use unregistered values"



> In 7.1.1:
>
>caaIdentities (optional, array of string):  Each string MUST be a
>   lowercase hostname which the ACME server recognizes as referring
>
> Is hostname fully qualified? U-label IDNA domains not allowed here? Please
> clarify.
>

These are only provided for matching against CAA records (RFC 6844), so the
simplest thing is to just require that they be equal.  In practice, that
means ASCII-names.



>   to itself for the purposes of CAA record validation as defined in
>   [RFC6844].  This allows clients to determine the correct issuer
>   domain name to use when configuring CAA records.
>
> Example in 7.1.1 (or maybe even earlier): You probably should say that some
> header fields are omitted here.
>

I think that is clear enough from context.



> In 7.1.2:
>
>contact (optional, array of string):  An array of URLs that the
>
> Which URI schemes are allowed (or at least expected) here?
>

Basically, servers must support "mailto", and may support others; they can
specify their requirements in an error message.

https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-7.3

The WG discussed this and decided not to have more negotiation here.  See,
e.g.:

https://mailarchive.ietf.org/arch/msg/acme/TW8sbspUIGDGbIldaqWW0k9jKYo



>   server can use to contact the client for issues related to this
>   account.  For example, the server may wish to notify the client
>   about server-initiated revocation or certificate expiration.
>
> In 7.4:
>
>Clients SHOULD NOT make any assumptions about the sort order of
>"identifiers" or "authorizations" elements in the returned order
>object.
>
> Why is this a SHOULD NOT and not a MUST NOT?
>

Done.


(Similar text in other sections!)
>

I don't see "sort order" anywhere else, or other relevant usage of
"order".  Do you have other places in mind?



>
> 7.4.2.  Downloading the Certificate
>
>GET /acme/cert/asdf 

[Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-acme-acme-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/



--
COMMENT:
--

Thank you for this very important document. I would like to switch to "Yes",
but please first review and respond to my comments:

First mentions of JSON and HTTPS need references.

6.4.1.  Replay-Nonce

   The "Replay-Nonce" header field includes a server-generated value
   that the server can use to detect unauthorized replay in future
   client requests.  The server MUST generate the value provided in
   Replay-Nonce in such a way that they are unique to each message, with
   high probability.  For instance, it is acceptable to generate Replay-
   Nonces randomly.

   The value of the Replay-Nonce field MUST be an octet string encoded
   according to the base64url encoding described in Section 2 of
   [RFC7515].  Clients MUST ignore invalid Replay-Nonce values.  The
   ABNF [RFC5234] for the Replay-Nonce header field follows:

 base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

This is not correct ABNF. Change range syntax in Section 3.4 of RFC 5234

 Replay-Nonce = *base64url

You allow for empty nonce here. Should this be "1*base64url"?

Please add normative references for Retry-After and Link header fields.

In Section 6.6:

  | unsupportedIdentifier   | Identifier is not supported, but may be |
   | | in future

Do you mean "identifier type", not identifier?

   This list is not exhaustive.  The server MAY return errors whose
   "type" field is set to a URI other than those defined above.  Servers
   MUST NOT use the ACME URN namespace Section 9.6 for errors other than
   the standard types.

I think this text is misleading, as you create a registry for these.
I suggest you rephrase and add a reference to the registry.

In 7.1.1:

   caaIdentities (optional, array of string):  Each string MUST be a
  lowercase hostname which the ACME server recognizes as referring

Is hostname fully qualified? U-label IDNA domains not allowed here? Please
clarify.

  to itself for the purposes of CAA record validation as defined in
  [RFC6844].  This allows clients to determine the correct issuer
  domain name to use when configuring CAA records.

Example in 7.1.1 (or maybe even earlier): You probably should say that some
header fields are omitted here.

In 7.1.2:

   contact (optional, array of string):  An array of URLs that the

Which URI schemes are allowed (or at least expected) here?

  server can use to contact the client for issues related to this
  account.  For example, the server may wish to notify the client
  about server-initiated revocation or certificate expiration.

In 7.4:

   Clients SHOULD NOT make any assumptions about the sort order of
   "identifiers" or "authorizations" elements in the returned order
   object.

Why is this a SHOULD NOT and not a MUST NOT?

(Similar text in other sections!)

7.4.2.  Downloading the Certificate

   GET /acme/cert/asdf HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert

I think your example is wrong, as Accept value needs to match
application/pem-certificate-chain returned below:

   HTTP/1.1 200 OK
   Content-Type: application/pem-certificate-chain
   Link: ;rel="index"

   -BEGIN CERTIFICATE-
   [End-entity certificate contents]
   -END CERTIFICATE-
   -BEGIN CERTIFICATE-
   [Issuer certificate contents]
   -END CERTIFICATE-
   -BEGIN CERTIFICATE-
   [Other certificate contents]
   -END CERTIFICATE-

In 8.3:

   The server SHOULD follow redirects when dereferencing the URL.

Why only a SHOULD?

9.1.  MIME Type: application/pem-certificate-chain

   The "Media Types" registry should be updated with the following
   additional value:

   MIME media type name: application

   MIME subtype name: pem-certificate-chain

   Required parameters: None

   Optional parameters: None

   Encoding considerations: None

This value has to be one of "7bit", "8bit", "binary" or "framed". I think this
should be "7bit", as PEM is ASCII.

   Security considerations: Carries a cryptographic certificate and its
   associated certificate chain

I suggest you add text saying that this media type doesn't include active
content.

   Interoperability considerations: None

   Published specification: draft-ietf-acme-acme [[ RFC EDITOR: Please