Re: [Acme] Removing extraneous link relations

[Jacob Hoffman-Andrews]

This all looks good to me.

On 02/13/2017 05:49 PM, Roland Shoemaker wrote:
> I propose we remove the 'author', 'revoke', and 'ct-sct' link relations.
> 'author' seems to provide no concrete value, and 'revoke' is already
> provided by the 'directory' endpoint. The 'ct-sct' relation is also
> somewhat pointless as the SCT will be provided by the CA via the
> certificate or a OCSP response, if it doesn't provide either of these
> then the client should be able to retrieve the SCT itself from the logs
> it expects to find the certificate in.
>
> I also agree with Martin's suggestion that we replace the 'directory'
> link relation with 'index' as it is already registered and means
> basically what we intend.
>
> PR making these changes: https://github.com/ietf-wg-acme/acme/pull/250
>

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

[Acme] Removing extraneous link relations

[Roland Shoemaker]

I propose we remove the 'author', 'revoke', and 'ct-sct' link relations.
'author' seems to provide no concrete value, and 'revoke' is already
provided by the 'directory' endpoint. The 'ct-sct' relation is also
somewhat pointless as the SCT will be provided by the CA via the
certificate or a OCSP response, if it doesn't provide either of these
then the client should be able to retrieve the SCT itself from the logs
it expects to find the certificate in.

I also agree with Martin's suggestion that we replace the 'directory'
link relation with 'index' as it is already registered and means
basically what we intend.

PR making these changes: https://github.com/ietf-wg-acme/acme/pull/250

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

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

[Acme] Just the technical comments (was: ACME draft is now in WGLC.)

[Martin Thomson]

At Rich's request, here are the technical parts.  I assume that the
editors will be trawling through the entirety of the original mail
(for which I apologize).

These are just the headline items, I pulled two forward because I
think they are more important.  The others are small beans.  Of course
I'm happy to be wrong about any of these.

S6.3.2

   [...] and MUST reflect [the?] value of the
   "external-account-binding" field in the resulting account object

Is this a direct copy of the MAC that was provided?  Do you realize
that this enables a user with access to any account that was created
with a binding to replay the binding in new accounts without actually
having the MAC key?  Would it be acceptable to just reflect that the
binding exists?  (Potentially bad idea: just include the key id; if
the CA wants, that key identifier could be a URL to the external
account details page and do double-duty.)

Note that this would be a violation of the stated security goal of not
having integrity compromised by a TLS MitM or CDN.  It doesn't
necessarily permit misissuance unless the binding to the account
carries authorizations across, or things like that.

S6.3.4

   It is up to server policy
   how long to retain data related to that account, whether to revoke
   certificates issued by that account, and whether to send email to
   that account's contacts.

This is terrible.  If I wish to decommission an account key, then I
can't because I might find that my certificates are all suddenly
revoked.  Think about a large organization that has a pool of
authorized accounts used for managing certificates.  If one of those
needs to fall out of the pool (the machine hosting the key is being
scrapped or rebuilt, for instance), then you don't want to have all
the certificates that it issued disappearing suddenly.

If there are good reasons to revoke certificates, then be definite
about it and say that they go away, at least then people can plan
around the problem.

S5.2

   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.

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.4

   [[ Open issue: More flexible scoping? ]]

Red flag.  In my view, the simple approach is fine.  New authorization
resources are cheap.  They can even be cloned easily, even allowing
one challenge to fulfill multiple.

S6.4.1

   The server can also provide the client with direct access to an SCT
   for a certificate using a Link relation header field with relation
   "ct-sct".

Where is this link relation type registered?  It isn't in either the
IANA considerations section or in the registry:
http://www.iana.org/assignments/link-relations/link-relations.xhtml

The same goes for the other link relation types that are used in the
example.  I see neither "revoke" nor "directory" being registered.
BTW, "index" would probably do well instead of "directory", "revoke"
seems specific enough to this usage - like "ct-sct" that using a URI
for the relation type would probably be better than registering a link
relation.

S6.5.1

   In responding to poll requests while
   the validation is still in progress, the server MUST return a 202
   (Accepted) response

The 202 is an odd choice here.  The resource exists and has content,
so 200 works perfectly well for this purpose.

S6.6

   The server MAY disallow a subset of reasonCodes from
  being used by the user.

Does a server ignore the reasonCode, or does it reject the request
when an impermissible code is chosen by the client?

S9.2

   For identifiers
   where the server already has some public key associated with the
   domain this attack can be prevented by requiring the client to prove
   control of the corresponding private key.

This doesn't seem right.  I believe that the model permits multiple
accounts to act for a single domain.  Not doing so would represent a
pretty big operational burden.  What public key does this then refer
to?  Or is this promise not valid?

S9.3

You should also recommend rate limits on account creation, or your
other mitigations might be weakened.

S9.4

Does an ACME server send Referer[sic]?  What should it set it to?

S10.2

   A CA that accepts TLS-based proof of domain control should attempt to
   check whether a domain is hosted on a domain with a default virtual
   host before allowing an authorization request for this host to use a
   TLS-based challenge.  A default virtual 

[Acme] Registering a PEM Content-Type

[Jacob Hoffman-Andrews]

>From the WGLC thread, Russ Housley said:

> 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.

This is a good point. Should we register x-pem-file as part of this RFC? Or 
come up with a new, more specific media type, like 
application/pem-certificate-chain?

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

Re: [Acme] HPKP in ACME

[Alan Doherty]

I would concur that clients should endeavour to support

(and thusly CAs can consider using in future, when support is available in 
wider librarys)

but because of the risks they should only consider doing so
if/when all their processes are in place to ensure failures can't occur

but how best to word that i don't know

At 20:09 13/02/2017  Monday, Clint Wilson wrote:
>I would definitely support removing ", and servers SHOULD emit pinning 
>headers", especially because of the footgun risk you indicated, but I think 
>there is some merit in continuing to recommend support for HPKP on the client 
>side.
>
>On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews 
><j...@eff.org> wrote:
>Martin brought up a section I've been considering removing:
>
>> Clients SHOULD support HTTP public key pinning [RFC7469], and servers
>SHOULD emit pinning headers.
>
>Here's my reasoning:
>
>- Public key pinning isn't implemented in most HTTPS libraries outside
>of browsers, so this is a considerable burden on implementers.
>- Public key pinning carries a fairly high risk of footgunning. The
>consequence of a failed pin for a CA that serves many ACME clients would
>be that some of those clients would fail to renew their certs, causing
>cascading breakage.
>- There is relatively little confidential information conveyed in ACME,
>and there are other defenses built into ACME (like including the account
>key as part of the challenge data), so HPKP is not strongly necessary.
>
>Any objections?
>
>PR to remove: 
>https://github.com/ietf-wg-acme/acme/pull/244
>
>___
>Acme mailing list
>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme
>
>___
>Acme mailing list
>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme

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

Re: [Acme] Repeated tokens for different challenges in same authorization

[Jacob Hoffman-Andrews]

On 02/13/2017 12:20 PM, Russ Housley wrote:
> I do not think it is a risk with the authorizations that have been
> defined. I was wondering about a situation where a client make a
> mistake. If a client tries to fulfill one of the authorizations and
> for some reason is unable to do so completely, and then moves to
> another authorization, can the half-done first authorization cause a
> problem.
Duplicate tokens across authorizations (not within authorizations) might
cause some minor issues. For instance, the token is used to identify a
resource being requested, so in the http-01 challenge a client might
find itself trying to write the same content to the same filename as
second time.

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

Re: [Acme] Repeated tokens for different challenges in same authorization

[Russ Housley]

> In the WGLC thread, Russ asked:
> 
>> In Section 6.5, should the example use different challenges for "http-01", 
>> "tls-sni-02", and "dns-01"?
> (https://ietf-wg-acme.github.io/acme/#rfc.section.6.5)
> 
> I assume you meant "token" here, and no, I think the token can be the same 
> across multiple challenges for the same authorization. Boulder (Let's 
> Encrypt's implementation) doesn't currently do this, but will in the future. 
> If you think there's a risk in this, please let us know!

I do not think it is a risk with the authorizations that have been defined. I 
was wondering about a situation where a client make a mistake.  If a client 
tries to fulfill one of the authorizations and for some reason is unable to do 
so completely, and then moves to another authorization, can the half-done first 
authorization cause a problem.

Russ
___
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] HPKP in ACME

[Clint Wilson]

I would definitely support removing ", and servers SHOULD emit pinning
headers", especially because of the footgun risk you indicated, but I think
there *is* some merit in continuing to recommend support for HPKP on the
client side.

On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews  wrote:

> Martin brought up a section I've been considering removing:
>
> > Clients SHOULD support HTTP public key pinning [RFC7469], and servers
> SHOULD emit pinning headers.
>
> Here's my reasoning:
>
> - Public key pinning isn't implemented in most HTTPS libraries outside
> of browsers, so this is a considerable burden on implementers.
> - Public key pinning carries a fairly high risk of footgunning. The
> consequence of a failed pin for a CA that serves many ACME clients would
> be that some of those clients would fail to renew their certs, causing
> cascading breakage.
> - There is relatively little confidential information conveyed in ACME,
> and there are other defenses built into ACME (like including the account
> key as part of the challenge data), so HPKP is not strongly necessary.
>
> Any objections?
>
> PR to remove: https://github.com/ietf-wg-acme/acme/pull/244
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Repeated tokens for different challenges in same authorization

[Jacob Hoffman-Andrews]

In the WGLC thread, Russ asked:

> In Section 6.5, should the example use different challenges for "http-01", 
> "tls-sni-02", and "dns-01"?
(https://ietf-wg-acme.github.io/acme/#rfc.section.6.5)

I assume you meant "token" here, and no, I think the token can be the same 
across multiple challenges for the same authorization. Boulder (Let's Encrypt's 
implementation) doesn't currently do this, but will in the future. If you think 
there's a risk in this, please let us know!

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

[Acme] HPKP in ACME

[Jacob Hoffman-Andrews]

Martin brought up a section I've been considering removing:

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

Here's my reasoning:

- Public key pinning isn't implemented in most HTTPS libraries outside
of browsers, so this is a considerable burden on implementers.
- Public key pinning carries a fairly high risk of footgunning. The
consequence of a failed pin for a CA that serves many ACME clients would
be that some of those clients would fail to renew their certs, causing
cascading breakage.
- There is relatively little confidential information conveyed in ACME,
and there are other defenses built into ACME (like including the account
key as part of the challenge data), so HPKP is not strongly necessary.

Any objections?

PR to remove: https://github.com/ietf-wg-acme/acme/pull/244

___
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