Re: [Acme] ACME draft is now in WGLC.

[Richard Barnes]

On Sat, Mar 18, 2017 at 1:08 PM, Phillip Hallam-Baker  wrote:

>
>
> On Tue, Mar 14, 2017 at 2:24 PM, Richard Barnes  wrote:
>
>>
>>
>> On Tue, Mar 14, 2017 at 12:24 PM, Hugo Landau 
>> wrote:
>>
>>> > > The CAA check is/was easy to make and crippling it
>>> > > by not making it a requirement was IMNSHO a mistake.
>>> > ...
>>> > > I urge the WG to reconsider.
>>> >
>>> > Does anyone else agree with Viktor?  Please speak up on the list this
>>> week if so.
>>>
>>> I'd agree that the CAA check should be made mandatory. At least, I can't
>>> think of any good reason why it shouldn't be.
>>>
>>
>> I very strongly disagree.  What checks the CA does before issuing is up
>> to the CA's policy.  This document provides tools for CAs to do those
>> checks; it does not constrain what CAs do.
>>
>>
>>
>>> I'd also agree that the use of a DNSSEC-validating resolver accessed via
>>> a trusted network (preferably localhost) should be mandatory.
>>>
>>
>> Likewise.
>>
>> ​​
>> --Richard
>>
>
> ​If that were so, why does ACME have any support for DNS validat​ion? It
> is merely CA policy after all.
>
> The point of CAA is that it is the one mechanism that is provided to allow
> domain owners to signal to third parties what parties they authorize to
> issue certs.
>
> In my view CAA should be mandatory for the reasons above.
>
> The other reason for making CAA mandatory is that if we are going to fully
> automate the issue process, we might well want to use information in the
> CAA records to facilitate that. That was the reason I thought Paul
> Hoffman's idea of using the DNS name rather than a policy oid or some PKIX
> identifier was the right approach.
>

This specification has always been focused on providing tools for CAs,
*not* on constraining what CAs must do.  What MUSTs there are in the
specification are to make clear the mechanisms that the specifications
define, not to specify CA policy.

CAA is clearly on the other side of that line -- it's not a part of the
mechanisms we define in this specification, but a totally separate
mechanism that CAs apply to vet requests.  It's much more like high-value
name checking than DNS validation.

I would be fine adding a line to the "CA Policy Considerations" section
[1], which is where other similar things have gone.

To be clear: I think CAA checking is a good idea, and I'm delighted that
CABF recently decided to require it [2].  I just don't think it's
appropriate for ACME to require it.

--Richard


[1] https://ietf-wg-acme.github.io/acme/#rfc.section.10.5
[2] https://cabforum.org/pipermail/public/2017-March/009988.html
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME draft is now in WGLC -- require CAA ?

[Hugo Landau]

> Have you seen the thread on the LAMPS (SPASM) mailing list, titled
> "CAA Erratum 4515"?  That raises some technical issues, which make me
> (as an individual at least) think it's premature.
I wasn't aware of this.

However, as far as I'm aware mandatory CAA checking is now a done deal:
https://cabforum.org/pipermail/public/2017-March/009988.html

I'd therefore argue it isn't premature, a) because CAs are going to have
to implement it by September anyway, b) because it's already used in
production (Let's Encrypt) successfully.

In light of the CAB Forum resolution, the additional utility of adding a
normative requirement to the ACME RFC is marginal, so I'm no longer
terribly bothered either way, though still ultimately in favour.

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

Re: [Acme] ACME draft is now in WGLC -- require CAA ?

[Salz, Rich]

 
> I'd agree that the CAA check should be made mandatory. At least, I can't
> think of any good reason why it shouldn't be.

Have you seen the thread on the LAMPS (SPASM) mailing list, titled "CAA Erratum 
4515"?  That raises some technical issues, which make me (as an individual at 
least) think it's premature.
 
> I'd also agree that the use of a DNSSEC-validating resolver accessed via a
> trusted network (preferably localhost) should be mandatory.

This is a separate issue, please start a separate thread.

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

Re: [Acme] ACME draft is now in WGLC.

[Hugo Landau]

> > The CAA check is/was easy to make and crippling it
> > by not making it a requirement was IMNSHO a mistake.
> ...
> > I urge the WG to reconsider.
> 
> Does anyone else agree with Viktor?  Please speak up on the list this week if 
> so.

I'd agree that the CAA check should be made mandatory. At least, I can't
think of any good reason why it shouldn't be.

I'd also agree that the use of a DNSSEC-validating resolver accessed via
a trusted network (preferably localhost) should be mandatory.

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

Re: [Acme] ACME draft is now in WGLC.

[Viktor Dukhovni]

On Mon, Mar 13, 2017 at 02:00:40PM -0700, Jacob Hoffman-Andrews wrote:

> > by CA/B forum as a "recommendation", which meant that the constraint
> > was meaningless.  Rumour has it that CAA will soon be a requirement,
> > so I've now published CAA records.  The CAA check is/was easy to
> > make and crippling it by not making it a requirement was IMNSHO a
> > mistake.
>
> I think by this you mean that the CA/Browser Forum should have mandated
> CAA support in its Baseline Requirements, back when it first adopted CAA
> as "recommended." Is that right?

Yes.

> I think the analogous goal here is that you'd like the CA/Browser Forum
> to mandate use of a DNSSEC-validating recursive resolver during
> DNS-based validation procedures.

No, dragging the CA/B forum into this discussion (by way of analogy)
was perhaps a mistake.  I am trying to say is that wiggle room to
not do DNSSEC ACME serves no purpose.  ACME should *require* DNSSEC
resolvers in *ACME conformant CAs.

> That's great! However, I don't think mandating use of a DNSSEC-validating
> resolver in the ACME spec will achieve that goal, since the CA/Browser
> Forum is not planning to mandate use of the ACME spec.

Convincing non-ACME CAs that issue DV certs do use DNSSEC for DNS
challenges is a separate issue (windmill for my Quixotic battles)
and is out of scope for this group.  So one thing at a time, I urge
the ACME WG to require DNSSEC for DNS challenges, so that security
of DNSSEC signed domains is not downgraded by ACME CAs negligently
running security-oblivious resolvers.

-- 
Viktor.

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

Re: [Acme] ACME draft is now in WGLC.

[Jacob Hoffman-Andrews]

As Rich said, the CA/Browser Forum has indeed voted to mandate CAA. Hooray!

On 03/13/2017 01:14 PM, Viktor Dukhovni wrote:
> I've had complete disinterest in CAA which initially was accepted
> by CA/B forum as a "recommendation", which meant that the constraint
> was meaningless.  Rumour has it that CAA will soon be a requirement,
> so I've now published CAA records.  The CAA check is/was easy to
> make and crippling it by not making it a requirement was IMNSHO a
> mistake.
I think by this you mean that the CA/Browser Forum should have mandated
CAA support in its Baseline Requirements, back when it first adopted CAA
as "recommended." Is that right?

I think the analogous goal here is that you'd like the CA/Browser Forum
to mandate use of a DNSSEC-validating recursive resolver during
DNS-based validation procedures. That's great! However, I don't think
mandating use of a DNSSEC-validating resolver in the ACME spec will
achieve that goal, since the CA/Browser Forum is not planning to mandate
use of the ACME spec.

I realize that the CA/Browser Forum seems relatively opaque and hard to
participate in, but if you check their bylaws it is possible for any
member of the public (not just a CA or a Browser) to directly
participate in the mailing list by submitting a simple form. I'd
encourage you to get involved!

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

Re: [Acme] ACME draft is now in WGLC.

[Salz, Rich]

> Rumour has it that CAA will soon be a requirement

It just passed their balloting so CA/B forum now requires it.  See the LAMPS WG 
thread(s) on CAA erratum 4515.

> The CAA check is/was easy to make and crippling it
> by not making it a requirement was IMNSHO a mistake.
...
> I urge the WG to reconsider.

Does anyone else agree with Viktor?  Please speak up on the list this week if 
so.

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

Re: [Acme] ACME draft is now in WGLC.

[Viktor Dukhovni]

On Tue, Feb 07, 2017 at 05:27:48PM +, Salz, Rich wrote:

> I put the time period as six weeks, which takes us to just around IETF-98...
> 
> PLEASE reply on list if you will review and/or are interested in working on 
> interop. 

I see there's no reference to use of DNSSEC resolvers by CAs that
implement DNS challenges.  Just a suggestion to send probes from
multiple networks to avoid MiTM attacks, which seems rather weak
to me.  The MiTM might be collocated near the victim rather than
the CA.

There was some brief discussion of DNSSEC back in Oct/2015:

https://www.ietf.org/mail-archive/web/acme/current/thrd3.html#00561

https://www.ietf.org/mail-archive/web/acme/current/msg00561.html
https://www.ietf.org/mail-archive/web/acme/current/msg00562.html
https://www.ietf.org/mail-archive/web/acme/current/msg00563.html
https://www.ietf.org/mail-archive/web/acme/current/msg00564.html
https://www.ietf.org/mail-archive/web/acme/current/msg00565.html
https://www.ietf.org/mail-archive/web/acme/current/msg00729.html

but no further action.  Is there a compellng reason to avoid
requiring acme CAs to spin up a validating resolver?  It does not
seem like a lot to ask.  If a domain is DNSSEC-signed then its ACME
challenge should IMHO be validated via DNSSEC.

-- 
Viktor.

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

Re: [Acme] ACME draft is now in WGLC.

[Jacob Hoffman-Andrews]

On 02/12/2017 10:09 PM, Anders Rundgren wrote:
> JWS is great for what is was originally designed for.  ES6 normalization
> nullifies the need for dressing JSON data in Base64Url.
Could you clarify this comment? Are you proposing that ACME should not
wrap internal fields in another layer of base64url? Or that the JWS spec
should be revised to not wrap payloads in base64url?

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

Re: [Acme] ACME draft is now in WGLC.

[Russ Housley]

Rich asked to me to divide my comments into technical and editorial.  This are 
the same comment that I sent earlier with that categorization.

Russ

= = = = = = = =

TECHNICAL

In Section 5.1, I think it is desirable to add a requirement that the ACME 
server SHOULD OCSP Staple.

In Section 5.5, please add a MUST statement about the size of the nonce value 
(before base64url encoding).

In Section 6.1.1, how does the key-change entry in the table in section 6.1.1 
relate to the figure in Section 6.1?  The other entries in this table seem to 
have an obvious companion in the figure.  I think the figure should to show how 
the key-change is used update the acct.

Section 6.1.1 says:

  "caa-identities" (optional, array of string):  Each string MUST be a
 lowercase hostname ...

How are IDNs handled?  Are all U-labels converted to A-labels?

Section 6.1.3 says:

  status (required, string):  The status of this order.  Possible
 values are: "pending", "processing", "valid", and "invalid".

Should the list of possible status strings should also include "expired"?  If 
not, the text should say that the status will be set to invalid if the 
authorizations are not accomplished before the expiration time.

Section 6.1.4 says:

  ...  Servers MUST verify any identifier values that
  begin with the ASCII Compatible Encoding prefix "xn-" as defined in
  [RFC5890] are properly encoded.  ...

I think you want to require the A-labels to be converted to U-labels and back 
again, and then reject the label if the converted A-label does not match the 
original A-label.

In Section 6.3.3, the list of steps clearly includes checking the signature on 
the inner JWS in step 4, but I do not see a step that checks the signature on 
the outer JWS.  I think the both signature checks need to be explicit in the 
steps.

Is an additional subsection in Section 6.3 needed to deal with lost account 
signature private keys?  I assume that some out-of-band mechanism would be 
needed to delete the account so that a new one can be created.

Section 6.4.2 says:

  The default format of the certificate is PEM (application/x-pem-file)
  as specified by [RFC7468]. ... The client may request other formats by
  including an Accept header in its request.  For example, the client
  may use the media type application/pkix-cert to request the end-
  entity certificate in DER format.

RFC 7468 defines the textual encoding for certificates, but it does not define 
the application/x-pem-file media type.  I cannot find a registration for the 
application/x-pem-file media type.

Also, please add a reference to RFC 2585; it specifies the 
application/pkix-cert media type.

In Section 8.2, I cannot understand the figure.  Please correct it.


EDITORIAL

Please use the terminology from RFC 5280.  Throughout the document:
  s/certificate authority/certification authority/
  s/issuing authority/certificate issuer/

Also, please use the correct expansion for PKIX (PKI using X.509).

In Section 1, please define ACME.

Also in Section 1:
s/Certificates in the Web PKI [RFC5280]/Certificates [RFC5280] in the Web PKI/

In Section 5.2, please repeat the reference for the JWS specification at the 
front of this section.

Section 5.2 says:

  In the examples below, JWS objects are shown in the JSON or flattened
  JSON serialization, with the protected header and payload expressed
  as base64url(content) instead of the actual base64-encoded value, so
  that the content is readable.  Some fields are omitted for brevity,
  marked with "...".

The example is above this text (below), and there is no "..." in it.

Section 6.1.1: s/function as both an ACME/functions as both an ACME/

Section 6.1.2: s/associated to an account/associated with an account/

Section 6.1.4 says:

  scope (optional, string):  If this field is present, then it MUST
 contain a URI for an order resource, such that this authorization
 is only valid for that resource.  If this field is absent, then
 the CA MUST consider this authorization valid for all orders until
 the authorization expires. [[ Open issue: More flexible scoping?
 ]]

This scoping seems fine.  Please remove the [[ question ]].

In Section 6.5, should the example use different challenges for "http-01", 
"tls-sni-02", and "dns-01"?

Section 7.2: s/in A and  records/in the DNS A and  resource records/

Section 7.3: s\by an A/ record\by the DNS A and  resource records\

Section 9.1: s/man in the middle/man-in-the-middle (MitM)/

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

Re: [Acme] ACME draft is now in WGLC.

[Anders Rundgren]

On 2017-02-13 06:26, Martin Thomson wrote:


   In the examples below, JWS objects are shown in the JSON or flattened
   JSON serialization, with the protected header and payload expressed
   as base64url(content) instead of the actual base64-encoded value, so
   that the content is readable.  Some fields are omitted for brevity,
   marked with "...".

I didn't really understand this without an example to use for
reference.  Given that the first actual use of this form is 15 (!)
pages further down the document, maybe you could move this there.


JWS is great for what is was originally designed for.  ES6 normalization
nullifies the need for dressing JSON data in Base64Url.

Anders
https://cyberphone.github.io/doc/security/jsonsignatures.html

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

Re: [Acme] ACME draft is now in WGLC.

[Martin Thomson]

On 11 February 2017 at 05:56, Salz, Rich  wrote:
> ACME WGLC

It's been a while since I did a review of this, so I spent a few hours on it.

This document is in pretty good shape.  I have a lot of comments (a
LOT), and some of these are serious enough that I'd want to see
another WGLC, but they are relatively minor.  Overall the document is
in very good shape; most of my comments are of the nitpicking variety.

This is a pretty significant piece of work and that this is as good as
it is represents cause for congratulations to those involved (except
me, I'm just a hazard).


Meta

I found the use of lowercase versions of RFC 2119 keywords quite
distracting, and occasionally confusing.  It's often the case that the
lowercase version is used where a simple imperative statement would
work.  I haven't called out many of those in my review, except where
they caused what I think to be a genuine problem.

I have created an editorial pull request on the spec.  There were lots
of tiny fixes (including some opportunities to correct the above).  In
some cases, that PR will conflict with substantial changes that I
think need to happen, so you might want to attend to that first.

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


S5.1

   Clients SHOULD
   support HTTP public key pinning [RFC7469], and servers SHOULD emit
   pinning headers.

and

   ACME clients SHOULD send a User-Agent header in accordance with
   [RFC7231], including the name and version of the ACME software in
   addition to the name and version of the underlying HTTP client
   software.

and

   Such servers SHOULD
   set the Access-Control-Allow-Origin header field to the value "*".

Why?  It's usually good practice with a SHOULD to provide some sort of
reason why choosing not to comply might be necessary, or to otherwise
motivate the choice.  All three seem relatively easy to fix with a
simple sentence (pinning good m'kay, client bugs(?), building a
web-based client).

S5.2

   For all other requests, there MUST be a "kid" field.  This field must
   contain the account URI received by POSTing to the new-reg resource.

MUST?

   Servers MUST NOT respond to GET
   requests for resources that might be considered sensitive.

Since this is a requirement, it might pay to do a little due diligence
on what might be sensitive.  I'm not sure that all implementers will
have the same view (or same motivations) when it comes to this.

  server MUST return an error

This would benefit from a reference to S5.7, as does all the other
instances of error handling.  Though this section includes an example
(that seems unnecessary), it's very hard to tell if this is normative
or not from context.

   In the examples below, JWS objects are shown in the JSON or flattened
   JSON serialization, with the protected header and payload expressed
   as base64url(content) instead of the actual base64-encoded value, so
   that the content is readable.  Some fields are omitted for brevity,
   marked with "...".

I didn't really understand this without an example to use for
reference.  Given that the first actual use of this form is 15 (!)
pages further down the document, maybe you could move this there.

S5.3

   JWK thumbprint [citation needed]

S5.4

I would reference RFC 7230, Section 2.7.3 "http and https URI
Normalization and Comparison" here and note the risk that
normalization could cause comparison failures.  A recommendation that
URLs generated by the server SHOULD be normalized according to that
section so that the risk of normalization is reduced.

S5.5

   The server MUST include a Replay-
   Nonce header field in every successful response to a POST request,
   and SHOULD provide it in error responses as well.

This seems to purposefully neglect to mention other requests, like
GET.  Does the "SHOULD" apply just to POST requests, or is it any
method?

This section says that nonces are mandatory with POST requests, but
does not offer a way to get a nonce that does not require a nonce.
Please make this observation and reference S6.2.

S5.6

Once again, mention is made of error descriptions without a forward reference.

   Additionally, the server
   SHOULD send a "Retry-After" header indicating when the current
   request may succeed again.

"may" or "could"?

S5.7

In a couple of places, a specific error URN is mandated (with MUST),
but this section only uses SHOULD for the error description.

   Authorization and challenge objects can also contain error
   information to indicate why the server was unable to validate
   authorization.

Where and how would this appear?  This needs more definition (I
looked, but I didn't find anything further down).

S6.1

The list of resources could use some references to the sections that
define them.

S6.1.2

   status (required, string):  The status of this account.  Possible
  values are: "valid", "deactivated", and "revoked".  The value
  "deactivated" should be used to indicate user initiated
  

Re: [Acme] ACME draft is now in WGLC.

[housley]

From: IETF Secretariat [mailto:ietf-secretariat-re...@ietf.org]
Sent: Tuesday, February 07, 2017 12:26 PM
To: draft-ietf-acme-a...@ietf.org; acme-cha...@ietf.org
Subject: IETF WG state changed for draft-ietf-acme-acme


The IETF WG state of draft-ietf-acme-acme has been changed to "In WG
Last Call" from "WG Document" by Rich Salz:

https://datatracker.ietf.org/doc/draft-ietf-acme-acme/


Please use the terminology from RFC 5280.  Throughout the document:
   s/certificate authority/certification authority/
   s/issuing authority/certificate issuer/

Also, please use the correct expansion for PKIX (PKI using X.509).

In Section 1, please define ACME.

Also in Section 1:
s/Certificates in the Web PKI [RFC5280]/Certificates [RFC5280] in the 
Web PKI/


In Section 5.1, I think it is desirable to add a requirement that the 
ACME server SHOULD OCSP Staple.


In Section 5.2, please repeat the reference for the JWS specification at 
the front of this section.


Section 5.2 says:

   In the examples below, JWS objects are shown in the JSON or flattened
   JSON serialization, with the protected header and payload expressed
   as base64url(content) instead of the actual base64-encoded value, so
   that the content is readable.  Some fields are omitted for brevity,
   marked with "...".

The example is above this text (below), and there is no "..." in it.

In Section 5.5, please add a MUST statement about the size of the nonce 
value (before base64url encoding).


In Section 6.1.1, how does the key-change entry in the table in section 
6.1.1 relate to the figure in Section 6.1?  The other entries in this 
table seem to have an obvious companion in the figure.  I think the 
figure should to show how the key-change is used update the acct.


Section 6.1.1: s/function as both an ACME/functions as both an ACME/

Section 6.1.1 says:

   "caa-identities" (optional, array of string):  Each string MUST be a
  lowercase hostname ...

How are IDNs handled?  Are all U-labels converted to A-labels?

Section 6.1.2: s/associated to an account/associated with an account/

Section 6.1.3 says:

   status (required, string):  The status of this order.  Possible
  values are: "pending", "processing", "valid", and "invalid".

Should the list of possible status strings should also include 
"expired"?  If not, the text should say that the status will be set to 
invalid if the authorizations are not accomplished before the expiration 
time.


Section 6.1.4 says:

   scope (optional, string):  If this field is present, then it MUST
  contain a URI for an order resource, such that this authorization
  is only valid for that resource.  If this field is absent, then
  the CA MUST consider this authorization valid for all orders until
  the authorization expires. [[ Open issue: More flexible scoping?
  ]]

This scoping seems fine.  Please remove the [[ question ]].

Section 6.1.4 says:

   ...  Servers MUST verify any identifier values that
   begin with the ASCII Compatible Encoding prefix "xn-" as defined in
   [RFC5890] are properly encoded.  ...

I think you want to require the A-labels to be converted to U-labels and 
back again, and then reject the label if the converted A-label does not 
match the original A-label.


In Section 6.3.3, the list of steps clearly includes checking the 
signature on the inner JWS in step 4, but I do not see a step that 
checks the signature on the outer JWS.  I think the both signature 
checks need to be explicit in the steps.


Is an additional subsection in Section 6.3 needed to deal with lost 
account signature private keys?  I assume that some out-of-band 
mechanism would be needed to delete the account so that a new one can be 
created.


Section 6.4.2 says:

   The default format of the certificate is PEM (application/x-pem-file)
   as specified by [RFC7468]. ... The client may request other formats 
by

   including an Accept header in its request.  For example, the client
   may use the media type application/pkix-cert to request the end-
   entity certificate in DER format.

RFC 7468 defines the textual encoding for certificates, but it does not 
define the application/x-pem-file media type.  I cannot find a 
registration for the application/x-pem-file media type.


Also, please add a reference to RFC 2585; it specifies the 
application/pkix-cert media type.


In Section 6.5, should the example use different challenges for 
"http-01", "tls-sni-02", and "dns-01"?


Section 7.2: s/in A and  records/in the DNS A and  resource 
records/


Section 7.3: s\by an A/ record\by the DNS A and  resource 
records\


In Section 8.2, I cannot understand the figure.  Please correct it.

Section 9.1: s/man in the middle/man-in-the-middle (MitM)/

Russ

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

Re: [Acme] ACME draft is now in WGLC.

[Salz, Rich]

> PLEASE reply on list if you will review and/or are interested in working on
> interop.

Looking for last-minute Valentine's Day plans?  
(https://en.wikipedia.org/wiki/Valentine's_Day among others).  What could be 
more romantic than an evening spent with your loved one reading the ACME WGLC 
spec, and jointly posting comments to the list?

Start here:  https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

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