Re: [Acme] [Technical Errata Reported] RFC8555 (7565)

[Richard Barnes]

This seems correct to me.  I would mark it Verified.

On Thu, Jul 13, 2023 at 12:19 PM RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7565
>
> --
> Type: Technical
> Reported by: Paul Breed 
>
> Section: 8.1
>
> Original Text
> -
>  The "Thumbprint" step indicates the computation specified in
>[RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
>[RFC7518] any prepended zero octets in the fields of a JWK object
>MUST be stripped before doing the computation.
>
> Corrected Text
> --
> The "Thumbprint" step indicates the computation specified in
>[RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
>[RFC7518] any additional prepended zero octets in the fields of a JWK
> object
>MUST be stripped before doing the computation.
>Fixed length fields such as found in ECDSA keys should be their natural
> length and
>leading zero octets should not be stripped.
>
> Notes
> -
> This comment was really aimed at the leading 0 octet sometimes used with
> RSA, but the comment is not RSA specific. ECDSA keys can have fixed length
> fields (X,Y) where there can be leading zeros.  This led me astray in
> implementing an ECDSA thumbprint routine for ACME. The result was that
> 1/128 ECDSA keys failed to generate t humbp[rint as leading zeros were
> removed.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Richard Barnes]

Hi Mike, Paul,

So if I understand this correctly, the idea is that an ACME client that
intends to obtain a certificate for example.com will look up CAA records
for example.com and follow the guidance there as to which CA to contact?

Couple of observations on a quick skim:

A brief "protocol overview" section might be helpful to capture the
intended happy-path flow.

If folks are annoyed about the .well-known parts (as I am, a little): Since
you're going to extend CAA anyway, you could just put a URL in there
instead of overloading the CAA domain name.  For example, instead of the
`discover` parameter being a boolean, you could just put the URL of the
ACME server directory there.  (That would introduce a risk of divergence in
the multiple-domain case, different ACME servers for the same CA domain,
but that seems like it fails safely.)

Section 3.1.2 says "the value "1" represents the highest priority", but
Section 3.2 includes "the highest priority of 0".  In general, the document
should be clear on how the default interacts with explicit priorities.

Cheers,
--RLB



On Thu, Jul 6, 2023 at 10:55 AM Mike Ounsworth  wrote:

> Hi ACME!
>
> This is new business that we would like to add to the agenda for 117.
>
> Thanks,
> ---
> Mike Ounsworth & Paul van Brouwershaven
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Thursday, July 6, 2023 9:39 AM
> To: Mike Ounsworth ; Paul van Brouwershaven <
> paul.vanbrouwersha...@entrust.com>
> Subject: [EXTERNAL] New Version Notification for
> draft-vanbrouwershaven-acme-auto-discovery-00.txt
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
>
> __
>
> A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt
> has been successfully submitted by Paul van Brouwershaven and posted to
> the IETF repository.
>
> Name:   draft-vanbrouwershaven-acme-auto-discovery
> Revision:   00
> Title:  Auto-discovery mechanism for ACME client configuration
> Document date:  2023-07-06
> Group:  Individual Submission
> Pages:  16
> URL:
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/
> Html:
> https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery
>
>
> Abstract:
>A significant impediment to the widespread adoption of the Automated
>Certificate Management Environment (ACME) [RFC8555] is that ACME
>clients need to be pre-configured with the URL of the ACME server to
>be used.  This often leaves domain owners at the mercy of their
>hosting provider as to which Certification Authorities (CAs) can be
>used.  This specification provides a mechanism to bootstrap ACME
>client configuration from a domain's DNS CAA Resource Record
>[RFC8659], thus giving control of which CA(s) to use back to the
>domain owner.
>
>Specifically, this document specifies two new extensions to the DNS
>CAA Resource Record: the "discovery" and "priority" parameters.
>Additionally, it registers the URI "/.well-known/acme" at which all
>compliant ACME servers will host their ACME directory object.  By
>retrieving instructions for the ACME client from the authorized
>CA(s), this mechanism allows for the domain owner to configure
>multiple CAs in either load-balanced or fallback prioritizations
>which improves user preferences and increases diversity in
>certificate issuers.
>
>
>
>
> The IETF Secretariat
>
>
> Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.
> ___
> 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] Call for adoption for draft-bweeks-acme-device-attest

[Richard Barnes]

I have read the draft, and it seems well thought through.  Especially if
there is implementor interest, this seems like a sane thing for the WG to
adopt.

On Tue, Nov 15, 2022 at 2:53 PM Carl Wallace 
wrote:

> I’ve read the draft and support its adoption.
>
>
>
> *From: *Acme  on behalf of Deb Cooley <
> debcool...@gmail.com>
> *Date: *Tuesday, November 15, 2022 at 1:01 PM
> *To: *IETF ACME 
> *Cc: *
> *Subject: *[Acme] Call for adoption for draft-bweeks-acme-device-attest
>
>
>
> This will be a three week call for adoption ending on 6 Dec. (because of
> holidays in the US).   Please speak up either for or against adopting this
> draft.
>
> Thanks,
> Deb and Yoav.
>
> ___ 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] [IANA #1217629] Expert Review for draft-ietf-acme-dtnnodeid-07 (acme)

[Richard Barnes]

Hi Amanda,

I reviewed the diff, and it doesn't look like anything relevant to the
review changed.  So I think we're good.

--RLB

On Fri, Oct 14, 2022 at 4:12 PM Amanda Baber via RT <
drafts-expert-rev...@iana.org> wrote:

> Dear Richard (cc: acme WG),
>
> You approved the proposed registrations in draft-ietf-acme-dtnnodeid-07 in
> January. Version -10 is now listed on the October 27th IESG telechat agenda:
>
> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/
>
> Does this document need another review?
>
> Thanks,
>
> Amanda Baber
> IANA Operations Manager
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Authority Token WGLC

[Richard Barnes]

Yeah, I was definitely thinking it would be optional.  If the new field is
present, a client could use it as its x5u parameter. If not, the client
knows it has to download and republish the certificate.

—Richard


On Mon, Aug 29, 2022 at 09:19 Chris Wendt  wrote:

> Hi Richard,
>
> Thanks for the review.  So, just to make sure i’m understanding, you are
> saying that we should have a feature where both the POST-as-GET standard
> ACME certificate URL is kept, but we also (maybe optionally or are you
> saying should mandate this?) offer the ability for a CA hosted URL that
> would be used directly in PASSporT for making the certificate available for
> relying party consumption?
>
> The idea that a CA offers direct URL to certificate has always been
> considered optional in SHAKEN, originally the thought was that it would be
> hosted under HTTPS address of the ACME client customer (service provider).
> I think as things have been implemented in the industry where it turns out
> many of the CAs are also hosted by vendors of the entire hosted STIR/SHAKEN
> solutions, as you state that hasn’t been the case and is often hosted under
> vendor/CA URL.
>
> I think if we include it as optional, I have no issue including it, if we
> think it needs to be mandatory would probably want to get more feedback
> from others.
>
> -Chris
>
> On Aug 26, 2022, at 5:02 PM, Richard Barnes  wrote:
>
> One minor point:
>
> STIR PASSporT objects reference certificates via the JWS "x5u" header,
> which requires that the URL respond to GET, vs. the POST-as-GET that is
> used for the ACME certificate URL.  On the face of it, this would seem to
> require a STIR signer to download their certificate from the CA and
> republish it on a different server, and in fact ATIS-174 describes this
> behavior.  However, current STIR CAs already offer GET-friendly URLs for
> their certificates, avoiding the need for such republication.  It would be
> helpful (for STIR, but also more broadly) if this protocol had a field
> where a CA that provides this service could specify an "x5u"-friendly
> certificate URL.
>
> It seems like there's a simple solution here, namely to add a field to
> completed order objects (state = "valid") that responds to GET requests and
> provides the certificate in the format "x5u" expects.  You could even just
> call the field "x5u" :)
>
> Anyway, I realize it's late for a feature request, but this seems like a
> minor addition, and it seems like fixing this gap would allow the ecosystem
> to fit together a little more smoothly.
>
> --Richard
>
> On Tue, Aug 23, 2022 at 3:59 PM Deb Cooley  wrote:
>
>> As we agreed at the acme session at IETF 114, this is a limited WGLC for
>> both:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token/
>>
>> https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-tnauthlist/
>>
>> I've added stir to the to line for good measure (and to broaden the pool
>> of reviewers a bit). We need to see if we can push these forward again.
>>
>> The review deadline is 6 Sep 2022.
>>
>> Deb Cooley
>> acme co-chair
>>
>> ___
>> 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] Authority Token WGLC

[Richard Barnes]

One minor point:

STIR PASSporT objects reference certificates via the JWS "x5u" header,
which requires that the URL respond to GET, vs. the POST-as-GET that is
used for the ACME certificate URL.  On the face of it, this would seem to
require a STIR signer to download their certificate from the CA and
republish it on a different server, and in fact ATIS-174 describes this
behavior.  However, current STIR CAs already offer GET-friendly URLs for
their certificates, avoiding the need for such republication.  It would be
helpful (for STIR, but also more broadly) if this protocol had a field
where a CA that provides this service could specify an "x5u"-friendly
certificate URL.

It seems like there's a simple solution here, namely to add a field to
completed order objects (state = "valid") that responds to GET requests and
provides the certificate in the format "x5u" expects.  You could even just
call the field "x5u" :)

Anyway, I realize it's late for a feature request, but this seems like a
minor addition, and it seems like fixing this gap would allow the ecosystem
to fit together a little more smoothly.

--Richard

On Tue, Aug 23, 2022 at 3:59 PM Deb Cooley  wrote:

> As we agreed at the acme session at IETF 114, this is a limited WGLC for
> both:
>
> https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token/
>
> https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-tnauthlist/
>
> I've added stir to the to line for good measure (and to broaden the pool
> of reviewers a bit). We need to see if we can push these forward again.
>
> The review deadline is 6 Sep 2022.
>
> Deb Cooley
> acme co-chair
>
> ___
> 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] Fwd: New Version Notification for draft-suchan-acme-onion-00.txt

[Richard Barnes]

Yep, this is the right way to suggest a new draft!  Thanks for writing this
up.

One high-level comment on a quick skim: I don't think you need the new
identifier type.  Since .onion is a "legit" TLD [RFC7686], onion names are
part of the DNS namespace.  It's OK for CAs to have different policies for
different domain names.  Obviously the CABF requirements would require a CA
to validate .onion names differently, but that's up to the CA's internal
logic to choose different challenges.  Note that they already need such
logic, since a client can already send in a .onion name, and the CA
shouldn't validate it like a normal name.

In general, it would be good to understand what extra work is really needed
here.  As you point out, http-01 and tls-alpn-01 work for onion names; is
the new challenge type better in some way?

On Tue, May 10, 2022 at 10:18 PM Seo Suchan  wrote:

>
> I'm new to rfc draft thing: is this right way to suggest a new draft?
>
> in appendix I made some questions. copyting them here:
>
> should this be about onion address, or all kind of alternative DNS systems?
> should identifier type and challenge type include or strip -v3 tag from
> its name? if we include that how about this doc name itself? http-01 and
> tls-alpn-01 over tor will work as well for like onion address V2 or V12,
> but csr challenge may not. but it's reasonable to ask same identifier
> type should give same set of challenges.
> should the as rigid as complying this will make comply CA/B Baseline
> requirement?
> while type onion domain name just full onion v3 name itself with example
> subdomain will exceed rfc line limit. but using ... doesn't right in
> context of domain name. any alternative to express truncated FQDN? would
> "example.onion" work while it wouldn't be valid onion name?
>
>  forwarded message 
> title:  New Version Notification for draft-suchan-acme-onion-00.txt
> date:   Tue, 10 May 2022 19:04:01 -0700
> sender: internet-dra...@ietf.org
> to: Seo Suchan 
>
>
>
>
> A new version of I-D, draft-suchan-acme-onion-00.txt
> has been successfully submitted by Seo Suchan and posted to the
> IETF repository.
>
> Name: draft-suchan-acme-onion
> Revision: 00
> Title: Automated Certificate Management Environment (ACME) Onion
> Identifier Validation Extension
> Document date: 2022-05-10
> Group: Individual Submission
> Pages: 7
> URL: https://www.ietf.org/archive/id/draft-suchan-acme-onion-00.txt
> Status: https://datatracker.ietf.org/doc/draft-suchan-acme-onion/
> Htmlized: https://datatracker.ietf.org/doc/html/draft-suchan-acme-onion
>
>
> Abstract:
> This document specifies identifiers and challenges required to enable
> the Automated Certificate Management Environment (ACME) to issue
> certificates for Tor Project's onion V3 addresses.
>
> ___
> 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] 2nd working group call for adoption

[Richard Barnes]

I have read the document, and support its adoption.

This functionality actually reflects the existing behavior of a lot of CAs
in the Web PKI (allowing issuance for subdomains after validating a
registered domain), so it's good to have clear semantics in ACME for it.

--Richard

On Thu, Oct 14, 2021 at 8:17 AM Cooley, Dorothy E  wrote:

> This is the second working group call for adoption of:
> draft-friel-acme-subdomains-05.
> We have had presentations of this work at the most recent interim
> (clarifications presented) and at many of the past IETF meetings.
>
> Please review the draft and post your comments to the list by Thursday, 28
> October 2021.
>
> Thanks,
> Deb and Yoav
>
>
> ___
> 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] Fwd: New Version Notification for draft-biggs-acme-sso-00.txt

[Richard Barnes]

Hi ACME folks,

I'd like to bring this proposed extension to ACME to the attention of the
working group.  This work builds on Alexei's document defining the "email"
identifier type, and defines (1) a mechanism for validating email addresses
using SSO, and (2) some CAA mechanisms to manage issuance of certificates
with email addresses.

I would like for the ACME WG to take this on as a work item, as a logical
next step following on draft-ietf-acme-email-smime.  Any feedback on the
draft would be very welcome.

Thanks,
--Richard


-- Forwarded message -
From: 
Date: Tue, Dec 8, 2020 at 10:09 AM
Subject: New Version Notification for draft-biggs-acme-sso-00.txt
To: Andrew Biggs , Richard L. Barnes 



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

Name:   draft-biggs-acme-sso
Revision:   00
Title:  Automated Certificate Management Environment (ACME)
Extension for Single Sign On Challenges
Document date:  2020-12-08
Group:  Individual Submission
Pages:  12
URL:https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.txt
Status: https://datatracker.ietf.org/doc/draft-biggs-acme-sso/
Html:   https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.html
Htmlized:   https://tools.ietf.org/html/draft-biggs-acme-sso-00


Abstract:
   This document specifies an extension to the ACME protocol [RFC8555]
   to enable ACME servers to validate a client's control of an email
   identifier using single sign-on (SSO) technologies.  An extension to
   the CAA [RFC8659] resource record specification is also defined to
   provide domain owners a means to declare a set of SSO providers that
   ACME servers may rely upon when employing SSO for identifier
   validation on their domain.




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] [Editorial Errata Reported] RFC8555 (6321)

[Richard Barnes]

(Submitter removed)

This appears to be invalid.

On Mon, Oct 26, 2020 at 10:50 PM RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6321
>
> --
> Type: Editorial
> Reported by: francis raguine <7r4nki3ra...@gmail.com>
>
> Section: 095ll210217
>
> Original Text
> -
>
>
> Corrected Text
> --
>
>
> Notes
> -
>
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (5979)

[Richard Barnes]

ADs: This seems like a nice clarification, but not really an error.
Suggest HFDU.

On Tue, Feb 11, 2020 at 4:49 PM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5979
>
> --
> Type: Technical
> Reported by: jonathan vanasco 
>
> Section: 7.4
>
> Original Text
> -
>  If the server is willing to issue the requested certificate, it
>responds with a 201 (Created) response.  The body of this response is
>an order object reflecting the client's request and any
>authorizations the client must complete before the certificate will
>be issued.
>
>
>
> Corrected Text
> --
>  If the server is willing to issue the requested certificate, it
>responds with a 201 (Created) response.  The body of this response is
>an order object reflecting the client's request and any
>authorizations the client must complete before the certificate will
>be issued. The server returns an order URL in a Location header field.
>
>
> Notes
> -
> The RFC does not specify/require where the "order URL" is presented.  The
> RFC is very explicit about where other URLs are obtained, and the common
> understanding is that the URL appears in a Location header after a
> new-order.
>
> For example:
>
> In 7.3; 7.3.1; 7.3.5, the RFC explicitly declares the account URL is in
> the Location header field.
>
> In 7.4.1 the RFC is explicit that authorization URLs in pre-authorization
> appear in the Location header field.
>
> But the order URL is only mentioned by example:
>
> In 7.4, the RFC illustrates the order URL appearing in the Location header
> field (All clients seem to implement this).  In 7.1, the RFC shows a table
> with "a typical sequence of requests" that note the "account" and "order"
> URLs appear in the location header field.
>
> The specification should state something to the effect of "The server
> returns an order URL in a Location header field." making this functionality
> explicit.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-ietf-acme-star

[Richard Barnes]

On Mon, Sep 9, 2019 at 4:15 AM Thomas Fossati 
wrote:

> Hi Richard,
>
> Thank you for the detailed review. As you note yourself, this is quite
> late in the document life-cycle (the draft completed IETF LC over a
> month ago), which is unfortunate, given that every one of your comments
> is an actual protocol change.


Do you have any implementations that this would break?  Or is this just
avoiding spec changes?

Most of the below should be pretty easy to address, so unless there's some
massively deployed code base that's going to be broken, I would propose
that they should be addressed before publication.

Note that there are some potential deployment blockers here, most
importantly the implication that the CA should pre-date certificates.

--Richard



> As far as we understand, none of them can
> be seen as a "showstopper" mistake in the protocol, and therefore we
> propose to move forward with the current draft version. Please let us
> know if we missed anything.
>
> Cheers, Thomas (on behalf of the authors)
>
> > On 28/08/2019 at 15:52, Richard Barnes  wrote:
> >
> > I had a chance to take a look at this draft as a result of being a
> > designated expert on the registries.  I approved the registrations,
> > but independently, I have several major concerns about the draft.  In
> > no particular order
> >
> > - The use of the "STAR" acronym is not helpful.  This is not an
> > acronym that will be familiar to a reader, and less so an implementer
> > who has not fully read and absorbed this spec.  Instead, you should
> > say what you mean, e.g., for the "meta" fields:
> >
> > star-enabled -> auto-renewal-allowed star-min-cert-validity ->
> > min-cert-validity star-max-renewal -> max-auto-renewals
> >
> > - Likewise, "recurrent" is not a common word in English.  If you want
> > to use a single word, "recurring" is more common, but referring to
> > "auto-renewal" would be even better.
> >
> > - It would be even cleaner to group all these "recurrent" fields into
> > a sub-object, so that you wouldn't have to worry about them being
> > present if "recurrent" wasn't set.  In other words, just signal the
> > "recurrent" boolean by the presence of the object, and specify the
> > parameters in the object.
> >
> > { "auto-renew": { "start": ..., "end": ..., "lifetime": ..., } }
> >
> > - The idea of "predating" is toxic.  Pre-dating a certificate means
> > making the notBefore date earlier than when you actually issued it,
> > which is a huge problem for a real CA to do.  That's not what you mean
> > here..  You just want there to be some overlap between certificates.
> > Say that instead ("recurrent-certificate-predate" -> "overlap") and
> > adjust Section 3.5 accordingly.
> >
> > - The Not-Before and Not-After headers should be removed.  On the one
> > hand, it's not clear to me that it's any easier to parse these headers
> > than it is to parse the certificate.  On the other hand, there are
> > existing HTTP headers that express almost exactly the same semantics,
> > e.g., Expires.
> >
> > - It's not clear that there's any reason to negotiate certificate-GET
> > on a per-order basis.  Just have the CA allow it or not unilaterally
> > and delete the "recurrent-certificate-get" field.
> >
> > - The "star-certificate" attribute is unnecessary.  Instead, you
> > should just say that when auto-renewal is enabled, the "certificate"
> > attribute points to the current certificate, and use "previous" link
> > relations to expose earlier certs.
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] draft-ietf-acme-star

[Richard Barnes]

I had a chance to take a look at this draft as a result of being a
designated expert on the registries.  I approved the registrations, but
independently, I have several major concerns about the draft.  In no
particular order

- The use of the "STAR" acronym is not helpful.  This is not an acronym
that will be familiar to a reader, and less so an implementer who has not
fully read and absorbed this spec.  Instead, you should say what you mean,
e.g., for the "meta" fields:

star-enabled -> auto-renewal-allowed
star-min-cert-validity -> min-cert-validity
star-max-renewal -> max-auto-renewals

- Likewise, "recurrent" is not a common word in English.  If you want to
use a single word, "recurring" is more common, but referring to
"auto-renewal" would be even better.

- It would be even cleaner to group all these "recurrent" fields into a
sub-object, so that you wouldn't have to worry about them being present if
"recurrent" wasn't set.  In other words, just signal the "recurrent"
boolean by the presence of the object, and specify the parameters in the
object.

{
  "auto-renew": {
"start": ...,
"end": ...,
"lifetime": ...,
  }
}

- The idea of "predating" is toxic.  Pre-dating a certificate means making
the notBefore date earlier than when you actually issued it, which is a
huge problem for a real CA to do.  That's not what you mean here.  You just
want there to be some overlap between certificates.  Say that instead
("recurrent-certificate-predate" -> "overlap") and adjust Section 3.5
accordingly.

- The Not-Before and Not-After headers should be removed.  On the one hand,
it's not clear to me that it's any easier to parse these headers than it is
to parse the certificate.  On the other hand, there are existing HTTP
headers that express almost exactly the same semantics, e.g., Expires.

- It's not clear that there's any reason to negotiate certificate-GET on a
per-order basis.  Just have the CA allow it or not unilaterally and delete
the "recurrent-certificate-get" field.

- The "star-certificate" attribute is unnecessary.  Instead, you should
just say that when auto-renewal is enabled, the "certificate" attribute
points to the current certificate, and use "previous" link relations to
expose earlier certs.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (5729)

[Richard Barnes]

+1

On Thu, May 23, 2019 at 7:43 PM Jacob Hoffman-Andrews  wrote:

> I believe this should be verified.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Editorial Errata Reported] RFC8555 (5734)

[Richard Barnes]

+1

On Thu, May 23, 2019 at 7:38 PM Jacob Hoffman-Andrews  wrote:

> I believe this should be verified.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Editorial Errata Reported] RFC8555 (5735)

[Richard Barnes]

+1

On Thu, May 23, 2019 at 7:39 PM Jacob Hoffman-Andrews  wrote:

> I believe this should be verified.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Use cases / trust model for device certs

[Richard Barnes]

Hey Rifaat,

Owen and I were chatting about ACME and device certs this morning, and it
seemed like it might be useful to rekindle discussion on the topic here on
the ACME list.

I'd like to push a little more on the trust model here.  Just to establish
some terminology:

- Device: Uses certificates to authenticate identifiers
- Vendor: Makes the device that will get the end certificate
- Customer: Buys the device from the vendor and operates it
- CA: Validates identifiers and issues certificates
- Relying Party: Uses certificates to verify authentication for identifiers
- Device Identity: MAC address or similar

In the flows Owen and I have been discussing (more based on ANIMA/BRSKI),
the model is basically broken in two, with the customer in the middle:

1. The customer validates devices' device identity as part of the ANIMA
flow, based on the customer trusting the vendor, and assigns the device a
domain name
2. The customer uses ACME to issue domain name certificates (the CA is
unaware of the device identity)

That all pretty much just works with BRSKI and ACME as they are today.  But
it presumes that the RP is authenticating the device by domain name, as is
prevalent in most uses of TLS today.

In contrast, it seems like your draft presumes that the RP needs to know
the device identity; it's not satisfied by a domain name alone.  Can you
elaborate a bit more on what scenarios you have in mind for this?  If all
you care about is the customer tracking things, then the model above is
sufficient; the customer can simply assign domain names that encode the
device identity however it likes.

Thanks,
--Richard
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-ietf-acme-ip-05

[Richard Barnes]

Hey Kathleen,

I'm not clear on what you're after here.  Do you see something in here
forbidding use for client certificates that needs to be removed?  Do you
think there needs to be some explanation of how to put the right EKU in the
CSR?  It might help if you could submit a PR.

--Richard

On Tue, Apr 16, 2019 at 12:25 PM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hello,
>
> In the ACME meeting, I had asked if this draft could have text added to
> address how client certificates could be generated since this was written
> specific to server certificates, but could easily be extended as the
> difference in most cases would just be in the CSR.  Could this text be
> added so the IP address use case for devices could be covered in one
> document?
>
> Thank you!
>
> --
>
> Best regards,
> Kathleen
> ___
> 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] Client certificate draft

[Richard Barnes]

On Fri, Mar 29, 2019 at 9:30 AM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

>
>
> On Fri, Mar 29, 2019 at 4:27 AM Richard Barnes  wrote:
>
>>
>>
>> On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty <
>> kathleen.moriarty.i...@gmail.com> wrote:
>>
>>> I meant to respond inline as well.
>>>
>>> Sent from my mobile device
>>>
>>> On Mar 28, 2019, at 4:58 PM, Richard Barnes  wrote:
>>>
>>> To recap and extend some things that were said at the meeting:
>>>
>>> - ACME can already be used for client certificates that attest to domain
>>> names.  It's just an EKU difference, so it can be negotiated in the CSR..
>>>
>>> - ACME can already be used for code-signing certs, with external
>>> validation.  As with client certs, the relevant EKUs can be negotiated in
>>> the CSR.  None of the empirical validation mechanisms are appropriate; the
>>> authority token work might be relevant.
>>>
>>> - FIDO does not define or issue certificates of any type.
>>>
>>>
>>> FIDO uses public key pairs, using different sets of credentials (key
>>> pairs) for each service.  This is working well for authentication for
>>> many.  I’ve heard a few people say they have different use cases and I’m
>>> trying to figure out if we want identity proofing or just ties to a system
>>> or to know the same person holds a few keys on different devices if we
>>> define something.
>>>
>>
>> C'est magnifique, mais ce n'est pas un certificat.
>>
>> You could make it a challenge, though. Cf.
>> https://tools.ietf.org/html/draft-ietf-acme-acme-00#section-7.3
>>
>
> Sure, it's listed as an option in the draft for a challenge already if
> people were interested.
>

It would be helpful if you could go ahead and post the draft.



>
>>
>> --Richard
>>
>>
>>>
>>> Best regards,
>>> Kathleen
>>>
>>>
>>>
>>> On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson <
>>> hidinginthe...@gmail.com> wrote:
>>>
>>>> Thank you for your draft.
>>>>
>>>> As per the discussion from the WG meeting in Prague, my thoughts:
>>>>
>>>> Section 5, Device Certificates:
>>>> DNS/IP based challenges may be appropriate for on-premises hardware and
>>>> less appropriate for Cloud or IoT environments where a machine
>>>> requesting may not have DNS or suitable IP address. For Cloud
>>>> deployments it may be more desirable to tie the challenge to the
>>>> platform's respective IAM service using draft-ietf-acme-authority-token.
>>>>
>>>> In terms of actions, an informative document describing considerations
>>>> (such as ensuring "TLS Client Certificate Authentication" is set in
>>>> CSR,
>>>> like you describe) would probably be most appropriate in my view and I
>>>> would be happy to co-author or contribute to it if there was interest.
>>>>
>>>> Section 6, End User Certificates:
>>>> I had considered the idea of using ACME for end user certificates (and
>>>> believe it's worth it, particulary in enterprise environments), as I
>>>> was
>>>> unaware of the possibility of FIDO being used. However CAs and
>>>> implementors may find using ACME better for consistency sake as they
>>>> may
>>>> already be doing existing issuance using it.
>>>>
>>>> Browser support I believe remains the biggest challenge for this and I
>>>> would like to hear the thoughts from browser vendors on list.
>>>>
>>>> Regards
>>>>
>>>> On 20/03/2019 14:59, Kathleen Moriarty wrote:
>>>> > Hello,
>>>> >
>>>> > I am attaching a draft on several client certificate types to discuss
>>>> in
>>>> > Prague.  The draft intentionally leaves some open questions for
>>>> > discussion and I'll form the slides for the presentation in Prague
>>>> > around those questions.
>>>> >
>>>> > Thanks in advance for your review and discussion in Prague.
>>>> >
>>>> > Safe travels!
>>>> >
>>>> > --
>>>> >
>>>> > Best regards,
>>>> > Kathleen
>>>> >
>>>> > ___
>>>> > 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
>>>>
>>>
>
> --
>
> Best regards,
> Kathleen
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Client certificate draft

[Richard Barnes]

On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> I meant to respond inline as well.
>
> Sent from my mobile device
>
> On Mar 28, 2019, at 4:58 PM, Richard Barnes  wrote:
>
> To recap and extend some things that were said at the meeting:
>
> - ACME can already be used for client certificates that attest to domain
> names.  It's just an EKU difference, so it can be negotiated in the CSR.
>
> - ACME can already be used for code-signing certs, with external
> validation.  As with client certs, the relevant EKUs can be negotiated in
> the CSR.  None of the empirical validation mechanisms are appropriate; the
> authority token work might be relevant.
>
> - FIDO does not define or issue certificates of any type.
>
>
> FIDO uses public key pairs, using different sets of credentials (key
> pairs) for each service.  This is working well for authentication for
> many.  I’ve heard a few people say they have different use cases and I’m
> trying to figure out if we want identity proofing or just ties to a system
> or to know the same person holds a few keys on different devices if we
> define something.
>

C'est magnifique, mais ce n'est pas un certificat.

You could make it a challenge, though. Cf.
https://tools.ietf.org/html/draft-ietf-acme-acme-00#section-7.3

--Richard


>
> Best regards,
> Kathleen
>
>
>
> On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson 
> wrote:
>
>> Thank you for your draft.
>>
>> As per the discussion from the WG meeting in Prague, my thoughts:
>>
>> Section 5, Device Certificates:
>> DNS/IP based challenges may be appropriate for on-premises hardware and
>> less appropriate for Cloud or IoT environments where a machine
>> requesting may not have DNS or suitable IP address. For Cloud
>> deployments it may be more desirable to tie the challenge to the
>> platform's respective IAM service using draft-ietf-acme-authority-token.
>>
>> In terms of actions, an informative document describing considerations
>> (such as ensuring "TLS Client Certificate Authentication" is set in CSR,
>> like you describe) would probably be most appropriate in my view and I
>> would be happy to co-author or contribute to it if there was interest.
>>
>> Section 6, End User Certificates:
>> I had considered the idea of using ACME for end user certificates (and
>> believe it's worth it, particulary in enterprise environments), as I was
>> unaware of the possibility of FIDO being used. However CAs and
>> implementors may find using ACME better for consistency sake as they may
>> already be doing existing issuance using it.
>>
>> Browser support I believe remains the biggest challenge for this and I
>> would like to hear the thoughts from browser vendors on list.
>>
>> Regards
>>
>> On 20/03/2019 14:59, Kathleen Moriarty wrote:
>> > Hello,
>> >
>> > I am attaching a draft on several client certificate types to discuss
>> in
>> > Prague.  The draft intentionally leaves some open questions for
>> > discussion and I'll form the slides for the presentation in Prague
>> > around those questions.
>> >
>> > Thanks in advance for your review and discussion in Prague.
>> >
>> > Safe travels!
>> >
>> > --
>> >
>> > Best regards,
>> > Kathleen
>> >
>> > ___
>> > 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] Client certificate draft

[Richard Barnes]

To recap and extend some things that were said at the meeting:

- ACME can already be used for client certificates that attest to domain
names.  It's just an EKU difference, so it can be negotiated in the CSR.

- ACME can already be used for code-signing certs, with external
validation.  As with client certs, the relevant EKUs can be negotiated in
the CSR.  None of the empirical validation mechanisms are appropriate; the
authority token work might be relevant.

- FIDO does not define or issue certificates of any type.


On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson 
wrote:

> Thank you for your draft.
>
> As per the discussion from the WG meeting in Prague, my thoughts:
>
> Section 5, Device Certificates:
> DNS/IP based challenges may be appropriate for on-premises hardware and
> less appropriate for Cloud or IoT environments where a machine
> requesting may not have DNS or suitable IP address. For Cloud
> deployments it may be more desirable to tie the challenge to the
> platform's respective IAM service using draft-ietf-acme-authority-token.
>
> In terms of actions, an informative document describing considerations
> (such as ensuring "TLS Client Certificate Authentication" is set in CSR,
> like you describe) would probably be most appropriate in my view and I
> would be happy to co-author or contribute to it if there was interest.
>
> Section 6, End User Certificates:
> I had considered the idea of using ACME for end user certificates (and
> believe it's worth it, particulary in enterprise environments), as I was
> unaware of the possibility of FIDO being used. However CAs and
> implementors may find using ACME better for consistency sake as they may
> already be doing existing issuance using it.
>
> Browser support I believe remains the biggest challenge for this and I
> would like to hear the thoughts from browser vendors on list.
>
> Regards
>
> On 20/03/2019 14:59, Kathleen Moriarty wrote:
> > Hello,
> >
> > I am attaching a draft on several client certificate types to discuss in
> > Prague.  The draft intentionally leaves some open questions for
> > discussion and I'll form the slides for the presentation in Prague
> > around those questions.
> >
> > Thanks in advance for your review and discussion in Prague.
> >
> > Safe travels!
> >
> > --
> >
> > Best regards,
> > Kathleen
> >
> > ___
> > 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] RFC 8555 on Automatic Certificate Management Environment (ACME)

[Richard Barnes]

Thanks to everyone for your work on this!

On Mon, Mar 11, 2019 at 5:08 PM  wrote:

> A new Request for Comments is now available in online RFC libraries.
>
>
> RFC 8555
>
> Title:  Automatic Certificate Management Environment (ACME)
> Author: R. Barnes,
> J. Hoffman-Andrews,
> D. McCarney,
> J. Kasten
> Status: Standards Track
> Stream: IETF
> Date:   March 2019
> Mailbox:r...@ipv.sx,
> j...@eff.org,
> c...@letsencrypt.org,
> jdkas...@umich.edu
> Pages:  95
> Characters: 196903
> Updates/Obsoletes/SeeAlso:   None
>
> I-D Tag:draft-ietf-acme-acme-18.txt
>
> URL:https://www.rfc-editor.org/info/rfc8555
>
> DOI:10.17487/RFC8555
>
> Public Key Infrastructure using 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.  As of this writing, 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.
>
> This document is a product of the Automated Certificate Management
> Environment Working Group of the IETF.
>
> This is now a Proposed Standard.
>
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and
> suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for
> the
> standardization state and status of this protocol.  Distribution of this
> memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
> ___
> 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] Add badPublicKey error

[Richard Barnes]

On Thu, Jan 24, 2019 at 10:52 AM Salz, Rich  wrote:

> As WG co-chair, I am not thrilled with making this addition so very very
> late in the process.  If the WG wants to do it, we'd need (a) clear
> consensus and (b) a quick approval from the IESG.
>

Note that since the registration policy is "specification required", doing
this in an extension spec instead would not require the consent of the IESG..



> As an individual, I dislike putting "here's what's wrong with your key" in
> the error message. For example, it encourages a thief to do "venue
> shopping" looking for a CA that will certify their stolen keypair.
>

I think you're confused here, Rich.  This error code relates to *account
keys*, not keys that are certified by the CA.

--Richard



>
> On 1/24/19, 9:27 AM, "Rob Stradling"  wrote:
>
> I realize it's very late for making non-editorial changes to
> draft-ietf-acme-acme, but I'd like to propose adding a new
> badPublicKey
> error.  This error would be returned by the server whenever it does
> not
> support, or wishes to reject, a "jwk" public key supplied in a
> client's
> request.
>
> Proposed text: https://github.com/ietf-wg-acme/acme/pull/478
>
> The 'array of supported "alg" values' in a badSignatureAlgorithm
> response is useful, but ISTM that it doesn't provide detailed enough
> information to assist a client in generating a suitable public key.
>
> (If the consensus is that it's too late to add a new error type, then
> my
> alternative proposal will be to use "malformed" instead of adding
> "badPublicKey", but keep the rest of PR 478 as is; I think it's a good
> idea to call out the need for a server to sanity check each
> client-supplied public key).
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
>
> ___
> 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] Add badPublicKey error

[Richard Barnes]

This seems fine to me.  It's basically just a table entry, with some
description of how to use it.

--Richard

On Thu, Jan 24, 2019 at 9:26 AM Rob Stradling  wrote:

> I realize it's very late for making non-editorial changes to
> draft-ietf-acme-acme, but I'd like to propose adding a new badPublicKey
> error.  This error would be returned by the server whenever it does not
> support, or wishes to reject, a "jwk" public key supplied in a client's
> request.
>
> Proposed text: https://github.com/ietf-wg-acme/acme/pull/478
>
> The 'array of supported "alg" values' in a badSignatureAlgorithm
> response is useful, but ISTM that it doesn't provide detailed enough
> information to assist a client in generating a suitable public key.
>
> (If the consensus is that it's too late to add a new error type, then my
> alternative proposal will be to use "malformed" instead of adding
> "badPublicKey", but keep the rest of PR 478 as is; I think it's a good
> idea to call out the need for a server to sanity check each
> client-supplied public key).
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
>
> ___
> 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] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Richard Barnes]

Inline.

On Sun, Jan 20, 2019 at 3:04 PM Rifaat Shekh-Yusef 
wrote:

> I looked at the TNAuthList draft, and as far as I understand, the
> framework seems
> a bit different from this proposal:
>
> 1. A Token Authority is authoritative for multiple identifier spaces (e.g.
>TNAuthList with telephone numbers and service providers), while a
> Device
>Authority is responsible for one identifier space, i.e. the devices
>manufactured by a specific vendor.
>

Just because the framework can address the case where a single authority
can speak for multiple identifier spaces doesn't mean it can't also address
the single identifier space case.



> 2. A certificate issued to an entity controlled by a Token Authority is
> specific
>to that entity independent of any domain, while a certificate issued to
>a device controlled by a Device Authority is specific to the device
> *and* the
>Client domain (based on a Client account with ACME).
>

What do you mean by "domain" here?


>
>
> Also, I noticed that the TNAuthList proposal does support redirection, as
> an
> optional feature. In the Device Authority case this is not critical and
> could be
> left as optional too, which will simplify the flow even further, as it
> would
> allow us to drop Steps 3 & 4 from the flow described in section 2.4, which
> would
> look as follows without the redirection:
>
> Client Device Authority
>  ACME CA
> (customer.com)  (as.vendor.com)  (
> acme.com)
>   ||
>   |
>   | [01] POST /new-order [kid=customer.com, url=vendor.com,
> identifier={mac}|
>
> |>|
>   ||
>   |
>   |[02] 201
>  |
>   | [authorizations=vendor.com/acme/authz/1234,
>|
>   | finalize=customer.com/acme/order/asdf/finalize]
> |
>
> |<|
>   ||
>   |
>   | [03] Use OAuth to obtain a device JWT
>  |
>   |<==>|
>   |
>   ||
>   |
>   | [04] POST /vendor.com/acme/authz/1234 [JWT]
>|
>
> |>|
>   ||
>   |
>   ||[05] 200
> [status=valid] |
>
> |<|
>   ||
>   |
>   | [06] POST /customer.com/acme/order/asdf/finalize [CSR]
>   |
>
> |>|
>   ||
>   |
>   |[07] 200 [certificate=customer.com/acme/cert/asdf]
>  |
>
> |<|
>   ||
>   |
>   | [8] GET /customer.com/acme/cert/asdf
>   |
>
> |>|
>   ||
>   |
>   ||  [8] 200
> [certificate] |
>
> |<|
>   ||
>   |
>
>
> Unless I missed something, because of the above and to keep this mechanism
> as
> simple as possible, I would like to keep this proposal independent of the
> Token
> Authority framework at this stage.
>

I'm confused.  Issuing with authority tokens entails exactly the flow
you've laid out.  It's just that the interaction between the client and the
token authority is undefined in that doc, so you can fill it in with your
step 03.

--Richard


>
> Thoughts?
>
> Regards,
>  Rifaat
>
>
> On Thu, Jan 17, 2019 at 1:51 AM Richard Barnes  wrote:
>
>> It seems like the core of this draft is identifier delegation.  Namely,
>> the CA recognizes the DA as an authority for a certain identifier space
>> (e.g., the first few octets of a MAC address), and the JWT delegates
>> permission to issue certificates for some identifier in that space to the
>> Client.
>>
>> Given that, it seems to me like this could fit under the rubric of the
>> "authority token" challenge.  If you were to do what this draft wants to do
>> with that framework, the Client would have two separate interactions -- an

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Richard Barnes]

"Always be closing" :)

Or to cite a more ancient source:
"Quidquid facies, respice ad mortem"
"Whatever you do, contemplate death"
-- Seneca

On Thu, Jan 17, 2019 at 4:09 PM Salz, Rich  wrote:

> Richard always wants to close WG’s.  :) His views don’t necessarily
> reflect those of the AD’s or Chairs or the WG itself.  Don’t worry about it
> being more than just one opinion of an involved person. :)
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Richard Barnes]

I would add that if this is just another token type, it might not be
necessary to keep the WG open for it.  Good exercise for the secdispatch
process.

On Thu, Jan 17, 2019 at 12:49 Rifaat Shekh-Yusef 
wrote:

> Thanks Richard,
>
> The redirection is not critical part, and your explanation makes sense.
> I looked at the "authority token" documents a while ago; I will take a
> look again to see if I can align this document with that framework.
>
> Regards,
>  Rifaat
>
>
> On Thu, Jan 17, 2019 at 1:51 AM Richard Barnes  wrote:
>
>> It seems like the core of this draft is identifier delegation.  Namely,
>> the CA recognizes the DA as an authority for a certain identifier space
>> (e.g., the first few octets of a MAC address), and the JWT delegates
>> permission to issue certificates for some identifier in that space to the
>> Client.
>>
>> Given that, it seems to me like this could fit under the rubric of the
>> "authority token" challenge.  If you were to do what this draft wants to do
>> with that framework, the Client would have two separate interactions -- an
>> OAuth interaction with the DA to get a token, then an ACME interaction with
>> the CA to issue the certificate.  The only specification needed would be to
>> specify the identifier and token type, as has been done for TNAuthList [2].
>>
>> The only thing that would then be missing with regard to this draft is
>> that the CA wouldn't provide the redirect to the DA.  Whether that makes
>> sense depends on the use case, but I suspect that in most cases it does
>> not.  The design in the draft presumes there's a single DA per identifier,
>> and that the CA keeps a mapping table from possible identifiers to DAs.
>> That seems unlikely for most identifier spaces and most CAs with reasonably
>> broad coverage.  So losing this property of the draft doesn't seem like a
>> big issue.
>>
>> So net/net, I think this draft should be restructured along the lines of
>> [2], to just define a token type and maybe an identifier type.
>>
>> --Richard
>>
>> [1] https://tools.ietf.org/html/draft-ietf-acme-authority-token
>> [2]
>> https://tools.ietf.org/wg/acme/draft-ietf-acme-authority-token-tnauthlist/
>>
>> On Wed, Jan 16, 2019 at 12:33 PM Rifaat Shekh-Yusef <
>> rifaat.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> I have just submitted new updated version to address the issues raised
>>> by Ilari and Ryan.
>>> I would appreciate any more reviews and comments.
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>> -- Forwarded message -
>>> From: 
>>> Date: Wed, Jan 16, 2019 at 3:28 PM
>>> Subject: New Version Notification for
>>> draft-yusef-acme-3rd-party-device-attestation-01.txt
>>> To: Rifaat Shekh-Yusef 
>>>
>>>
>>>
>>> A new version of I-D,
>>> draft-yusef-acme-3rd-party-device-attestation-01.txt
>>> has been successfully submitted by Rifaat Shekh-Yusef and posted to the
>>> IETF repository.
>>>
>>> Name:   draft-yusef-acme-3rd-party-device-attestation
>>> Revision:   01
>>> Title:  Third-Party Device Attestation for ACME
>>> Document date:  2019-01-16
>>> Group:  Individual Submission
>>> Pages:  9
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-yusef-acme-3rd-party-device-attestation
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-yusef-acme-3rd-party-device-attestation-01
>>>
>>> Abstract:
>>>This document defines a Third-Party Device Attestation for ACME
>>>mechanism to allow the ACME CA to delegate some of its authentication
>>>and authorization functions to a separate trusted entity, to automate
>>>the issuance of certificates to devices.
>>>
>>>
>>>
>>>
>>> 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Richard Barnes]

It seems like the core of this draft is identifier delegation.  Namely, the
CA recognizes the DA as an authority for a certain identifier space (e.g.,
the first few octets of a MAC address), and the JWT delegates permission to
issue certificates for some identifier in that space to the Client.

Given that, it seems to me like this could fit under the rubric of the
"authority token" challenge.  If you were to do what this draft wants to do
with that framework, the Client would have two separate interactions -- an
OAuth interaction with the DA to get a token, then an ACME interaction with
the CA to issue the certificate.  The only specification needed would be to
specify the identifier and token type, as has been done for TNAuthList [2].

The only thing that would then be missing with regard to this draft is that
the CA wouldn't provide the redirect to the DA.  Whether that makes sense
depends on the use case, but I suspect that in most cases it does not.  The
design in the draft presumes there's a single DA per identifier, and that
the CA keeps a mapping table from possible identifiers to DAs.  That seems
unlikely for most identifier spaces and most CAs with reasonably broad
coverage.  So losing this property of the draft doesn't seem like a big
issue.

So net/net, I think this draft should be restructured along the lines of
[2], to just define a token type and maybe an identifier type.

--Richard

[1] https://tools.ietf.org/html/draft-ietf-acme-authority-token
[2]
https://tools.ietf.org/wg/acme/draft-ietf-acme-authority-token-tnauthlist/

On Wed, Jan 16, 2019 at 12:33 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> I have just submitted new updated version to address the issues raised by
> Ilari and Ryan.
> I would appreciate any more reviews and comments.
>
> Regards,
>  Rifaat
>
>
> -- Forwarded message -
> From: 
> Date: Wed, Jan 16, 2019 at 3:28 PM
> Subject: New Version Notification for
> draft-yusef-acme-3rd-party-device-attestation-01.txt
> To: Rifaat Shekh-Yusef 
>
>
>
> A new version of I-D, draft-yusef-acme-3rd-party-device-attestation-01.txt
> has been successfully submitted by Rifaat Shekh-Yusef and posted to the
> IETF repository.
>
> Name:   draft-yusef-acme-3rd-party-device-attestation
> Revision:   01
> Title:  Third-Party Device Attestation for ACME
> Document date:  2019-01-16
> Group:  Individual Submission
> Pages:  9
> URL:
> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/
> Htmlized:
> https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-yusef-acme-3rd-party-device-attestation
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-yusef-acme-3rd-party-device-attestation-01
>
> Abstract:
>This document defines a Third-Party Device Attestation for ACME
>mechanism to allow the ACME CA to delegate some of its authentication
>and authorization functions to a separate trusted entity, to automate
>the issuance of certificates to devices.
>
>
>
>
> 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Meeting in Prague?

[Richard Barnes]

I hold out hope that we can have the WG closed by Prague.  If we haven't,
and the collaborators on the phone stuff need to meet, that seems like it
can be handled as a side meeting.

On Tue, Jan 15, 2019 at 9:09 AM Salz, Rich  wrote:

> Should we meet in Prague?
>
>
>
> Most of our documents are in last-call or on the verge, and the other is
> the phone stuff which has a small group of collaborators who are working
> well together.
>
>
>
> Am quite happy to meet if the WG thinks it is worthwhile.
>
>
> ___
> 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] email-tls, identifiers, challenges

[Richard Barnes]

Hey all,

Following up on my comments at the mic today... It seems like we have few
questions here:

1. What identifiers do we envision going in the certificate?
2. What identifiers should be validated in ACME to support issuance for
those identifiers?
3. What challenges should be used to validate the ACME identifiers?

I agree with Tim and Alexey that it would be better to validate specific
ports, but that may not be the world we live in today.  TBH, though, given
that people are going to be writing fresh code for ACME, I'm inclined to
write the spec for the world we want, with the idea that CAs can update
their practices to go with the new code.

ISTM the architecturally clean way to do this is as follows:

1. Target the use case where SRVNames are in the certificate
2. Define an "srv" identifier type that encodes a name and a port number
3. Define the challenge types in the document as valid for the "srv"
identifier type

The main gap that leaves is that it doesn't define how to validate a "dns"
identifier with an email protocol.  (Here I'm assuming that there are mail
agents that can't do SRVName, so you need a dNSName)  Maybe you could say
that the email protocol challenges are good for "dns" identifiers as well,
but in that case, the ports for those challenges should be nailed down to
the default ports.

Hope that helps,
--Richard
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Richard Barnes]

On Mon, Oct 22, 2018 at 10:57 AM Kas  wrote:

>
> On 10/22/2018 5:40 PM, Richard Barnes wrote:
>
> On Mon, Oct 22, 2018 at 10:13 AM Kas 
> wrote:
>
>> Hi Richard,
>> The weak point here is the TLS connection so the question is :
>> How to prevent man in the middle from issuing a compromised certificate
>> to automated client ?
>>
>
> I don't understand what you're proposing here.  There's nothing we can do
> in a protocol to stop a CA from issuing any certificate it wants to.
> (That's why we have Baseline Requirements, audits, etc.)
>
> Are you worried about a MitM causing the real CA to issue a certificate to
> the MitM?  That risk is already addressed in ACME, but using *client*
> authentication, not server authentication -- what matters is the client
> from which the server accepts domain proof and a CSR, not what server the
> client thinks it's talking to.
>
>
> I am concerned about MitM issuing the certificate to the client.
>

Why does the MitM even need ACME for this?  Can't it just issue the
certificate?

Maybe your concern is that the MitM could convince the client to install
and serve TLS using a certificate of the MitM's choosing.  I can see how
that could be harmful, e.g., if the certificate had improper SANs in it.
This is addressed to a degree in the Operational Considerations [1], but
could probably be improved.  In any case, the right mitigation for this
risk is for the client to verify that the certificate chain looks sane
before installing it, since even the correct server could provide a
malicious cert chain.

[1] https://tools.ietf.org/html/draft-ietf-acme-acme-16#section-11.4


> or How to make sure TLS connection is not compromised ?
>>
>> TLS require self signed root certificates and CA certificate and this
>> compromise the client implementation and put weak points allowing attacks
>> or failure due to expired certificates ( compromised system ...) , all of
>> this can be prevented without waiting for/(or forcing) DANE by implementing
>> similar approach.
>> By adding such mechanism client can work securely forever, no certificate
>> to expire or revoke, such feature will eliminate the depending on system
>> provided CA certificates or any third-party source.
>>
>
> This sentence should cause you concern.  Nothing is forever in security.
>
> Using forever was wrong, i shouldn't say that.
>
>
> As I noted above, there is already no need for third-party resources..
>
> --Richard
>
>
>
>>
>> Best regards,
>> K. Obaideen
>>
>> On 10/22/2018 3:48 PM, Richard Barnes wrote:
>>
>> Hi Kas,
>>
>> Before launching into mechanism, maybe you could clarify what
>> authentication property you think is lacking here?
>>
>> Note that ACME already has server authentication, via TLS server
>> authentication.  All the normal PKI mitigations apply there: CT, HPKP,
>> etc.  It is also already the case that the CA can issue certificates for
>> its ACME server; no third party is needed.
>>
>> Thanks,
>> --Richard
>>
>> On Mon, Oct 22, 2018 at 7:06 AM Kas 
>> wrote:
>>
>>> It will be regrettable and unfortunate moment to pass on such
>>> opportunity to make the internet more secure, and please let me start
>>> with listing the facts:
>>>
>>> 1_ ACME Server is CA server, if you consider it a CA server then you
>>> don't need a third party to validate and secure the connection with such
>>> server.
>>> 2_ DANE is great but will not be adopted and needs years or a
>>> catastrophic failure by some CA to go mainstream, simply too many
>>> parties has it in conflict with their business model.
>>> 3_ SPF and DKIM are used in plain TXT DNS records and they already
>>> securing the internet the world.
>>> 4_ ACME protocol is utilizing DNS TXT record to authenticate the client
>>> so both server and client has DNS handling procedure.
>>> 5_ There is huge security hole in providing the root certificates to
>>> secure the internet, and in most cases it depends on the system store,
>>> many antivirus software installs with default settings to intercept
>>> HTTPS connection by injecting their own root certificate in system, many
>>> things can go wrong with system store, even extensions in a browser can
>>> do that.
>>>
>>> So why not authenticate ACME server in different way than DANE TLSA
>>> record and utilize TXT record similar to DKIM and make it a obligatory,
>>> this will allow two parties to securely communicate with only one
>>> requirement to trust one ACME server they alre

Re: [Acme] Please consider adding server authentication

[Richard Barnes]

On Mon, Oct 22, 2018 at 10:13 AM Kas 
wrote:

> Hi Richard,
> The weak point here is the TLS connection so the question is :
> How to prevent man in the middle from issuing a compromised certificate to
> automated client ?
>

I don't understand what you're proposing here.  There's nothing we can do
in a protocol to stop a CA from issuing any certificate it wants to.
(That's why we have Baseline Requirements, audits, etc.)

Are you worried about a MitM causing the real CA to issue a certificate to
the MitM?  That risk is already addressed in ACME, but using *client*
authentication, not server authentication -- what matters is the client
from which the server accepts domain proof and a CSR, not what server the
client thinks it's talking to.


> or How to make sure TLS connection is not compromised ?
>
> TLS require self signed root certificates and CA certificate and this
> compromise the client implementation and put weak points allowing attacks
> or failure due to expired certificates ( compromised system ...) , all of
> this can be prevented without waiting for/(or forcing) DANE by implementing
> similar approach.
> By adding such mechanism client can work securely forever, no certificate
> to expire or revoke, such feature will eliminate the depending on system
> provided CA certificates or any third-party source.
>

This sentence should cause you concern.  Nothing is forever in security.

As I noted above, there is already no need for third-party resources.

--Richard



>
> Best regards,
> K. Obaideen
>
> On 10/22/2018 3:48 PM, Richard Barnes wrote:
>
> Hi Kas,
>
> Before launching into mechanism, maybe you could clarify what
> authentication property you think is lacking here?
>
> Note that ACME already has server authentication, via TLS server
> authentication.  All the normal PKI mitigations apply there: CT, HPKP,
> etc.  It is also already the case that the CA can issue certificates for
> its ACME server; no third party is needed.
>
> Thanks,
> --Richard
>
> On Mon, Oct 22, 2018 at 7:06 AM Kas 
> wrote:
>
>> It will be regrettable and unfortunate moment to pass on such
>> opportunity to make the internet more secure, and please let me start
>> with listing the facts:
>>
>> 1_ ACME Server is CA server, if you consider it a CA server then you
>> don't need a third party to validate and secure the connection with such
>> server.
>> 2_ DANE is great but will not be adopted and needs years or a
>> catastrophic failure by some CA to go mainstream, simply too many
>> parties has it in conflict with their business model.
>> 3_ SPF and DKIM are used in plain TXT DNS records and they already
>> securing the internet the world.
>> 4_ ACME protocol is utilizing DNS TXT record to authenticate the client
>> so both server and client has DNS handling procedure.
>> 5_ There is huge security hole in providing the root certificates to
>> secure the internet, and in most cases it depends on the system store,
>> many antivirus software installs with default settings to intercept
>> HTTPS connection by injecting their own root certificate in system, many
>> things can go wrong with system store, even extensions in a browser can
>> do that.
>>
>> So why not authenticate ACME server in different way than DANE TLSA
>> record and utilize TXT record similar to DKIM and make it a obligatory,
>> this will allow two parties to securely communicate with only one
>> requirement to trust one ACME server they already asking it for
>> certificates, those parties can build secure internet environment based
>> on one ACME server, even this protocol can evolve in future to issue
>> certificates with only IP and no domain name, is that something wrong ?
>>
>> (listing few ideas, examples)
>> "acme.TLSA" TXT here you can copy the whole content of TLSA record in
>> JSON format encoded in base64url ( may be too much )
>> "acme.certs" TXT list the hash of the acme server certificates for
>> secure connection ( shouldn't be the root or CA certificate )
>> "acme.ckeys" TXT list the the certificates public keys in JWK format
>> with base64url encoding ( shouldn't be the root or CA certificate )
>> "acme.aKey" TXT contain one or more public keys (RSA or ECC) in JWK
>> (base64url) format this key can be used to authenticate responses from
>> acme server or only one critical response
>>
>>
>> "acme.dir" TXT the directory url encoded with base64url ( in this case
>> the client only need the server domain name like example.com or
>> staging.acme.example.com to get the acme directory )
>> "acme.chain" TXT ur

Re: [Acme] Please consider adding server authentication

[Richard Barnes]

Hi Kas,

Before launching into mechanism, maybe you could clarify what
authentication property you think is lacking here?

Note that ACME already has server authentication, via TLS server
authentication.  All the normal PKI mitigations apply there: CT, HPKP,
etc.  It is also already the case that the CA can issue certificates for
its ACME server; no third party is needed.

Thanks,
--Richard

On Mon, Oct 22, 2018 at 7:06 AM Kas  wrote:

> It will be regrettable and unfortunate moment to pass on such
> opportunity to make the internet more secure, and please let me start
> with listing the facts:
>
> 1_ ACME Server is CA server, if you consider it a CA server then you
> don't need a third party to validate and secure the connection with such
> server.
> 2_ DANE is great but will not be adopted and needs years or a
> catastrophic failure by some CA to go mainstream, simply too many
> parties has it in conflict with their business model.
> 3_ SPF and DKIM are used in plain TXT DNS records and they already
> securing the internet the world.
> 4_ ACME protocol is utilizing DNS TXT record to authenticate the client
> so both server and client has DNS handling procedure.
> 5_ There is huge security hole in providing the root certificates to
> secure the internet, and in most cases it depends on the system store,
> many antivirus software installs with default settings to intercept
> HTTPS connection by injecting their own root certificate in system, many
> things can go wrong with system store, even extensions in a browser can
> do that.
>
> So why not authenticate ACME server in different way than DANE TLSA
> record and utilize TXT record similar to DKIM and make it a obligatory,
> this will allow two parties to securely communicate with only one
> requirement to trust one ACME server they already asking it for
> certificates, those parties can build secure internet environment based
> on one ACME server, even this protocol can evolve in future to issue
> certificates with only IP and no domain name, is that something wrong ?
>
> (listing few ideas, examples)
> "acme.TLSA" TXT here you can copy the whole content of TLSA record in
> JSON format encoded in base64url ( may be too much )
> "acme.certs" TXT list the hash of the acme server certificates for
> secure connection ( shouldn't be the root or CA certificate )
> "acme.ckeys" TXT list the the certificates public keys in JWK format
> with base64url encoding ( shouldn't be the root or CA certificate )
> "acme.aKey" TXT contain one or more public keys (RSA or ECC) in JWK
> (base64url) format this key can be used to authenticate responses from
> acme server or only one critical response
>
>
> "acme.dir" TXT the directory url encoded with base64url ( in this case
> the client only need the server domain name like example.com or
> staging.acme.example.com to get the acme directory )
> "acme.chain" TXT url to download acme server certificate chain in secure
> manner
> "acme.store" TXT url to download the mini store for that acme server
> certificate trust in secure manner ( if this adopted then there will be
> many store provider like mozilla.com or android.com the client
> application can get his own store form his own sources, client trust
> Microsoft and its store but he can't be sure the store copy in his
> Windows is not tainted )
>
> Please consider discussion this.
>
> Best regards
> K. Obaideen
>
>
> ___
> 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] Adam Roach's Yes on draft-ietf-acme-acme-16: (with COMMENT)

[Richard Barnes]

Thanks for your review, Adam!

On Tue, Oct 16, 2018, 15:11 Adam Roach  wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-acme-acme-16: Yes
>
> 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:
> --
>
> Thanks for all the work that everyone has put into this protocol, and
> especially for the work that went into addressing the privacy issue that I
> identified. I'm excited by what ACME been able to do for the certificate
> issuance sector as a whole, and truly appreciate all of the early
> implementors
> who have put both clients and servers into active production.
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Richard Barnes]

This draft contains the latest (final?) round of changes:

Minor fixes related to POST-as-GET (#454)
Fixed typo: 'appear' instead of 'apper'. (#456)
Fix cross-reference in IANA considerations (#461)
Remove exception for certificate GET. (#459)
Tweak security concerns for URL correlations. (#463)
Forbid the use of 'nonce' in account roll-over (#464)
Revert "Revert "Randomize URLs in examples (#455)" (#458)" (#460)

Chairs, ADs: I believe this addresses all known issues and is ready to
proceed to the RFC Editor.

--Richard

On Fri, Oct 12, 2018 at 2:58 PM  wrote:

>
> 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-16.txt
> Pages   : 90
> Date: 2018-10-12
>
> 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-16
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-16
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-16
>
>
> 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
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] lack of nonce for external account binding (was Re: Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14:) (with DISCUSS and COMMENT)

[Richard Barnes]

On Wed, Oct 10, 2018 at 6:47 PM Benjamin Kaduk  wrote:

> On Wed, Oct 10, 2018 at 06:42:33PM -0400, Richard Barnes wrote:
> > On Wed, Oct 3, 2018 at 11:54 AM Benjamin Kaduk  wrote:
> >
> > > On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote:
> > > > On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote:
> > > > > > My co-author Daniel McCarney is working on the COMMENT comments.
> > > > >
> > > > > > IMPORTANT: I don't think I understand why "nonce" MUST NOT be
> > > present in
> > > > > > the external-binding JWS object, though I think I understand why
> one
> > > is
> > > > > not
> > > > > > needed in order to bind the MAC to the current transaction.
> (That
> > > is,
> > > > > this
> > > > > > is in effect a "triply nested" construct, where a standalone MAC
> that
> > > > > > certifies an ACME account (public) key as being authorized by the
> > > > > > external-account holder to act on behal of that external account.
> > > But
> > > > > this
> > > > > > standalone MAC will only be accepted by the ACME server in the
> > > context of
> > > > > > the outer JWS POST, that must be signed by the ACME account key,
> > > which is
> > > > > > assumed to be kept secure by the ACME client, ensuring that both
> > > > > > key-holding entities agree to the account linkage.)  Proof of
> > > freshness of
> > > > > > the commitment from the external account holder to authorize the
> ACME
> > > > > > account key would only be needed if there was a scenario where
> the
> > > > > external
> > > > > > account holder would revoke that association, which does not
> seem to
> > > be a
> > > > > > workflow supported by this document.  Any need to effectuate
> such a
> > > > > > revocation seems like it would involve issuing a new MAC key for
> the
> > > > > > external account (and invalidating the old one), and
> > > revoking/deactivating
> > > > > > the ACME account, which is a somewhat heavy hammer but perhaps
> > > reasonable
> > > > > > for such a scenario.
> > > > > > Account key rollover just says that the nonce is NOT REQUIRED,
> and
> > > also
> > > > > > uses some nicer (to me) language about "outer JWS" and "inner
> JWS".
> > > It
> > > > > > might be nice to synchronize these two sections.
> > > > >
> > > > > I defer on this to the other authors/people that want
> > > > > externalAccountBinding to
> > > > > be a thing.
> > > >
> > > > Okay.  I would like to avoid having needless normative requirements
> if
> > > > there is in fact no reason for this requirement.
> > >
> > > My apologies if I missed it when it went by, but did we ever hear more
> > > about this requirement from the proponents of externalAccountBinding?
> > >
> >
> > Picking this up...
> >
> > I actually have the opposite inclination to you here -- if a field is not
> > used by the protocol, then it should be forbidden, in the spirit of [1].
> > By that logic, we should also forbid the use of the "nonce" field in
> > roll-over.  I think it was just an oversight that we didn't.  The
> security
> > analysis that Bhargavan et al. did long ago did not presume any use of
> > it.   I've made a PR making it a MUST NOT:
> >
> > https://github.com/ietf-wg-acme/acme/pull/464
> >
> > [1] https://tools.ietf.org/html/draft-iab-protocol-maintenance-00
>
> Okay, a "MUST NOT" because anything not needed should be forbidden is a
> fine reason to me; thanks for putting together the PR to bring the two
> cases into consistency.
>

Thanks for the review!
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] lack of nonce for external account binding (was Re: Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14:) (with DISCUSS and COMMENT)

[Richard Barnes]

On Wed, Oct 3, 2018 at 11:54 AM Benjamin Kaduk  wrote:

> On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote:
> > On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote:
> > > > My co-author Daniel McCarney is working on the COMMENT comments.
> > >
> > > > IMPORTANT: I don't think I understand why "nonce" MUST NOT be
> present in
> > > > the external-binding JWS object, though I think I understand why one
> is
> > > not
> > > > needed in order to bind the MAC to the current transaction.  (That
> is,
> > > this
> > > > is in effect a "triply nested" construct, where a standalone MAC that
> > > > certifies an ACME account (public) key as being authorized by the
> > > > external-account holder to act on behal of that external account.
> But
> > > this
> > > > standalone MAC will only be accepted by the ACME server in the
> context of
> > > > the outer JWS POST, that must be signed by the ACME account key,
> which is
> > > > assumed to be kept secure by the ACME client, ensuring that both
> > > > key-holding entities agree to the account linkage.)  Proof of
> freshness of
> > > > the commitment from the external account holder to authorize the ACME
> > > > account key would only be needed if there was a scenario where the
> > > external
> > > > account holder would revoke that association, which does not seem to
> be a
> > > > workflow supported by this document.  Any need to effectuate such a
> > > > revocation seems like it would involve issuing a new MAC key for the
> > > > external account (and invalidating the old one), and
> revoking/deactivating
> > > > the ACME account, which is a somewhat heavy hammer but perhaps
> reasonable
> > > > for such a scenario.
> > > > Account key rollover just says that the nonce is NOT REQUIRED, and
> also
> > > > uses some nicer (to me) language about "outer JWS" and "inner JWS".
> It
> > > > might be nice to synchronize these two sections.
> > >
> > > I defer on this to the other authors/people that want
> > > externalAccountBinding to
> > > be a thing.
> >
> > Okay.  I would like to avoid having needless normative requirements if
> > there is in fact no reason for this requirement.
>
> My apologies if I missed it when it went by, but did we ever hear more
> about this requirement from the proponents of externalAccountBinding?
>

Picking this up...

I actually have the opposite inclination to you here -- if a field is not
used by the protocol, then it should be forbidden, in the spirit of [1].
By that logic, we should also forbid the use of the "nonce" field in
roll-over.  I think it was just an oversight that we didn't.  The security
analysis that Bhargavan et al. did long ago did not presume any use of
it.   I've made a PR making it a MUST NOT:

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

[1] https://tools.ietf.org/html/draft-iab-protocol-maintenance-00


>
> Thanks,
>
> Benjamin
>
> ___
> 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] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Richard Barnes]

Chairs: It looks like there's consensus among the author team to close out
this discussoin by merging #459, #460, and #463.  Is that all right with
you?

On Wed, Oct 10, 2018 at 5:23 PM Jacob Hoffman-Andrews  wrote:

> Pushed some more changes.
>
> On 10/10/2018 02:06 PM, Jacob Hoffman-Andrews wrote:
>
> Updated to include Orders and Authorizations in the example as you
> requested. https://github.com/ietf-wg-acme/acme/pull/463/files
>
> On 10/09/2018 04:49 PM, Jacob Hoffman-Andrews wrote:
>
> I'll revise this to include examples from the other URLs. One of my goals
> is to switch away from the "counting accounts" or "counting authzs"
> examples (which I think we can't effectively mitigate) to more specific
> examples of correlations. However, I think I can make that point with
> examples from across all the different resource types.
>
> On 10/09/2018 12:27 PM, Richard Barnes wrote:
>
> Thanks for the PR.
>
> My only issue is with the changes in there that slim down the example.
> ISTM that we should be encouraging unguessable URLs as widely as possible;
> guessable URLs should be a justified exception (as you noted in your
> description of what LE does).
>
> If you could slim this down to just killing the "Capability URL"
> reference, I would be +1
>
> On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews  wrote:
>
>> On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote:
>> > Also, I would add a caveat that this type of URL design is only
>> > necessary for properties that the CA considers secret. For instance,
>> > Let's Encrypt does not consider its number of accounts secret, and
>> > assigns serially incrementing IDs to account URLs.
>> >
>> > I'll send a PR later today tweaking this section.
>>
>> Here's a PR improving the correlations section of security concerns:
>> https://github.com/ietf-wg-acme/acme/pull/463
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
>
>
> ___
> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme
>
>
>
>
> ___
> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Richard Barnes]

You seem to be trying to approach this point-by-point.  What Adam and I
have been saying is that randomizing everything, you don't have to do the
analysis case by case.  That's why that's the desired recommendation --
it's conservative.

If you want to do the analysis, go ahead.  The URL plan is 100% up to the
server operator.  But the recommendation in the spec should be the
conservative one.

--Richard

On Tue, Oct 9, 2018 at 7:49 PM Jacob Hoffman-Andrews  wrote:

> I'll revise this to include examples from the other URLs. One of my goals
> is to switch away from the "counting accounts" or "counting authzs"
> examples (which I think we can't effectively mitigate) to more specific
> examples of correlations. However, I think I can make that point with
> examples from across all the different resource types.
>
> On 10/09/2018 12:27 PM, Richard Barnes wrote:
>
> Thanks for the PR.
>
> My only issue is with the changes in there that slim down the example.
> ISTM that we should be encouraging unguessable URLs as widely as possible;
> guessable URLs should be a justified exception (as you noted in your
> description of what LE does).
>
> If you could slim this down to just killing the "Capability URL"
> reference, I would be +1
>
> On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews  wrote:
>
>> On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote:
>> > Also, I would add a caveat that this type of URL design is only
>> > necessary for properties that the CA considers secret. For instance,
>> > Let's Encrypt does not consider its number of accounts secret, and
>> > assigns serially incrementing IDs to account URLs.
>> >
>> > I'll send a PR later today tweaking this section.
>>
>> Here's a PR improving the correlations section of security concerns:
>> https://github.com/ietf-wg-acme/acme/pull/463
>>
>> ___
>> 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] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Richard Barnes]

Thanks for the PR.

My only issue is with the changes in there that slim down the example.
ISTM that we should be encouraging unguessable URLs as widely as possible;
guessable URLs should be a justified exception (as you noted in your
description of what LE does).

If you could slim this down to just killing the "Capability URL" reference,
I would be +1

On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews  wrote:

> On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote:
> > Also, I would add a caveat that this type of URL design is only
> > necessary for properties that the CA considers secret. For instance,
> > Let's Encrypt does not consider its number of accounts secret, and
> > assigns serially incrementing IDs to account URLs.
> >
> > I'll send a PR later today tweaking this section.
>
> Here's a PR improving the correlations section of security concerns:
> https://github.com/ietf-wg-acme/acme/pull/463
>
> ___
> 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] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Richard Barnes]

So here's the compromise I would propose:

1. Remove GET for certificates.  I think this is a mistake, but I can grant
that it's clunky as-is, and it will be straightforward to re-add it later
if it's needed.

2. Keep the security considerations about capability URLs and the
randomized examples.  Those are needed for the correlation concerns
regardless of GET.

In units of PRs, I think that means:
- Merge #459 (remove GET for certificates)
- Merge #460 (randomize URLs)
- Close #462 (meta flag for GET; obsoleted by #459)
- Close #457 (remove recommendation for capability URLs; obsoleted by #459)

Jacob, Daniel: How does that strike you?

--Richard

On Tue, Oct 9, 2018 at 10:32 AM Daniel McCarney  wrote:

> I am also opposed to this change. I think it is a clunky solution and
> there hasn't been convincing justification of why the base ACME draft needs
> to carry this complexity instead of having STAR add the extensions it
> requires.
>
> On Mon, Oct 8, 2018 at 3:27 PM Jacob Hoffman-Andrews  wrote:
>
>> >   https://github.com/ietf-wg-acme/acme/pull/462
>> 
>>
>> I'm opposed to this change. It's better for STAR to just extend the Order
>> object with a new "gettableCert" URL field. Less complex.
>> ___
>> 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] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Richard Barnes]

No, because GET+capability > GET.  If you're going to have GET at all, you
should have GET+capability.

On Mon, Oct 8, 2018 at 12:43 PM Eric Rescorla  wrote:

> My question is whether you would remove the text that JSHA was objecting
> to about capabilities URLs.
>
> On Mon, Oct 8, 2018 at 6:31 AM Richard Barnes  wrote:
>
>> Not sure which existing text you're referring to.  No conflict comes to
>> mind.
>>
>> In particular, this seems compatible with the stuff in #post-as-get about
>> how the server indicates that it doesn't allow GET.  The model I have in
>> mind is that this flag indicates that it's reasonable for the client to try
>> GET, but the server may still deny in some cases.  Maybe that could be
>> clarified.
>>
>> On Mon, Oct 8, 2018, 09:24 Eric Rescorla  wrote:
>>
>>> Speaking as an individual.
>>>
>>> Just to be clear, this change would be expected to coexist with the
>>> existing capabilities text? Richard, does it require that we retain that
>>> text?
>>>
>>> -Ekr
>>>
>>>
>>> On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich  wrote:
>>>
>>>> WG, this PR adds a new optional indicator that GET can be used to fetch
>>>> certificates.
>>>>
>>>>
>>>>
>>>> If you opposed please speak up now.
>>>>
>>>>
>>>>
>>>> *From: *Richard Barnes 
>>>> *Reply-To: *ietf-wg-acme/acme <
>>>> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
>>>> >
>>>> *Date: *Sunday, October 7, 2018 at 3:47 PM
>>>> *To: *ietf-wg-acme/acme 
>>>> *Cc: *Subscribed 
>>>> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
>>>> requests for certificates are allowed (#462)
>>>>
>>>>
>>>>
>>>> This avoids the need for the client to guess. Assumes that #459
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_459=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=6yfRh9z504d7dO7AZHfqVaLK67f8VZUhbutg4HyibIs=>
>>>> will not be merged.
>>>> --
>>>> You can view, comment on, or merge this pull request online at:
>>>>
>>>>   https://github.com/ietf-wg-acme/acme/pull/462
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk=>
>>>> Commit Summary
>>>>
>>>>- Add a meta flag to indicate when GET requests for certificates
>>>>are allowed
>>>>
>>>> File Changes
>>>>
>>>>- *M* draft-ietf-acme-acme.md
>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462_files-23diff-2D0=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=3-t1zAmt-HqR18SwnxsCgquqZyRAmp77GPE5ARp-XPg=>
>>>>(4)
>>>>
>>>> Patch Links:
>>>>
>>>>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.patch=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=iLEjv5GNBU4uXvONa0gllnpyj3HovrLyy5nqQK-zvYo=>
>>>>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.diff=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=8CNiNAnFkQae97gch-t0HidpnAqkaBJQ8su695zMYX0=>
>>>>
>>>> —
>>>> You are receiving this because you are subscribed to this thread.
>>>> Reply to this email directly, view it on GitHub
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk=>,
>>>> or mute the thread
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AG-5FilACJeDnYH-2DFetofUArLOJQvAVdpKks5uilpMgaJpZM4XMAP2=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=r8HeHSMQ1w62iouWigror9a1ItZfkYtv9oNryK1PXMo=>
>>>> .[image:
>>>> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
>>>> ___
>>>> 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] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Richard Barnes]

Not sure which existing text you're referring to.  No conflict comes to
mind.

In particular, this seems compatible with the stuff in #post-as-get about
how the server indicates that it doesn't allow GET.  The model I have in
mind is that this flag indicates that it's reasonable for the client to try
GET, but the server may still deny in some cases.  Maybe that could be
clarified.

On Mon, Oct 8, 2018, 09:24 Eric Rescorla  wrote:

> Speaking as an individual.
>
> Just to be clear, this change would be expected to coexist with the
> existing capabilities text? Richard, does it require that we retain that
> text?
>
> -Ekr
>
>
> On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich  wrote:
>
>> WG, this PR adds a new optional indicator that GET can be used to fetch
>> certificates.
>>
>>
>>
>> If you opposed please speak up now.
>>
>>
>>
>> *From: *Richard Barnes 
>> *Reply-To: *ietf-wg-acme/acme <
>> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
>> >
>> *Date: *Sunday, October 7, 2018 at 3:47 PM
>> *To: *ietf-wg-acme/acme 
>> *Cc: *Subscribed 
>> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
>> requests for certificates are allowed (#462)
>>
>>
>>
>> This avoids the need for the client to guess. Assumes that #459
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_459=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=6yfRh9z504d7dO7AZHfqVaLK67f8VZUhbutg4HyibIs=>
>> will not be merged.
>> --
>> You can view, comment on, or merge this pull request online at:
>>
>>   https://github.com/ietf-wg-acme/acme/pull/462
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk=>
>> Commit Summary
>>
>>- Add a meta flag to indicate when GET requests for certificates are
>>allowed
>>
>> File Changes
>>
>>- *M* draft-ietf-acme-acme.md
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462_files-23diff-2D0=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=3-t1zAmt-HqR18SwnxsCgquqZyRAmp77GPE5ARp-XPg=>
>>(4)
>>
>> Patch Links:
>>
>>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.patch=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=iLEjv5GNBU4uXvONa0gllnpyj3HovrLyy5nqQK-zvYo=>
>>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.diff=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=8CNiNAnFkQae97gch-t0HidpnAqkaBJQ8su695zMYX0=>
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk=>,
>> or mute the thread
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AG-5FilACJeDnYH-2DFetofUArLOJQvAVdpKks5uilpMgaJpZM4XMAP2=DwMCaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w=r8HeHSMQ1w62iouWigror9a1ItZfkYtv9oNryK1PXMo=>
>> .[image:
>> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
>> ___
>> 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] Allow get for certificates?

[Richard Barnes]

I went ahead and posted a PR adding the "meta" field:

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


On Sun, Oct 7, 2018 at 5:04 AM Thomas Fossati 
wrote:

> The 10/06/2018 17:27, Richard Barnes wrote:
> > I'm not hard set against this change, I just don't see much benefit.
> >
> > Allowing GETs for certificate URLs is so low-risk that we weren't going
> to
> > access-control it at all until a couple weeks ago.  Now it's so high-risk
> > that we need to REQUIRE authentication?  That's "REQUIRED" in the RFC
> 2119
> > sense, since higher up in the section, it says that servers MUST return
> 405
> > if they get a GET, except as allowed in that section.
> >
> > There are reasonable use cases for GETs.  STAR is one, but you could
> > imagine non-auto-renewed cases as well.  There's no security reason to
> cut
> > off those GETs, so I don't understand what value we're conserving here.
> > The PR says that having GETs complicates the security analysis, but this
> is
> > not some inner part of the protocol, it's the output.
>
> From the point of view of STAR this is not a big deal.  We have
> acme-star where to define both the plain-GET exception - which is a core
> requirement for the delegation workflow - and how the server advertises
> support for it.
>
> My worry is that by accepting this change, other legit plain-GET use
> cases are automatically made either more complicated or potentially
> insecure (someone might decide that sharing the account key across a
> bunch of edge caches or some other HA configuration is a worth
> trade-off.)
>
> That said...
>
> > The only argument that seems at all cogent here is that we don't have
> > any up-front signaling for whether a server supports GET or not, just
> > the error code.  So clients have to guess.  Maybe that's enough to
> > motivate removing it for now; a later doc could come along and say
> > "allow GETs and signal it with this field in the meta object".
>
> ... it should be pretty easy to add the needed meta object extension
> directly into the acme-acme document if this is the only missing piece?
>
> > But if we do that, we should be clear that we're removing GET to keep
> > the protocol flow clean, not for any security reason.
>
> Emphatic +1
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Randomizing URLs in examples

[Richard Barnes]

I didn't merge, I just opened the PR so that we could have the discussion.

On Sat, Oct 6, 2018, 17:44 Salz, Rich  wrote:

> The fact that there were open concerns does not mean that PR455 was wrong.
>
>
>
> Please undo the revert that was part of PR458.
>
>
>
> EVERYONE.  Stop merging.  Discuss on the list.
>
>
>
> *From: *Richard Barnes 
> *Date: *Saturday, October 6, 2018 at 5:38 PM
> *To: *"acme@ietf.org" 
> *Subject: *[Acme] Randomizing URLs in examples
>
>
>
> I have opened a PR reverting Jacob's reversion of the #455
>
>
>
> https://github.com/ietf-wg-acme/acme/pull/460
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_460=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=BVuDxcfZ6gqvMhTwPx5_IBrSGYyRDKXFz44zpUDqYzk=-UB6HkBx9D0IC9vVtH33vUa91KYUENpYQ8Ngn63FQfo=>
>
>
>
> The randomization of examples is independent of whether you think GETs are
> a good idea or not.  As noted in the Security Considerations, having
> different types of resources in different namespaces, with unpredictable
> URLs, prevents attackers from discovering correlations if, say, a URL leaks.
>
>
>
> Any objections to this change?
>
>
>
> --Richard
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Randomizing URLs in examples

[Richard Barnes]

I have opened a PR reverting Jacob's reversion of the #455

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

The randomization of examples is independent of whether you think GETs are
a good idea or not.  As noted in the Security Considerations, having
different types of resources in different namespaces, with unpredictable
URLs, prevents attackers from discovering correlations if, say, a URL leaks.

Any objections to this change?

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

Re: [Acme] Allow get for certificates?

[Richard Barnes]

I'm not hard set against this change, I just don't see much benefit.

Allowing GETs for certificate URLs is so low-risk that we weren't going to
access-control it at all until a couple weeks ago.  Now it's so high-risk
that we need to REQUIRE authentication?  That's "REQUIRED" in the RFC 2119
sense, since higher up in the section, it says that servers MUST return 405
if they get a GET, except as allowed in that section.

There are reasonable use cases for GETs.  STAR is one, but you could
imagine non-auto-renewed cases as well.  There's no security reason to cut
off those GETs, so I don't understand what value we're conserving here.
The PR says that having GETs complicates the security analysis, but this is
not some inner part of the protocol, it's the output.

The only argument that seems at all cogent here is that we don't have any
up-front signaling for whether a server supports GET or not, just the error
code.  So clients have to guess.  Maybe that's enough to motivate removing
it for now; a later doc could come along and say "allow GETs and signal it
with this field in the meta object".  But if we do that, we should be clear
that we're removing GET to keep the protocol flow clean, not for any
security reason.

--Richard



On Sat, Oct 6, 2018 at 12:53 PM Eric Rescorla  wrote:

> Speaking as Area Director: there is no process problem with this
> reference. Of course, it's a WG decision whether it's advisable.
>
> -Ekr
>
>
> On Sat, Oct 6, 2018 at 8:31 AM Salz, Rich  wrote:
>
>> In order to address an issue raised during IESG review, unauthenticated
>> GET for ACME server resources was changed to a simple POST that had a
>> signed message body, providing authentication. Some raised the issue that
>> they still wanted GET for certificates, as they’re public information and
>> that sometimes a different process (without the account credentials) might
>> be involved in the deployment workflow.  STAR was mentioned as an example.
>>
>>
>>
>> There is now concern about calling out STAR, as it is still a WG draft
>> and the full extent of its requirements are not known.
>>
>>
>>
>> If you have anything else to add to this discussion, please do so now.
>>
>>
>>
>> diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
>>
>> index 26f..f1ca93f 100644
>>
>> --- a/draft-ietf-acme-acme.md
>>
>> +++ b/draft-ietf-acme-acme.md
>>
>> @@ -463,17 +463,6 @@ resources (see {{resources}}), in addition to
>> POST-as-GET requests
>>
>> for these resources.  This enables clients to bootstrap into the
>>
>> ACME authentication system.
>>
>> -The server MAY allow GET requests for certificate resources in
>>
>> -order to allow certificates to be fetched by a lower-privileged
>>
>> -process, e.g., the web server that will use the referenced
>>
>> -certificate chain.  (See {{?I-D.ietf-acme-star}} for more advanced
>>
>> -cases.)  A server that allows GET requests for certificate resources
>>
>> -can still provide a degree of access control by assigning them
>>
>> -capability URLs {{?W3C.WD-capability-urls-20140218}}.
>>
>> -As above, if the server does not allow GET requests for a given
>>
>> -resource, it MUST return an error with status code 405 "Method Not
>>
>> -Allowed" and type "malformed".
>>
>> -
>>
>> ## Request URL Integrity
>>
>>  It is common in deployment for the entity terminating TLS for HTTPS to
>> be different
>>
>>
>> ___
>> 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] Backing-out capability URLs from the spec (added in #445)

[Richard Barnes]

On Fri, Oct 5, 2018 at 1:41 PM Adam Roach  wrote:

> [as an individual]
>
> On 10/5/18 11:21 AM, Jacob Hoffman-Andrews wrote:
>
> In the rounds of reviews on https://github.com/ietf-wg-acme/acme/pull/445,
> I missed an addition: the suggestion to use capability URLs for access
> control on certificate URLs. We should definitely not introduce this into
> the spec: ACME has one authentication model, based on JWS signing. We
> shouldn't introduce another, weaker authentication model. I pointed this
> out way back in 2015:
> https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712.
>
> At the time, the WG decision was to split resources into sensitive ones
> (authenticated) and non-sensitive ones (unauthenticated). The recent round
> of POST-as-GET changes consolidates things so nearly everything is
> authenticated. I don't think there's a strong case to introduce a new,
> halfway level of authentication based on capability URLs. If we want
> certificates to be authenticated, let's authenticate them the same way as
> everything else, and let the STAR group define an extension for
> unauthenticated URLs. Here's my PR backing out the change:
> https://github.com/ietf-wg-acme/acme/pull/457
>
>
> I oppose this change. The removed language is a non-normative statement
> of fact for the benefit of implementors. Removing it does not change the
> fact that capability URLs can be used in this context; it simply hides this
> fact from the reader.
>
I think Adam is on the right track here.

Jacob: The change you're proposing makes security worse.  The security
properties of GET-without-capability-URLs are strictly worse than
GET-with-capability-URLs.  It seems like you're trying to get rid of a
better option to maintain the appearance architectural purity.

--Richard


/a
> ___
> 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] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Richard Barnes]

In the spirit of giving credit where credit is due: I just noticed that
Sophie Herold had suggested making URLs non-guessable all the way back in
January [0].  Not sure why that got missed at the time (looks like we got
distracted by the reasoning), but retroactive thanks to Sophie!

[0] https://mailarchive.ietf.org/arch/msg/acme/usaOr4Bnyma4jX1fjfE4Lftai8E

On Thu, Aug 30, 2018 at 6:50 AM Adam Roach  wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-acme-acme-14: Discuss
>
> 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/
>
>
>
> --
> DISCUSS:
> --
>
> Thanks for all the work that everyone has put into this protocol. I'm
> excited by
> what it's been able to do for the certificate issuance sector as a whole,
> and
> truly appreciate all of the early implementors who have put both clients
> and
> servers into active production. I'm definitely balloting YES once we get
> clarity
> on my DISCUSS, below.
>
> ---
>
> I've looked at this several different ways, and I must be missing something
> obvious -- which should make this easy to clear.
>
> §6.2:
>
> >  Note that authentication via signed JWS request bodies implies that
> >  GET requests are not authenticated.  Servers MUST NOT respond to GET
> >  requests for resources that might be considered sensitive.  Account
> >  resources are the only sensitive resources defined in this
> >  specification.
>
> This doesn't seem correct.
>
> For example, let's imagine that I, as a user, get the directory for an ACME
> server, the body of which is the example in §7.1.1. Then, I go through the
> new-account process, and receive the Account object in §7.1.2:
>
>{
>  "status": "valid",
>  "contact": [
>"mailto:cert-ad...@example.com;,
>"mailto:ad...@example.com;
>  ],
>  "termsOfServiceAgreed": true,
>  "orders": "https://example.com/acme/acct/1/orders;
>}
>
> Huh. Suddenly, I'm not so interested in *my* orders, because I've noticed
> that
> different users' orders are apparently at a predictable URL that varies
> only by
> a small integer. Curious, I change the "1" to a "2" and send:
>
>   GET /acme/acct/2/orders HTTP/1.1
>   Host: example.com
>
> And get back not *my* orders, but someone *else's* orders.
>
>HTTP/1.1 200 OK
>Content-Type: application/json
>
>{
>  "orders": [
>"https://example.com/acme/acct/2/order/1;,
>"https://example.com/acme/acct/2/order/2;,
>"https://example.com/acme/acct/2/order/3;,
>"https://example.com/acme/acct/2/order/4;
>  ]
>}
>
> Interesting. So now I can do four more unauthenticated GETs and grab those
> order
> objects.
>
>HTTP/1.1 200 OK
>Content-Type: application/json
>
>{
>  "status": "valid",
>  ...
>  "identifiers": [
>{ "type": "dns", "value": "smithforcongress.example" }
>  ],
>  ...
>  "certificate": "https://example.com/acme/cert/1234;
>}
> --
>HTTP/1.1 200 OK
>Content-Type: application/json
>
>{
>  "status": "valid",
>  ...
>  "identifiers": [
>{ "type": "dns", "value":
> "something-embarassing-with-goats.example" }
>  ],
>  ...
>  "certificate": "https://example.com/acme/cert/5678;
>}
> --
>HTTP/1.1 200 OK
>Content-Type: application/json
>
>{
>  "status": "valid",
>  ...
>  "identifiers": [
>{ "type": "email", "value": "smith-personal@obscure-domain.example"
> }
>  ],
>  ...
>  "certificate": "https://example.com/acme/cert/9abc;
>}
> --
>HTTP/1.1 200 OK
>Content-Type: application/json
>
>{
>  "status": "valid",
>  ...
>  "identifiers": [
>{ "type": "tn", "value": "+12025550172" }
>  ],
>  ...
>  "certificate": "https://example.com/acme/cert/defg;
>}
>
> So now I've learned that the same account has pulled certs for both
> "smithforcongress.example" and "something-embarassing-with-goats.example";
> that
> they have control over the email address
> "smith-personal@obscure-domain.example," and that their phone number is
> +1 202
> 555 0172. There's a pretty good chance that... someone didn't want all of
> that
> to be generally known.
>
> And... huh... that's interesting.
>
>  GET /acme/cert/9abc HTTP/1.1
>  Host: example.com
>
>  HTTP/1.1 200 OK
>  Content-Type: 

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

[Richard Barnes]

lem 10:
>
>{
>  "protected": base64url({
>"alg": "ES256",
>"kid": "https://example.com/acme/acct/1; 
> <https://example.com/acme/acct/1>,
>"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
>"url": "https://example.com/acme/new-authz; 
> <https://example.com/acme/new-authz>
>  }),
>  "payload": base64url({
>"identifier": {
>  "type": "dns",
>  "value": "example.net"
>}
>  }),
>  "signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
>}
>
>
> Problem 11:
>
>POST /acme/authz/1234 HTTP/1.1
>Host: example.com
>Content-Type: application/jose+json
>Accept: application/pkix-cert
>
>{
>  "protected": base64url({
>"alg": "ES256",
>"kid": "https://example.com/acme/acct/1; 
> <https://example.com/acme/acct/1>,
>"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
>"url": "https://example.com/acme/authz/1234; 
> <https://example.com/acme/authz/1234>,
>  }),
>  "payload": "",
>  "signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
>}
>
>HTTP/1.1 200 OK
>Content-Type: application/json
>Link: <https://example.com/acme/some-directory> 
> <https://example.com/acme/some-directory>;rel="index"
>
>{
>  "status": "pending",
>  "expires": "2018-03-03T14:09:30Z",
>
>  "identifier": {
>"type": "dns",
>"value": "example.org"
>  },
>
>  "challenges": [
>{
>  "type": "http-01",
>  "url": "https://example.com/acme/authz/1234/0; 
> <https://example.com/acme/authz/1234/0>,
>  "token": "DGyRejmCefe7v4NfDGDKfA"
>},
>{
>  "type": "dns-01",
>  "url": "https://example.com/acme/authz/1234/2; 
> <https://example.com/acme/authz/1234/2>,
>  "token": "DGyRejmCefe7v4NfDGDKfA"
>}
>  ],
>
>  "wildcard": false
>}
>
>
> Problem 12:
>
>POST /acme/authz/1234/0 HTTP/1.1
>Host: example.com
>Content-Type: application/jose+json
>
>{
>  "protected": base64url({
>"alg": "ES256",
>"kid": "https://example.com/acme/acct/1; 
> <https://example.com/acme/acct/1>,
>"nonce": "Q_s3MWoqT05TrdkM2MTDcw",
>"url": "https://example.com/acme/authz/1234/0; 
> <https://example.com/acme/authz/1234/0>
>  }),
>  "payload": base64url({}),
>  "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
>}
>
>
> Problem 13:
>
>POST /acme/authz/1234 HTTP/1.1
>Host: example.com
>Content-Type: application/jose+json
>Accept: application/pkix-cert
>
>{
>  "protected": base64url({
>"alg": "ES256",
>"kid": "https://example.com/acme/acct/1; 
> <https://example.com/acme/acct/1>,
>"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
>"url": "https://example.com/acme/authz/1234; 
> <https://example.com/acme/authz/1234>,
>  }),
>  "payload": "",
>  "signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
>}
>
>HTTP/1.1 200 OK
>Content-Type: application/json
>
>{
>  "status": "valid",
>  "expires": "2018-09-09T14:09:01.13Z",
>
>  "identifier": {
>"type": "dns",
>"value": "example.org"
>  },
>
>  "challenges": [
>{
>  "type": "http-01",
>  "url": "https://example.com/acme/authz/1234/0; 
> <https://example.com/acme/authz/1234/0>,
>  "status": "valid",
>  "validated": "2014-12-01T12:05:13.72Z",
>  "token": "IlirfxKKXAsHtmzK29Pj8A"
>}
>  ],
>
>  "wildcard": false
>}
>
>
> Problem 14:
>
>POST /acme/au

Re: [Acme] malformedRequest vs. malformed in draft-ietf-acme-acme-15

[Richard Barnes]

Thanks, Felix, good catch.  I have implemented this fix in the following PR:

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

Please take a look and let me know if that looks good.

On Tue, Oct 2, 2018 at 9:56 PM Felix Fontein  wrote:

> Hi,
>
> while looking at POST-as-GET support for account URLs, I noticed that
> draft-ietf-acme-acme-15 mentions an error called "malformedRequest" in
> two places (w.r.t. POST-as-GET), while the error is simply called
> "malformed" in the list in Section 6.7. I think this is an oversight
> and they should be the same, i.e. either "malformed" (as until now) or
> "malformedRequest" (which would be a breaking change).
>
> Best regards,
> Felix
>
>
> ___
> 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] Mismatch between example and text in 7.4.2 of draft-ietf-acme-acme-15

[Richard Barnes]

Thanks, David, good idea.  I have implemented this fix (with slightly
different words) in this PR:

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

On Sat, Sep 29, 2018 at 7:07 PM David Hancock 
wrote:

> In section 7.4.2. "Downloading the Certificate", the text doesn't match
> the example (text says use POST-as-GET, but the example still shows GET). I
> thought this was a flat-out error until I noticed the text in section
> 6.3 that says GET may be supported in this case.
>
>
> To avoid confusion, I propose that we update the example in 7.4.2. to
> show POST-as-GET, to match the text, and add a sentence after the example
> that says something like...
>
>
> ''If supported by the server, an ACME client can also use a GET request
> to download the issued certificate (see section 6.3)."
>
>
> Thanks,
>
> David
>
>
>
> ___
> 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] New Version Notification for draft-ietf-acme-acme-15.txt

[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] Tightening up the PEM cert chain type

[Richard Barnes]

FYI:

In response to a GitHub issue[1], I have filed a PR [2] to tighten up the
definition of the application/pem-certificate-chain media type in two ways:

1. Forbid explanatory text
2. Require the "strict" format

Chairs: OK to handle this on the same "comments-by-Friday" basis as the
GET-as-POST PR?

--Richard

[1] https://github.com/ietf-wg-acme/acme/issues/446
[2] https://github.com/ietf-wg-acme/acme/pull/452
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

After the weekend's discussions, I've updated the PR to reflect what I
understand to be emerging agreement on these topics:

ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the
privacy analysis?
PROPOSED RESOLUTION: Yes.

ISSUE 2: How should we signal that POST-as-GET request is different from
other POST requests?
PROPOSED RESOLUTION: A JWS with a zero-octet payload ("")

ISSUE 3: Should servers be required to allow GET requests for certificate
URLs?
PROPOSED RESOLUTION: No, but they MAY

ISSUE 4: How should we address the risk that an attacker can discover URLs
by probing for Unauthorized vs. Not Found?
PROPOSED RESOLUTION: Security considerations that recommend
non-correlatable URL plans

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

Adam: Is this looking like an approach that would satisfy your DISCUSS?

Chairs / EKR: How would you like to proceed on closing this out?  What are
the next process steps?


On Fri, Aug 31, 2018 at 6:08 PM Richard Barnes  wrote:

> Hey all,
>
> This thread forked into a couple of different issues, so I wanted to post
> a little end-of-day summary of the issues and where we stand.  I've updated
> the PR [1] to reflect most of today's discussion.
>
> ===
>
> ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the
> privacy analysis?
>
> It seems like there's pretty strong agreement that we should get rid of
> GET, as the architecturally cleanest option.
>
> ===
>
> ISSUE 2: How should we signal that POST-as-GET request is different from
> other POST requests?
>
> The current PR signals this by sending a JWS with an empty (zero-octet)
> payload, instead of a JSON object.  Jacob and Daniel suggested that we
> should instead use the payload being an empty JSON object as the signal.
> An earlier draft PR used a field in the protected header.
>
> ===
>
> ISSUE 3: Should servers be required to allow GET requests for certificate
> URLs?
>
> I had proposed this earlier today; Jacob and Daniel pushed back.  I have
> implemented a compromise in the latest PR, where servers MAY accept GET
> requests.
>
> ===
>
> ISSUE 4: How should we address the risk that an attacker can discover URLs
> by probing for Unauthorized vs. Not Found?
>
> There seemed to be agreement on the list that this should be addressed
> with some guidance to servers on how to assign URLs.  I have just added
> some text to the PR for this.
>
> ===
>
> It seems to me we're pretty much closed on the first issue, and the other
> three are still open.  Please send comments, so we can resolve this issue
> and get the document back in motion!
>
> Thanks,
> --Richard
>
> [1] https://github.com/ietf-wg-acme/acme/pull/445
>
> On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews 
> wrote:
>
>> ACME currently has unauthenticated GETs for some resources. This was
>> originally discussed in January 2015[1]. We decided to put all sensitive
>> data in the account resource and consider all GET resources public, with
>> a slant towards transparency.
>>
>> Adam Roach recently pointed out in his Area Director review that even
>> when the contents of GET URLs aren’t sensitive, their correlation may
>> be. For instance, some CAs might consider the grouping of certificates
>> by account to be sensitive.
>>
>> Richard Barnes proposes[2] to change all GETs to POSTs (except directory
>> and new-nonce). This will be a breaking change. Clients that were
>> compatible with previous drafts, informally called ACMEv1 and ACMEv2,
>> will not be compatible with a draft that mandates POSTs everywhere. It
>> will be a painful change, since the ecosystem just started switching to
>> ACMEv2, which looked to be near-final.
>>
>> I think this is the right path forwards. ACME will be a simpler, better
>> protocol long-term if all requests are authenticated. However, if we’re
>> taking this path we should aim to come to consensus and land the final
>> spec quickly to reduce uncertainty for ACME client implementers.
>>
>> [1]
>> https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
>> [2] https://github.com/ietf-wg-acme/acme/pull/445/files
>>
>> ___
>> 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] POST-as-GET payload contents

[Richard Barnes]

On Wed, Sep 5, 2018 at 3:43 PM Jacob Hoffman-Andrews  wrote:

> On 09/05/2018 12:39 PM, Richard Barnes wrote:
> > Using the same notation, I'm:
> >
> > 1) ""
> > 2) "urn:ietf:params:acme:get"
> > 99) "{}"
>
> Given that, I'm willing to compromise on "". I think the experience we
> had of almost implementing bugs with that approach was informative, but
> isn't decisive.
>

Thanks for compromising.  I agree that the interop stuff will cause some
hiccups, but hopeful that rather than being a blocker for folks, it will
create some pressure for JOSE libraries to interop better in this case.  In
any case, I'll update the PR to make extra clear that {payload: ""} is
what's required.

Anyone else have opinions before we consider this closed?

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

Re: [Acme] POST-as-GET payload contents

[Richard Barnes]

Using the same notation, I'm:

1) ""
2) "urn:ietf:params:acme:get"
99) "{}"

The problem with "{}" is not just what it conflicts with in the current
doc, it's that it constrains everything one might do in the future.  Same
with any other payload-only option (including {"get": true}) with valid
JSON payload.  So your options are (1) do something in the protected header
or (2) have the payload be something non-JSON.

If you want something payload-only that is not empty, that seems doable as
well.  We could require the payload to be the two-octet string 0x1844,
which conveniently base64url-encodes to "GET" :)

On Wed, Sep 5, 2018 at 1:17 PM Jacob Hoffman-Andrews  wrote:

> On 09/05/2018 08:33 AM, Richard Barnes wrote:
> > 1. A field in the protected header ("urn:ietf:params:acme:get": true)
> > with a requirement that the payload be "{}"
> > 2. A field in the payload ({"get": true}) a requirement that if that
> > field be there, then there are no other fields present
>
> I dislike both of these options as adding complexity. My preference
> order is:
>
> 1) "{}"
> 2) ""
> 99) "urn:ietf:params:acme:get"
>
>  > I'm still uncomfortable with {}, though, because it risks colliding
> with other POST uses.
>
> The only current use it conflicts with is POSTing to challenges to
> trigger their validation. We can fix that two ways:
>
>   - Define challenges as non-pollable: Poll authorizations instead,
> since they contain the challenges. This was something I'd proposed
> previously, in the spirit of "there should just be one way to do
> things." Right now, some clients poll authorizations and some poll
> challenges. There's no benefit to one way or the other, it's just a
> random implementer choice that sometimes exposes different code paths.
>
>   - Define multiple POSTs to challenges as idempotent. That is, the
> first time you POST a "{}" body to a challenge it triggers validation,
> and subsequently it acts as a GET.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Richard Barnes]

On Wed, Sep 5, 2018 at 12:53 PM Salz, Rich  wrote:

>
>- Because being generous in what you receive is harmful.
>
> https://tools.ietf.org/html/draft-iab-protocol-maintenance-00
> 
>
>
>
> Sorry, I disagree with King Martin in this case. :)
>
>
>
> I think mandating a specific requrest body is hard to get right.
>

Can you point to an implementation framework where this would be
difficult?  AFAIK, every JSON library out there marshalls {} as "{}", with
no whitespace, and every JOSE library signs whatever string you give it.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Richard Barnes]

Because being generous in what you receive is harmful.
https://tools.ietf.org/html/draft-iab-protocol-maintenance-00

In case anyone want to try to interop, I updated my lego patch to implement
(1):
https://github.com/bifurcation/lego/pull/1/commits/750383d7ad272a0894d6ff86d4d85d38f965c14f


On Wed, Sep 5, 2018 at 12:44 PM Salz, Rich  wrote:

> I like the header, but rather than say the payload MUST be {} (which
> brings up all sorts of whitespace issues at least), maybe we should say the
> server MUST ignore the request body?
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Richard Barnes]

I'm tempted to say that the "" / null ambiguity is an interop problem for
JOSE, not for us.  But nonetheless, it's a problem.

I'm still uncomfortable with {}, though, because it risks colliding with
other POST uses.  What would you guys think about one of these explicit
markers:

1. A field in the protected header ("urn:ietf:params:acme:get": true) with
a requirement that the payload be "{}"
2. A field in the payload ({"get": true}) a requirement that if that field
be there, then there are no other fields present

Personally, I find (1) a little more explicit.  It's a little more bloat
because of the URN cruft, but (1) it doesn't make sense to register a
generic, unprefixed parameter, and (2) checking for "{}" is easier than
checking for "no other fields".

--Richard

On Tue, Sep 4, 2018 at 3:17 PM Logan Widick  wrote:

> I like using {} for the POST-as-GET payload as well.
>
> Sincerely,
>
> Logan Widick
>
> On Tue, Sep 4, 2018, 12:26 Jacob Hoffman-Andrews  wrote:
>
>> New day, new thread for a specific issue I'd like to nail down quickly.
>>
>> > ISSUE 2: How should we signal that POST-as-GET request is different
>> > from other POST requests?
>> >
>> > The current PR signals this by sending a JWS with an empty
>> > (zero-octet) payload, instead of a JSON object.  Jacob and Daniel
>> > suggested that we should instead use the payload being an empty JSON
>> > object as the signal.  An earlier draft PR used a field in the
>> > protected header.
>>
>> In short, this question is about whether POST-as-GETs should have:
>>
>> "payload": ""
>>
>> or
>>
>> "payload": "{}"
>>
>>
>> When implementing the first one (empty payload), Daniel and I each
>> separately implemented a different bug that would have also accepted:
>>
>> "payload": null
>>
>> This may be quirk of Go's handling of byte arrays, but it may turn out
>> to be a common pattern in JSON libraries. The downside, if a server
>> implementer landed a bug like that, would be that clients might get away
>> with generating the invalid "null" form, leading to interoperability
>> problems.
>>
>> There's also potential for client bugs that produce an empty payload
>> simply due to an uninitialized field, rather than due to a POST-as-GET.
>> This would produce confusing errors relating to GETs rather than a
>> clearer "malformed input" error.
>>
>> Lastly, many clients already implement the "{}" form as a way to GET an
>> account, so expanding the use of "{}" minimizes disruption.
>>
>> My preference is still for "{}" over "", but I am also willing to be
>> convinced in the interests of landing this change speedily and keeping
>> forward momentum.
>>
>> ___
>> 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] nomenclature: “POST-as-GET”

[Richard Barnes]

On Tue, Sep 4, 2018 at 1:44 PM Felipe Gasper 
wrote:

> FWIW, it seems to me like, if the HTTP verb being used is, in fact,
> “POST”, then a more appropriate term for the proposed fix for the identity
> correlation problem identified last week would be “GET-as-POST” rather than
> “POST-as-GET”.
>
> “POST-as-GET” sounds to me like the actual HTTP verb is a GET, but we’re
> shoehorning what would normally be a POST over that request. The opposite,
> of course, is what is proposed: a POST with an uninteresting payload is
> being sent to simulate a GET but with the authentication of a POST. The
> pattern of a GET is being sent “as a POST”.
>

I would be fine either way.  It really just depends on which implicit verb
you read with the "as" -- "POST-acting-as-GET" or "GET-sent-as-POST".  I
would prefer not to actually include the verb, just because that gets wordy..



> Alternatively, would it make sense to define a new HTTP verb, e.g.,
> “FETCH”, for this?
>

I'm inclined not to do this.  We definitely shouldn't actually mint a new
HTTP method, since we're not changing the method.  As a corollary, we
shouldn't write it in all caps (so "Fetch" or "fEtcH" or something).  Also,
while "fetch" is the obvious verb, it collides with the HTML5 JS API of
that name, which supports all methods.

--Richard



>
> -FG
> ___
> 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] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

Hey all,

This thread forked into a couple of different issues, so I wanted to post a
little end-of-day summary of the issues and where we stand.  I've updated
the PR [1] to reflect most of today's discussion.

===

ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the
privacy analysis?

It seems like there's pretty strong agreement that we should get rid of
GET, as the architecturally cleanest option.

===

ISSUE 2: How should we signal that POST-as-GET request is different from
other POST requests?

The current PR signals this by sending a JWS with an empty (zero-octet)
payload, instead of a JSON object.  Jacob and Daniel suggested that we
should instead use the payload being an empty JSON object as the signal.
An earlier draft PR used a field in the protected header.

===

ISSUE 3: Should servers be required to allow GET requests for certificate
URLs?

I had proposed this earlier today; Jacob and Daniel pushed back.  I have
implemented a compromise in the latest PR, where servers MAY accept GET
requests.

===

ISSUE 4: How should we address the risk that an attacker can discover URLs
by probing for Unauthorized vs. Not Found?

There seemed to be agreement on the list that this should be addressed with
some guidance to servers on how to assign URLs.  I have just added some
text to the PR for this.

===

It seems to me we're pretty much closed on the first issue, and the other
three are still open.  Please send comments, so we can resolve this issue
and get the document back in motion!

Thanks,
--Richard

[1] https://github.com/ietf-wg-acme/acme/pull/445

On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews  wrote:

> ACME currently has unauthenticated GETs for some resources. This was
> originally discussed in January 2015[1]. We decided to put all sensitive
> data in the account resource and consider all GET resources public, with
> a slant towards transparency.
>
> Adam Roach recently pointed out in his Area Director review that even
> when the contents of GET URLs aren’t sensitive, their correlation may
> be. For instance, some CAs might consider the grouping of certificates
> by account to be sensitive.
>
> Richard Barnes proposes[2] to change all GETs to POSTs (except directory
> and new-nonce). This will be a breaking change. Clients that were
> compatible with previous drafts, informally called ACMEv1 and ACMEv2,
> will not be compatible with a draft that mandates POSTs everywhere. It
> will be a painful change, since the ecosystem just started switching to
> ACMEv2, which looked to be near-final.
>
> I think this is the right path forwards. ACME will be a simpler, better
> protocol long-term if all requests are authenticated. However, if we’re
> taking this path we should aim to come to consensus and land the final
> spec quickly to reduce uncertainty for ACME client implementers.
>
> [1] https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
> [2] https://github.com/ietf-wg-acme/acme/pull/445/files
>
> ___
> 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] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

On Fri, Aug 31, 2018 at 3:30 PM Jacob Hoffman-Andrews  wrote:

> On 08/31/2018 07:25 AM, Richard Barnes wrote:
> > The problem with using POST-as-GET for certificate resources, as
> > Felipe I think pointed out, is that the thing that downloads the
> > certificate URL is often not an ACME player, doesn't have an account,
> > etc.  It's a web server or something. (cf. the STAR drafts.)  What I'm
> > saying is that it's painful to make them integrate with ACME and we
> > don't get any benefit.
> AFAIK, no current ACME client hands off certificate URLs to
> less-privileged processes.
>
> Keeping GETs for certificates undermines the goal of making the
> POST-as-GET change. Certificate resources may be constructed in
> enumerable ways, like:
>
> /account/100/certificate/3438
> /account/201/certificate/3439
> /account/100/certificate/3440*
>
> While many CAs may not consider correlation of certificates by account
> to be sensitive, our goal with this change is to eliminate a footgun for
> CAs who do consider it sensitive, by simply ensuring all requests are
> authenticated by default. Consistent authentication also has the
> potential to simplify by client and server libraries.
>
> I think it would be a mistake to carve out this exception in the main
> ACME spec for use cases that are still speculative. Instead, if there is
> a use case that truly requires unauthenticated certificate retrieval, it
> should be defined as an extension or an optional feature.
>

I understand the desire for uniformity; I'm just concerned we're going
overboard here.

I could live with this being optional, but I would prefer to go ahead and
add it (because STAR needs it) and keep the negotiation minimal.  I would
propose that we just say the server MAY accept GETs for certificate URLs,
returning 405 if not.

That way a client with a GET-based use case would have to either find out
out of band that the server was compatible, or else fail when it tries.
But that seems like an acceptable outcome to me.  If we need an "I always
do cert+GET" signal, we can toss it in the "meta" dictionary later.

--Richard


>
> In short, I think certificates should be POST-as-GET just like the other
> resources.
>
> *Note: I'm aware that certificate serial numbers must be randomized, but
> there is no requirement that the certificate serial number be present in
> the URL.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

On Fri, Aug 31, 2018 at 3:30 PM Daniel McCarney  wrote:

> here's a PR[0] for the Pebble ACME server that implements Richard's
>> proposal[1] to establish viability. The proposal seems OK to me given
>> the trade-offs/alternatives on the table.
>
>
> One of the changes Richard made in his second iteration of PR #445 was to
> differentiate a POST from a POST-as-GET by sending an empty body "a
> zero-length octet string" in the POST JWS. Talking about the experience of
> implementing this more with Jacob Hoffman-Andrews I think I've come around
> to preferring an alternative design. #445 as described requires server and
> client developers pay careful attention to the differences between `null`
> and `""` in serialization/deserialization and might be bumping into
> differences between languages/JSON parsers. Both myself and Jacob failed to
> get it right on a first-go[0] and if people this close to the specification
> are going to trip on this I think we can be assured others will too.
>
> A proposed alternative: We use `{}` as the body for POST-as-GET (as
> suggested by Jacob[1]) and further specify that challenges can only be
> initiated with a POST and do not support POST-as-GET.
>
> Using `{}` as the body matches the long standing method of authenticating
> access to account information and avoids any null troubles. Removing
> polling of challenges is required to free up POSTing `{}` as the challenge
> initiation message. All of the challenge information is already accessible
> by POST-as-GET polling the associated authorization and it seems sensible
> to remove that redundancy as it can cause bugs when a client developer
> polls a challenge for an authorization not realizing the associated
> authorization has changed to status valid from a different challenge.
>
> Thoughts?
>

The confusion over `null` and `""` is actually part of the motivation for
using a zero-length body -- it's not JSON.   That's what makes it a good
signal.  If you're doing POST-as-POST, you have a JSON body and you have to
do JSON stuff.  If you're doing POST-as-GET, you're not and you don't.  It
guarantees clean separation between the two cases, minimizing risk of
confusion.

I think the cleaner answer here is to fix the "account fetch" case to use
POST-as-GET.

--Richard



>
> [0] https://github.com/letsencrypt/pebble/pull/162#discussion_r214446189
> [1] https://github.com/ietf-wg-acme/acme/pull/445#issuecomment-417505743
>
> On Fri, Aug 31, 2018 at 2:56 PM, Daniel McCarney 
> wrote:
>
>> I think its an anti-pattern to standardize protocol features that haven't
>> been implemented by anyone so here's a PR[0] for the Pebble ACME server
>> that implements Richard's proposal[1] to establish viability. The proposal 
>> seems
>> OK to me given the trade-offs/alternatives on the table.
>>
>> I would encourage other ACME client/server developers to try their hand
>> at implementing the changes from [1] as well. I've tested my PR with
>> hand-rolled requests but not as part of an automated issuance process with
>> a "real" ACME client. Speak now or forever hold your bugs.
>>
>> [0] - https://github.com/letsencrypt/pebble/pull/162
>> [1] - https://github.com/ietf-wg-acme/acme/pull/445/files
>>
>> On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes  wrote:
>>
>>> No, if a server receives a GET request for a resource other than those
>>> specified, then it MUST return 405.  But please check out the PR and see if
>>> it's clear there.
>>>
>>> On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich  wrote:
>>>
>>>>
>>>>- * Servers MUST return a 405 if they get a GET for a resource
>>>>other than directory/newNonce/certificate.
>>>>
>>>>
>>>>
>>>> They means client? Or there’s a word missing, and “they get a” is “they
>>>> do not support”
>>>>
>>>
>>> ___
>>> 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] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

I was able upgrade the lego client in a pretty short patch (5 files
changed, 26 insertions(+), 16 deletions(-)) [0].  It interoperates with
Daniel's branch of pebble.

--Richard

[1] https://github.com/bifurcation/lego/pull/1



On Fri, Aug 31, 2018 at 2:56 PM Daniel McCarney  wrote:

> I think its an anti-pattern to standardize protocol features that haven't
> been implemented by anyone so here's a PR[0] for the Pebble ACME server
> that implements Richard's proposal[1] to establish viability. The proposal 
> seems
> OK to me given the trade-offs/alternatives on the table.
>
> I would encourage other ACME client/server developers to try their hand at
> implementing the changes from [1] as well. I've tested my PR with
> hand-rolled requests but not as part of an automated issuance process with
> a "real" ACME client. Speak now or forever hold your bugs.
>
> [0] - https://github.com/letsencrypt/pebble/pull/162
> [1] - https://github.com/ietf-wg-acme/acme/pull/445/files
>
> On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes  wrote:
>
>> No, if a server receives a GET request for a resource other than those
>> specified, then it MUST return 405.  But please check out the PR and see if
>> it's clear there.
>>
>> On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich  wrote:
>>
>>>
>>>- * Servers MUST return a 405 if they get a GET for a resource other
>>>than directory/newNonce/certificate.
>>>
>>>
>>>
>>> They means client? Or there’s a word missing, and “they get a” is “they
>>> do not support”
>>>
>>
>> ___
>> 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] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

On Fri, Aug 31, 2018 at 4:15 PM Jacob Hoffman-Andrews  wrote:

> On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote:
> > /account/100/certificate/3438
> > /account/201/certificate/3439
> > /account/100/certificate/3440*
>
> Here's an issue that came up during code review: When you POST-as-GET to
> a resource you don't own, should you get Not Found or Unauthorized? The
> quick answer is Not Found. If we return Unauthorized, that still allows
> potentially enumerating the existence of certificates URLs, which
> depending on URL schemes might reveal the grouping of certificates by
> account id.
>
> However, if we choose Not Found, that implies we're trying to hide the
> existence of certain resources, which means checking for those resources
> has to be timing-safe, a very high bar. We wind up hiding one foot-gun
> (URL enumeration) under another foot-gun (timing attacks).
>
> Alternately, we could consider URL enumeration out of scope, and say
> "POST-as-GET is only intended to protect the contents of resources, not
> their existence or relationship to each other."
>
> That winds up leaving us pretty close to being back at draft-14: Since
> POST-as-GET protects resource bodies, and the currently-specified
> resources are already broken down into sensitive (account) and not
> (orders, authorizations, challenges, certificates), we could just as
> well leave the non-sensitive resources as regular GETs. We might make a
> change to define POST-as-GET as a broader mechanism, to be used by
> default by future extensions that define new resource types.
>
> Alternately, we might say that even though orders, authorizations,
> challenges, and certificates are all non-sensitive, we should require
> POST-as-GET across the board for all ACME requests, because it will
> simplify security analysis.
>
> What do you all think? Should enumeration of the existence of URLs be
> considered in-scope?
>

The correct answer here is Unauthorized.  The resource exists, and it's the
job of the authentication / authorization system to prevent unauthorized
parties from accessing it.

I disagree with your assessment that this puts us back at draft-14.  It
just moves us to the edge of the demarc: The guidance from the HTTP folks
says we're not allowed to specify URL plans for server operators, in order
to give them deployment flexibility.  The flip-side of that is that it is
up to operators to use a safe URL plan.  So we're doing our part in the
protocol; operators need to do their part.

I can add some guidance to the security considerations.

--Richard

On Fri, Aug 31, 2018 at 4:15 PM Jacob Hoffman-Andrews  wrote:

> On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote:
> > /account/100/certificate/3438
> > /account/201/certificate/3439
> > /account/100/certificate/3440*
>
> Here's an issue that came up during code review: When you POST-as-GET to
> a resource you don't own, should you get Not Found or Unauthorized? The
> quick answer is Not Found. If we return Unauthorized, that still allows
> potentially enumerating the existence of certificates URLs, which
> depending on URL schemes might reveal the grouping of certificates by
> account id.
>
> However, if we choose Not Found, that implies we're trying to hide the
> existence of certain resources, which means checking for those resources
> has to be timing-safe, a very high bar. We wind up hiding one foot-gun
> (URL enumeration) under another foot-gun (timing attacks).
>
> Alternately, we could consider URL enumeration out of scope, and say
> "POST-as-GET is only intended to protect the contents of resources, not
> their existence or relationship to each other."
>
> That winds up leaving us pretty close to being back at draft-14: Since
> POST-as-GET protects resource bodies, and the currently-specified
> resources are already broken down into sensitive (account) and not
> (orders, authorizations, challenges, certificates), we could just as
> well leave the non-sensitive resources as regular GETs. We might make a
> change to define POST-as-GET as a broader mechanism, to be used by
> default by future extensions that define new resource types.
>
> Alternately, we might say that even though orders, authorizations,
> challenges, and certificates are all non-sensitive, we should require
> POST-as-GET across the board for all ACME requests, because it will
> simplify security analysis.
>
> What do you all think? Should enumeration of the existence of URLs be
> considered in-scope?
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Richard Barnes]

STAR only requires that the server be able to GET the certificate URL,
right?  If that's the case, I don't see a problem, given that the latest
version of the PR allows GET to certificate resources.

I don't think we can make authentication optional.  That would revert us
back to having to do privacy analysis for everything.  Note, however, that
the *authorization* that the server applies is still up to the server.  If
the server wants to have some external interface by which you could
authorize additional people to see your stuff, they are not forbidden from
doing so.

--Richard

On Fri, Aug 31, 2018 at 2:28 PM Fossati, Thomas (Nokia - GB/Cambridge) <
thomas.foss...@nokia.com> wrote:

> +1
>
> As noted by Felipe, the implication that the service effectively
> consuming the certificate has to have the ACME account's key at hand is
> not always a practical nor a particularly secure arrangement.  (Another
> example where this wouldn't work out particularly well is a single ACME
> STAR certificate shared across multiple service instances in a HA
> configuration.)
> Broadly speaking, it looks like this is going to be problematic in all
> cases where you'd want to decouple the certificate requester from the
> certificate consumer roles.
>
> In particular, I'm very concerned about the impact on STAR Requests.
> In both its forms - as an ACME profile [1] as well as a standalone
> protocol [2] - the design postulates that the certificate resource is
> public.  This is a core precondition to allow delegation without sharing
> credentials between the delegating and the delegated entities.  The
> authenticated POST-as-GET access to the certificate resource completely
> wrecks this architecture.
>
> So, my question (just to be super clear: scoped only to the "POST-as-GET
> certificate" part of the proposed change) is: Can we let the ACME user
> decide whether to enable or disable this specific behaviour instead of
> making it mandatory for everyone?
>
> Cheers, thanks
>
> [1]
> https://github.com/thomas-fossati/I-D/blob/acme-delegation-profile/STAR-Request/draft-sheffer-acme-star-delegation.md
> [2]
> https://github.com/thomas-fossati/I-D/blob/acme-delegation-profile/STAR-Request/draft-sheffer-acme-star-request.md
> 
> From: Acme  on behalf of Felipe Gasper <
> fel...@felipegasper.com>
> Sent: 30 August 2018 20:17
> To: Salz, Rich
> Cc: acme@ietf.org
> Subject: Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with
> DISCUSS and COMMENT)
>
> Would it work to keep certificate fetches as plain GET?
>
> In shared hosting environments it’s common for a privileged process to
> request certificates on behalf of user accounts. This avoids having 1,000s
> of ACME server registrations from a single server. While certificates are
> generally made available within seconds, theoretically the delay between
> request and issuance could be much longer (e.g., for OV/EV), such that it
> might be prudent for that privileged process to give the order ID to the
> user and have the user poll for the certificate, e.g., via cron.
>
> -Felipe Gasper
> Mississauga, Ontario
>
>
> > On Aug 30, 2018, at 11:51 AM, Salz, Rich 
> > 
> wrote:
> >
> > It appears that we missed a security issue.
> >
> > Please take a look at the PR mentioned below.  It removes many GET
> requests and turns them into POST so that the client payload can have
> authentication information.
> >
> > If you object to this change, please post a note to the list and explain
> why.  Try to do that within a week.
> >
> > Thanks.
> >
> > From: Richard Barnes 
> > Date: Thursday, August 30, 2018 at 11:42 AM
> > To: Adam Roach 
> > Cc: "felix=40fontein...@dmarc.ietf.org"  40fontein...@dmarc.ietf.org>, "acme@ietf.org" 
> > Subject: Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14:
> (with DISCUSS and COMMENT)
> >
> > My preference here would be for approach (1).  I appreciate that it's a
> big change to make this late in the process, but that's the price we pay
> for missing a pretty significant issue up until now.  For existing
> implementations, the code impact should be modest, as long as they have
> been architected to isolate fetch logic (i.e., the have a get() method that
> you could just change to do the right POST thing).  And as long as we don't
> *forbid* responding to GET requests, servers can support both options for
> the time being.
> >
> > To illustrate what change we'd need to make, I went ahead and wrote up a
> PR:
> >
> > https://github.com/ietf-wg-acme/acme/pull/445
> >
> > __

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Richard Barnes]

On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk  wrote:

> On Fri, Aug 31, 2018 at 12:32:08PM -0400, Richard Barnes wrote:
> > I've started a PR for your DISCUSS comments here:
> >
> > https://github.com/ietf-wg-acme/acme/pull/447
> >
> > Right now, there are the following major edits there:
> >
> > - Added some text to the Security Considerations that clarifies that the
> > only protection we provide against an ACME MitM is that we prevent it
> from
> > getting improper authorization.  We don't prevent it from doing downgrade
> > attacks or DoS.
> >
> > - Added an explicit statement that there are no restrictions on the use
> of
> > 0-RTT
> >
> > - Clarified what contents are expected in the "challenges" array
> >
> > Some more comments inline below.  Comments addressed by PR / overcome by
> > events trimmed.
> >
> >
> > On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk  wrote:
> >
> > > > > Section 7.1.1 discusses how the server can include a caaIdentities
> > > element
> > > > > in its directory metadata; does this (or anything else) need to be
> > > > > integrity protected by anything stronger than the Web PKI cert
> > > > > authenticating the HTTPS connection?  It seems that a bogus
> > > caaIdentities
> > > > > value could lead to an unfortunate DoS in some cases.
> > > > >
> > > >
> > > > I don't know what you would consider stronger than a WebPKI cert.
> You
> > > > could use a secondary key that isn't provided to the CDN and do JWS
> in
> > > the
> > > > server-to-client direction.  But that would require clients to
> configure
> > > a
> > > > public key as well as a URL, and you would have to figure out
> whether you
> > > > wanted caching or anti-replay and build the corresponding addenda to
> JWS.
> > > > All in all, a lot of complexity for marginal benefit, especially this
> > > late
> > > > in the game.
> > >
> > > Yeah, it's clearly a lot of complexity for marginal benefit (since the
> DoS
> > > would likely be easy to notice and recover from) and late in the game.
> > > Though the CA does already have a key that the client trusts...
> > >
> >
> > I guess it's true that the CA could present a key certified by its
> trusted
> > root, say in the directory object.  But that just turns the complexity
> knob
> > even higher :)
>
> Yup.  And having the trusted root directly sign a statement of CAA
> identifiers is probably right out for many reasons, including X.509
> constraints and it being a bad idea operationally to pull out your offline
> key to do something this mundane.
>
> >
> >
> > > Do you want to mention that the caaIdentities element gives a leaf cert
> > > some control over the trust anchors that are used, in the security
> > > considerations?  (This is a serious question; I am leaning towards it
> being
> > > worth doing, but it would not be very hard to convince me otherwise.)
> > >
> >
> > I'm not sure what you mean by "caaIdentities element gives a leaf cert
> some
> > control over the trust anchors that are used".  Who is controlling whose
> > use of trust anchors, and how?
>
> The scenario I had in mind, which may be completely bogus, was that you
> have a CDN/whatever in front of the ACME server; that CDN's EE cert could
> in principle be signed by a different CA hierarchy than the ACME server is
> doing issuance for.  So you have a TLS cert from CA XYZ that is the
> authentication on a statement "use CAA value  for CA ABC".  If the
> ACME
> client and its friends then go off and installs  as their CAA record
> with a large TTL, when the client goes to ask for a cert, ABC goes and
> checks the CAA record and says "nothing doing".  If ABC caches for the full
> TTL, the client might have to find a different CA (perhaps one that does
> not use an actively harmful CDN to front its operations, heh).  This seems
> to only differ from the case of a CDN just dropping traffic on the floor or
> the other DoS vectors available to it, by virtue of the long TTL on the CAA
> record -- even after ABC decides that this CDN is evil and switches, that
> bogus CAA record is still valid.  Maybe it's better to say that the CDN's
> EE cert is controlling which trust anchor is *not* used [for issuing
> certificates for the client's domain] than to say it controls which trust
> anchor is used.
>

I agree that the TTL is the only issue her

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

No, if a server receives a GET request for a resource other than those
specified, then it MUST return 405.  But please check out the PR and see if
it's clear there.

On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich  wrote:

>
>- * Servers MUST return a 405 if they get a GET for a resource other
>than directory/newNonce/certificate.
>
>
>
> They means client? Or there’s a word missing, and “they get a” is “they do
> not support”
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Richard Barnes]

Responses to COMMENT comments inline below (DISCUSS part trimmed).  PR here:

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

On Thu, Aug 30, 2018 at 12:50 AM Adam Roach  wrote:

>
> --
> COMMENT:
> --
>
> I have a small handful of substantive comments, and several editorial nits.
>
> ---
>
> General:
>
> This protocol specifies the use of RFC 3339 time formats in several
> places. Most
> modern protocols that reference RFC 3339 choose to place further
> restrictions on
> the format; commonly, the time-secfrac portion is required to be omitted,
> and
> the time-offset portion is required to be "Z". In addition to making
> parsing
> easier, these restrictions have the property of any given time having only
> one
> possible string representation.
>
> My suggestion would be for ACME to include similar restrictions.
> Alternately, if
> the full range of optionality allowed by RFC 3339 is actually intended,
> please
> adjust the examples so that at least a few of them include fractional
> seconds
> and non-UTC timezones.
>

Unless you can point me to an easy-to-specify,
univserally-supported-for-generation-and-consumption spec, I'm just going
to leave this as it is.



> ---
>
> §5:
>
> For avoidance of doubt, this section should probably indicate that values
> that
> will appear in certificates will be used and conveyed in the form present
> in
> certificates, possibly with a reference to RFC 5280 section 7.
>

Done, but in the section 7.1.4 where we define the "dns" identifier type.



> ---
>
> §6.4.1:
>
> >  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.
>
> It's not clear whether the values need to also be unpredictable; e.g.,
> would it
> be okay if the value of the nonce for operation n+1 could be easily
> derived or
> guessed from the nonce for operation n?
>

Done.



> ---
>
> §7.4.2:
>
> >  GET /acme/cert/asdf HTTP/1.1
> >  Host: example.com
> >  Accept: application/pkix-cert
> >
> >  HTTP/1.1 200 OK
> >  Content-Type: application/pem-certificate-chain
>
> This pairing of "Accept: application/pkix-cert" with "Content-Type:
> application/pem-certificate-chain" seems to be at odds with the
> description in
> RFC 7231 §5.3.2. I know that proactive negotiation is optional in HTTP,
> but it
> seems that it would be much better to show this as something like:
>
>GET /acme/cert/asdf HTTP/1.1
>Host: example.com
>Accept: application/pkix-cert, application/pem-certificate-chain;q=0..5
>

This was noted in Alexey's review, and is fixed in the corresponding PR:

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



> ===
>
> All of my remaining comments are editorial in nature, and most of those are
> minor editorial nits.
>

Using my editorial discretion, I've just marked these as "Done" or
"Disagree".


i-d nits reports:
>
>   ** There are 3 instances of too long lines in the document, the longest
> one
>  being 15 characters in excess of 72.
>
> I'm not sure it's reasonable to expect the RFC editor to have enough
> knowledge
> to know how to best split the key authorization across lines (or to elide
> portions of it, whichever makes more sense).
>

Done.



> ---
>
> i-d nits also reports:
>
>   -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is
> not
>  defined in RFC 2119.  If it is intended as a requirements expression,
> it
>  should be rewritten using one of the combinations defined in RFC 2119;
>  otherwise it should not be all-uppercase.
>

This was noted in another IESG review (I think Ben's), and fixed in the
corresponding PR.



> ---
>
> §1:
>
> >  Existing Web PKI certificate authorities tend to use a set of ad hoc
> >  protocols for certificate issuance and identity verification.  In the
> >  case of DV certificates, a typical user experience is something like:
>
> I expect this text won't age gracefully. Even at the time of publication of
> this document, over 64% of all certificates issued on the web have been
> issued
> using the ACME protocol, arguably making it the "typical user experience."
> (see
>
> https://censys.io/certificates/report?q=tags%3Atrusted=parsed.issuer.organization.raw_buckets=50
> )
>
> I suggest caveating this paragraph with text 

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Richard Barnes]

I've started a PR for your DISCUSS comments here:

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

Right now, there are the following major edits there:

- Added some text to the Security Considerations that clarifies that the
only protection we provide against an ACME MitM is that we prevent it from
getting improper authorization.  We don't prevent it from doing downgrade
attacks or DoS.

- Added an explicit statement that there are no restrictions on the use of
0-RTT

- Clarified what contents are expected in the "challenges" array

Some more comments inline below.  Comments addressed by PR / overcome by
events trimmed.


On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk  wrote:

> > > Section 7.1.1 discusses how the server can include a caaIdentities
> element
> > > in its directory metadata; does this (or anything else) need to be
> > > integrity protected by anything stronger than the Web PKI cert
> > > authenticating the HTTPS connection?  It seems that a bogus
> caaIdentities
> > > value could lead to an unfortunate DoS in some cases.
> > >
> >
> > I don't know what you would consider stronger than a WebPKI cert.  You
> > could use a secondary key that isn't provided to the CDN and do JWS in
> the
> > server-to-client direction.  But that would require clients to configure
> a
> > public key as well as a URL, and you would have to figure out whether you
> > wanted caching or anti-replay and build the corresponding addenda to JWS.
> > All in all, a lot of complexity for marginal benefit, especially this
> late
> > in the game.
>
> Yeah, it's clearly a lot of complexity for marginal benefit (since the DoS
> would likely be easy to notice and recover from) and late in the game.
> Though the CA does already have a key that the client trusts...
>

I guess it's true that the CA could present a key certified by its trusted
root, say in the directory object.  But that just turns the complexity knob
even higher :)



> Do you want to mention that the caaIdentities element gives a leaf cert
> some control over the trust anchors that are used, in the security
> considerations?  (This is a serious question; I am leaning towards it being
> worth doing, but it would not be very hard to convince me otherwise.)
>

I'm not sure what you mean by "caaIdentities element gives a leaf cert some
control over the trust anchors that are used".  Who is controlling whose
use of trust anchors, and how?





On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk  wrote:

> On Wed, Aug 29, 2018 at 09:10:06PM -0400, Richard Barnes wrote:
> > Hi Ben,
> >
> > Thanks for the detailed review.  Responses to the DISCUSS comments
> inline.
> > My co-author Daniel McCarney is working on the COMMENT comments.
> >
> > --Richard
> >
> > On Wed, Aug 29, 2018 at 2:53 PM Benjamin Kaduk  wrote:
> >
> > >
> > > It looks like the server returns an unauthenticated
> "badSignatureAlgorithm"
> > > error when the client sends a JWS using an unsupported signature
> algorithm
> > > (Section 6.2).  What prevents an active attacker from performing a
> > > downgrade attack on the signature algorithm used?
> > >
> >
> > HTTPS, and the minimum requirements established in this document.  We can
> > add some comments to the Security Considerations if you want.
>
> It's probably worth some security considerations text.
> (BTW, I was more picky than usual for this doc, since apparently TLS MitM
> capabilities are explicitly in the threat model via the
> "CDN-in-front-of-ACME-server" case.  So in some sense that is implying that
> the web PKI is not quite good enough for that channel.)
>
> >
> >
> > > Similarly, since we include in the threat model a potentially hostile
> > > CDN/MitM between the ACME client and ACME server, can that attacker
> strip a
> > > success response and replace it with a badNonce error, causing the
> client
> > > to retry (and thus duplicate the request processing on the server)?
> > >
> >
> > In the spectrum of DoS attacks the CDN could wage against the server,
> this
> > seems pretty lame.  The CDN could also just stop forwarding requests.
> >
> > In other words, I don't really think the
>
> (incomplete sentence)
> But yes, I was thinking about this some more after I balloted and it did
> end up seeming likely innocuous by comparison.  It's still good to have
> people more familiar with the document than me think about the
> possibilities, though -- it seems like most things the client would be
> trying to do are relatively idempotent (that is, new challenge tokens and
> such co

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

I have updated the pull request here with a couple of major changes:

* Instead of using the "typ" header parameter to signal POST-as-GET, the
client signals a POST-as-GET request by sending an empty JWS payload.  It
seems like all of the actual-POST requests we have send a JSON object, so
this should be a reliable distinguisher.

* GET requests are now allowed for certificate resources, with a
recommendation for CAs to use capability URLs if they want access control.

* Servers MUST return a 405 if they get a GET for a resource other than
directory/newNonce/certificate.

The last change makes this a harder break for current clients/servers.  But
it's only breaking in the sense that they're not in compliance with the
RFC; you can operate a non-RFC-compliant service, no protocol police.  And
I think it results in a cleaner, more reliable definition here.

--Richard


On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews  wrote:

> ACME currently has unauthenticated GETs for some resources. This was
> originally discussed in January 2015[1]. We decided to put all sensitive
> data in the account resource and consider all GET resources public, with
> a slant towards transparency.
>
> Adam Roach recently pointed out in his Area Director review that even
> when the contents of GET URLs aren’t sensitive, their correlation may
> be. For instance, some CAs might consider the grouping of certificates
> by account to be sensitive.
>
> Richard Barnes proposes[2] to change all GETs to POSTs (except directory
> and new-nonce). This will be a breaking change. Clients that were
> compatible with previous drafts, informally called ACMEv1 and ACMEv2,
> will not be compatible with a draft that mandates POSTs everywhere. It
> will be a painful change, since the ecosystem just started switching to
> ACMEv2, which looked to be near-final.
>
> I think this is the right path forwards. ACME will be a simpler, better
> protocol long-term if all requests are authenticated. However, if we’re
> taking this path we should aim to come to consensus and land the final
> spec quickly to reduce uncertainty for ACME client implementers.
>
> [1] https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
> [2] https://github.com/ietf-wg-acme/acme/pull/445/files
>
> ___
> 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] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

The problem with using POST-as-GET for certificate resources, as Felipe I
think pointed out, is that the thing that downloads the certificate URL is
often not an ACME player, doesn't have an account, etc.  It's a web server
or something.  (cf. the STAR drafts.)  What I'm saying is that it's painful
to make them integrate with ACME and we don't get any benefit.

On Fri, Aug 31, 2018 at 10:20 AM Salz, Rich  wrote:

>
>- - If a server is concerned about the privacy of certificate
>resources, then they SHOULD assign them capability URLs.
>
>
>
> Not a fan of capability URL’s; does get/post handle things well enough?
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

To be clear, I'm proposing that the server MUST allow GET for a certificate
resource (as well as POST-as-GET).  It can protect those GETs with
capability URLs if it wants to.

On Fri, Aug 31, 2018 at 10:21 AM Felipe Gasper 
wrote:

> I wonder, then, if it’s worth making it discoverable whether the server
> allows a plain GET for a certificate … other than, of course, getting a 405
> back when the client tries to request a certificate via GET.
>
> -F
>
> > On Aug 31, 2018, at 10:16 AM, Richard Barnes  wrote:
> >
> > TBH, I'm not averse to allowing GETs for certificate resources.  It
> seems analogous to allowing them for the directory resource, just on the
> opposite side of the process.  That is, the directory and certificate
> resources are the interfaces between ACME and the outside world, so it
> makes sense not to force the outside world into the ACME authentication
> model.  In the same vein, capability URLs could be sensible here as an
> optional protection, since they're an authn model that's easy for the
> outside world to use.
> >
> > In addition, the content of certificate resources is tightly
> constrained, so we don't have the problem that we have with the JSON
> resources, that a server might add some information that violates privacy
> expectations.
> >
> > So I would propose that we say:
> >
> > - GETs are allowed for directory, newNonce, and certificate resources
> > - Servers MUST still respond to POST-as-GET requests for certificates,
> to simplify client logic
> > - If a server is concerned about the privacy of certificate resources,
> then they SHOULD assign them capability URLs.
> >
> > I'll be updating the PR to reflect some comments in Github a little
> later today, and will incorporate the above unless people think it's awful.
> >
> > --Richard
> >
> > On Thu, Aug 30, 2018 at 8:46 PM Felipe Gasper 
> wrote:
> >
> >
> > > On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews 
> wrote:
> > >
> > > (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's
> Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)")
> > >
> > > On 08/30/2018 11:17 AM, Felipe Gasper wrote:
> > > > Would it work to keep certificate fetches as plain GET?
> > > >
> > > > In shared hosting environments it’s common for a privileged process
> to request certificates on behalf of user accounts. This avoids having
> 1,000s of ACME server registrations from a single server. While
> certificates are generally made available within seconds, theoretically the
> delay between request and issuance could be much longer (e.g., for OV/EV),
> such that it might be prudent for that privileged process to give the order
> ID to the user and have the user poll for the certificate, e.g., via cron..
> > >
> > > This use case makes sense, but I think it is not critical enough to
> carve out an exception from the "GETs become POSTs" plan. If the ACME
> implementation structures certificate fetches such that they are
> enumerable, you would wind up again with the same sort of correlation
> problem Adam brought up. You could make the certificate URLs unpredictable,
> but then you've introduced a notion of capability URLs[1], which breaks the
> notion of having a single authentication system for ACME.
> >
> > I suppose if I have:
> >
> > GET /order/123/certificate=>   cert for yin.com
> >
> > GET /order/124/certificate=>   cert for yang.com
> >
> > … then one could surmise (however justifiably) that these two may be
> related, so I see the point.
> >
> > > You could make the certificate URLs unpredictable, but then you've
> introduced a notion of capability URLs[1], which breaks the notion of
> having a single authentication system for ACME.
> >
> > I can see that.
> >
> >
> > Thanks for your consideration!
> >
> > -FG
> > ___
> > 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] ACME breaking change: Most GETs become POSTs

[Richard Barnes]

TBH, I'm not averse to allowing GETs for certificate resources.  It seems
analogous to allowing them for the directory resource, just on the opposite
side of the process.  That is, the directory and certificate resources are
the interfaces between ACME and the outside world, so it makes sense not to
force the outside world into the ACME authentication model.  In the same
vein, capability URLs could be sensible here as an optional protection,
since they're an authn model that's easy for the outside world to use.

In addition, the content of certificate resources is tightly constrained,
so we don't have the problem that we have with the JSON resources, that a
server might add some information that violates privacy expectations.

So I would propose that we say:

- GETs are allowed for directory, newNonce, and certificate resources
- Servers MUST still respond to POST-as-GET requests for certificates, to
simplify client logic
- If a server is concerned about the privacy of certificate resources, then
they SHOULD assign them capability URLs.

I'll be updating the PR to reflect some comments in Github a little later
today, and will incorporate the above unless people think it's awful.

--Richard

On Thu, Aug 30, 2018 at 8:46 PM Felipe Gasper 
wrote:

>
>
> > On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews  wrote:
> >
> > (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's
> Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)")
> >
> > On 08/30/2018 11:17 AM, Felipe Gasper wrote:
> > > Would it work to keep certificate fetches as plain GET?
> > >
> > > In shared hosting environments it’s common for a privileged process to
> request certificates on behalf of user accounts. This avoids having 1,000s
> of ACME server registrations from a single server. While certificates are
> generally made available within seconds, theoretically the delay between
> request and issuance could be much longer (e.g., for OV/EV), such that it
> might be prudent for that privileged process to give the order ID to the
> user and have the user poll for the certificate, e.g., via cron.
> >
> > This use case makes sense, but I think it is not critical enough to
> carve out an exception from the "GETs become POSTs" plan. If the ACME
> implementation structures certificate fetches such that they are
> enumerable, you would wind up again with the same sort of correlation
> problem Adam brought up. You could make the certificate URLs unpredictable,
> but then you've introduced a notion of capability URLs[1], which breaks the
> notion of having a single authentication system for ACME.
>
> I suppose if I have:
>
> GET /order/123/certificate=>   cert for yin.com
>
> GET /order/124/certificate=>   cert for yang.com
>
> … then one could surmise (however justifiably) that these two may be
> related, so I see the point.
>
> > You could make the certificate URLs unpredictable, but then you've
> introduced a notion of capability URLs[1], which breaks the notion of
> having a single authentication system for ACME.
>
> I can see that.
>
>
> Thanks for your consideration!
>
> -FG
> ___
> 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] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Richard Barnes]

My preference here would be for approach (1).  I appreciate that it's a big
change to make this late in the process, but that's the price we pay for
missing a pretty significant issue up until now.  For existing
implementations, the code impact should be modest, as long as they have
been architected to isolate fetch logic (i.e., the have a get() method that
you could just change to do the right POST thing).  And as long as we don't
*forbid* responding to GET requests, servers can support both options for
the time being.

To illustrate what change we'd need to make, I went ahead and wrote up a PR:

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

On Thu, Aug 30, 2018 at 11:33 AM Adam Roach  wrote:

> On 8/30/18 8:48 AM, Felix Fontein wrote:
>
> Hello,
>
>
> On 8/30/18 7:55 AM, Richard Barnes wrote:
>
> Focusing on DISCUSS comment for now, will pick up COMMENTs later.
>
> On your DISCUSS, I think you're off on a couple of small things
>
>
>
> Yeah, I woke up with the sudden realization that I'd had the wrong
> model in my head when I talked through the cert endpoint. All that's
> there is a signed public cert rather than a public/private pair, so
> it's not sensitive.
>
>
> what happens if the cert URL is 
> nothttps://example.com/acme/cert/somerandomlookingidentifier, 
> buthttps://example.com/acme/acct/2/order/1/cert? Then someone can still do
> identification correlation when the certificate can be downloaded
> without authentication.
>
>
> That's a good point as well.
>
> After some further discussion, I think there are two potential paths
> forward:
>
>1. Remove all uses of GET from the specification (except for
>retrieving the directory), which causes all requests to be authenticated, 
> or
>2. Scrub all of the ACME documents to ensure that the resources that
>can be retrieved without authentication cannot be correlated with each
>other.
>
> Approach 1 (which is a stronger form of what Richard proposed in his PR)
> has the advantage of closing all privacy holes, even the ones that we can't
> identify at the moment. It has the disadvantage of differing from current
> deployed implementations.
>
> Approach 2 has the advantage of being consistent with today's deployments,
> but has the drawback that it it requires significant new work to identify
> and address means of correlating resources with each other. It's worth
> noting that the extensibility of the protocol makes it necessary to perform
> this analysis every time a new field is added to a structure and every time
> a new HTTP endpoint type is defined, which makes this approach extremely
> fragile. In particular, the fact that individual implementations can
> include arbitrary JSON fields for debugging and/or proprietary behavior
> means that we're going to require implementations to independently perform
> this analysis for every nonstandard field they add to the structure as well.
>
> /a
> ___
> 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] 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] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Richard Barnes]

Focusing on DISCUSS comment for now, will pick up COMMENTs later.

On your DISCUSS, I think you're off on a couple of small things, but right
on the underlying point that the document doesn't really provide any
guidance as to which resources a server should consider sensitive.  I agree
that it would be good to say more, and I've started up a PR for this.

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

I don't agree that sensitivity entails a need for non-guessable URLs.  If
accessing the URL requires authentication, then it doesn't matter if
someone can guess it; unauthorized people can't access it even if they can
guess it.  I guess you could argue that if you made a random URL and only
distributed it in authenticated channels, then you could allow GETs to it,
using the URL itself as an authenticator.  But that seems super brittle; I
would rather just have all the authentication be based on signing.  So at
best, random URLs are a backstop against a CA making the wrong decision
about GETs.

You're also correct to note that some resources might be sensitive that we
now instruct clients to poll with GETs.  For example, the client is
supposed to poll an authorization resource to see when it validates, but if
the authz has a TN in it and so is considered sensitive, you won't be able
to do a GET.  I think the right answer here is to have the server return
405 Method Not Allowed if it gets a GET and have the client fall back to an
authenticated "POST {}", which should be equivalent to a GET in all cases.

--Richard


On Thu, Aug 30, 2018 at 12:50 AM Adam Roach  wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-acme-acme-14: Discuss
>
> 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/
>
>
>
> --
> DISCUSS:
> --
>
> Thanks for all the work that everyone has put into this protocol. I'm
> excited by
> what it's been able to do for the certificate issuance sector as a whole,
> and
> truly appreciate all of the early implementors who have put both clients
> and
> servers into active production. I'm definitely balloting YES once we get
> clarity
> on my DISCUSS, below.
>
> ---
>
> I've looked at this several different ways, and I must be missing something
> obvious -- which should make this easy to clear.
>
> §6.2:
>
> >  Note that authentication via signed JWS request bodies implies that
> >  GET requests are not authenticated.  Servers MUST NOT respond to GET
> >  requests for resources that might be considered sensitive.  Account
> >  resources are the only sensitive resources defined in this
> >  specification.
>
> This doesn't seem correct.
>
> For example, let's imagine that I, as a user, get the directory for an ACME
> server, the body of which is the example in §7.1.1. Then, I go through the
> new-account process, and receive the Account object in §7.1.2:
>
>{
>  "status": "valid",
>  "contact": [
>"mailto:cert-ad...@example.com;,
>"mailto:ad...@example.com;
>  ],
>  "termsOfServiceAgreed": true,
>  "orders": "https://example.com/acme/acct/1/orders;
>}
>
> Huh. Suddenly, I'm not so interested in *my* orders, because I've noticed
> that
> different users' orders are apparently at a predictable URL that varies
> only by
> a small integer. Curious, I change the "1" to a "2" and send:
>
>   GET /acme/acct/2/orders HTTP/1.1
>   Host: example.com
>
> And get back not *my* orders, but someone *else's* orders.
>
>HTTP/1.1 200 OK
>Content-Type: application/json
>
>{
>  "orders": [
>"https://example.com/acme/acct/2/order/1;,
>"https://example.com/acme/acct/2/order/2;,
>"https://example.com/acme/acct/2/order/3;,
>"https://example.com/acme/acct/2/order/4;
>  ]
>}
>
> Interesting. So now I can do four more unauthenticated GETs and grab those
> order
> objects.
>
>HTTP/1.1 200 OK
>Content-Type: application/json
>
>{
>  "status": "valid",
>  ...
>  "identifiers": [
>{ "type": "dns", "value": "smithforcongress.example" }
>  ],
>  ...
>  "certificate": "https://example.com/acme/cert/1234;
>}
> --
>HTTP/1.1 200 OK
>Content-Type: application/json
>
>{
>  "status": "valid",
>  ...
>  "identifiers": [
>{ "type": "dns", "value":
> "something-embarassing-with-goats.example" }
>  ],
>  ...
>  

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] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Richard Barnes]

Hi Ben,

Thanks for the detailed review.  Responses to the DISCUSS comments inline.
My co-author Daniel McCarney is working on the COMMENT comments.

--Richard

On Wed, Aug 29, 2018 at 2:53 PM Benjamin Kaduk  wrote:

>
> It looks like the server returns an unauthenticated "badSignatureAlgorithm"
> error when the client sends a JWS using an unsupported signature algorithm
> (Section 6.2).  What prevents an active attacker from performing a
> downgrade attack on the signature algorithm used?
>

HTTPS, and the minimum requirements established in this document.  We can
add some comments to the Security Considerations if you want.



> Similarly, since we include in the threat model a potentially hostile
> CDN/MitM between the ACME client and ACME server, can that attacker strip a
> success response and replace it with a badNonce error, causing the client
> to retry (and thus duplicate the request processing on the server)?
>

In the spectrum of DoS attacks the CDN could wage against the server, this
seems pretty lame.  The CDN could also just stop forwarding requests.

In other words, I don't really think the


> I am not an ART AD, but there is not yet an internationalization
> directorate, and seeing statements like "inputs for digest computations
> MUST be encoded using the UTF-8 character set" (Section 5) without
> additional discussion of normalization and/or what the canonical form for
> the digest input is makes me nervous.  Has sufficient internationalization
> review been performed to ensure that there are no latent issues in this
> space?
>

Two of the three ART ADs have already signed off, so we have that going for
us :)

The only place we have human-readable text is in the problem documents, so
at that level, the i18n considerations are handled by that spec.  Other
than that, everything is ASCII, so saying "UTF-8" is just a fancy way of
saying, "don't send extra zero bytes".



> Section 6.1 has text discussing TLS 1.3's 0-RTT mode.  If this text is
> intended to be a profile that defines/allows the use of TLS 1.3 0-RTT data
> for the ACME protocol, I think you need to be more specific and say
> something like "MAY allow clients to send early data (0-RTT); there are no
> ACME-specific restrictions on which types of requests are permitted in
> 0-RTT", since the runtime configuration is just 0-RTT yes/no, and the
> protocol spec is in charge of saying which PDUs are allowed or not.
>

The risk for HTTPS with 0-RTT is replay of requests.  The text already
notes that that is not an issue for ACME requests because they have their
own anti-replay protection.  There are no restrictions on which PDUs are
allowed.   What further specificity do you need?



> Section 6.2 notes that servers MUST NOT respond to GET requests for
> sensitvie resources.  Why are account resources the only sensitive ones?
> Are authorizations not sensitive?  Or are those considered to fall under
> the umbrella of "account resources" (Section 7.1 seems pretty clear that
> they do not)?
>

That sentence has an overly prescriptive tone.  Obviously it's up to the
CA's policy what it considers sensitive.  (Some especially profligate CA
that's not subject to GDPR might be OK publishing its account objects.)
Happy to dial it back to something like "For example, most CAs will likely
consider account resources to be sensitive."



> Section 7.1.1 discusses how the server can include a caaIdentities element
> in its directory metadata; does this (or anything else) need to be
> integrity protected by anything stronger than the Web PKI cert
> authenticating the HTTPS connection?  It seems that a bogus caaIdentities
> value could lead to an unfortunate DoS in some cases.
>

I don't know what you would consider stronger than a WebPKI cert.  You
could use a secondary key that isn't provided to the CDN and do JWS in the
server-to-client direction.  But that would require clients to configure a
public key as well as a URL, and you would have to figure out whether you
wanted caching or anti-replay and build the corresponding addenda to JWS.
All in all, a lot of complexity for marginal benefit, especially this late
in the game.



> I am also a bit uncertain if the document is internally consistent about
> whether one challenge verification suffices or there can be cases when
> multiple challenge verifications are required for a successful
> authorization.  I attmpted to note relevant snippets of the text in my
> comments on Section 7.1.4.
>

The document is clear that (1) any one challenge is sufficient for a given
authorization ("the server should consider any one of the challenges
sufficient to make the authorization valid") and (2) the server may provide
multiple authorizations in the order object if it requires multiple
different validations.
___
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)

[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 

Re: [Acme] Ben Campbell's Yes on draft-ietf-acme-acme-14: (with COMMENT)

[Richard Barnes]

Hi Ben,

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

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

--Richard

On Tue, Aug 28, 2018 at 10:46 PM Ben Campbell  wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-acme-acme-14: Yes
>
> 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:
> --
>
> Thanks for the work on this; I'm happy to see it nearing completion. I
> have a
> few minor comments:
>
> *** Substantive ***
>
> §6.1: "The ACME server acts
>as an HTTP and HTTPS client when validating challenges via HTTP."
>
> Section 8.3 says that HTTP challenge validation cannot use HTTPS. Also, §6
> says
> that all interactions between the client and server use HTTPS. I recognize
> challenge validation is not really an interaction between the client and
> server, but I suspect some readers may be confused.
>

Done.


> - "ACME servers SHOULD follow the recommendations of [RFC7525] when
>configuring their TLS implementations."
> Why not MUST?
>

I believe the WG discussed this and decided that there was not a need to be
overly prescriptive here.



> §7.3: "... and the server MUST reject new-account
>requests that do not have the "termsOfServiceAgreed" field set to
>"true". "
>
> The MUST seems overly strong there; is there no room for local policy?
> Would it
> be completely insane to offer optional ToS? (For example, maybe one gets
> some
> additional service for agreeing to terms, but still gets a cert either
> way.)
>

Edited to "If the server wishes to require the client to agree to
terms...".



> - "Clients SHOULD NOT automatically agree to terms by default."
> Why not MUST NOT?
>

Same as the SHOULD NOT for warning the user below -- this is a UX / legal
issue.



> §8.3:
>
> - Is there a lifetime after which a provisioned HTTP resource in response
> to a
> challenge should go away?
>

Good question.  There has been discussion of "continuous validation", where
the CA would re-do validation over the life of a certificate, but I don't
think that's ever done in practice right now.  And if someone wants to do
that, they can define a new challenge "http-continuous-01".

I've noted that you can remove the resource once validation is complete.
And the same for the DNS challenge, actually.



> *** Editorial and Nits ***
>
> §2, first paragraph: Is the "user" the person requesting services from the
> ACME
> server?
>

Yes, but it's easier just to replace "the user's" with "a" :)



> §10.2: "
>It is RECOMMENDED that the server perform DNS queries and make HTTP
>connections from various network perspectives..."
>
> §7.3.6: " The inner JWS is NOT REQUIRED to have a "nonce" header
> parameter."
>
> "NOT REQUIRED" is not among the terms defined by 2119/8174. I suspect this
> is
> intended as a statement of fact, and should therefore not be capitalized.
>

Changed "NOT REQUIRED to have" to "MAY omit".  I do want some 2119/8174
language here since it's modifying normative requirements above



> I'm not sure what that means. Given that this uses an upper-case
> RECOMMENDED,
> can it be stated more concretely?
>

Not totally sure what's unclear here, but I added some words to try to
clarify.



> §13.3: Is this section also to be removed?
>

Yes, but presumably that will take care of itself once the reference is
removed in the XML.  In any case, this section is auto-created, so I can't
really edit it.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-ietf-acme-tls-alpn-03

[Richard Barnes]

I don't really think it matters much who's going to make a new version.
The only difference here is whether you go back to IANA to get a new code
point.  Given that the IANA process is not onerous, it seems like the extra
couple of octets are not really adding anything here.  So I'm inclined to
do as Russ suggests and just have future versions in the same ARC as
opposed to having a separate version field.  Like Roland, however, I don't
feel super strongly about this.

--Richard

On Tue, Aug 14, 2018 at 5:18 PM Roland Shoemaker 
wrote:

> The decision to format the OID this way was an early one that I’m not
> completely attached to. That said the existing solution does still feel
> cleaner to me than doing the versioning directly under id-pe. Given it’s
> unlikely that the version with be incremented by anything other than a
> document from the ACME WG, and that doing so is likely to deprecate the
> existing version it seems more prudent to me (from a inexperienced position
> admittedly) for this WG to manage the assignments of the versioned OIDs
> under the id-pe-acmeIdentifier arc rather than have to defer to the
> registration to the SMI numbers registry.
>
> With that said if there is WG consensus to move to this suggested version
> I’m happy to oblige and move forward with it.
>
> > On Aug 14, 2018, at 12:00 PM, Russ Housley  wrote:
> >
> > This document include a particular object identifier, and IANA has not
> assigned it yet.  Please do not assume that you will get the next available
> number.  Someone else could get there before you.
> >
> > This document uses the following syntax for the certificate extension:
> >
> >   id-pe-acmeIdentifier OBJECT IDENTIFIER ::=  { id-pe 31 }
> >
> >   id-pe-acmeIdentifier-v1 OBJECT IDENTIFIER ::=  {
> id-pe-acmeIdentifier 1 }
> >
> >   acmeValidation-v1 ::= OCTET STRING (SIZE (32))
> >
> > I see no reason for the middle value.  This would cause the creation os
> an additional table for IANA to maintain.
> >
> > Instead, I suggest using  { id-pe 31 } directly for the certificate
> extension.  If a v2 is needed in the future, another number from this same
> object identifier arc can be assigned for it.
> >
> > Russ
> > (The IANA Expert for the SMI Security for PKIX Certificate Extension
> registry)
> > ___
> > 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] I-D Action: draft-ietf-acme-acme-14.txt

[Richard Barnes]

This version just addresses a bunch of small things found during IETF LC.

EKR: I think this is ready for the IESG's consideration.

Thanks,
--Richard

On Fri, Aug 10, 2018 at 9:24 AM  wrote:

>
> 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-14.txt
> Pages   : 88
> Date: 2018-08-10
>
> 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-14
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-14
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-14
>
>
> 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
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard

[Richard Barnes]

I merged 433 and +1'ed some of your comments on 432.

People on the mailing list: Please note there is some discussion in the
linked issues.

--Richard

On Thu, Aug 9, 2018 at 10:40 AM Daniel McCarney  wrote:

> Thanks for the review/PRs Sean.
>
> I left a +1 for PR 433. Richard: can that be merged?
>
> I left some feedback on PR 432 and a question on issue 435.
>
>
>
> On Wed, Aug 8, 2018 at 11:42 PM, Sean Turner  wrote:
>
>> Okay two PRs:
>>
>> https://github.com/ietf-wg-acme/acme/pull/432
>> https://github.com/ietf-wg-acme/acme/pull/433
>>
>> And three issues:
>>
>> https://github.com/ietf-wg-acme/acme/issues/434
>> https://github.com/ietf-wg-acme/acme/issues/435
>> https://github.com/ietf-wg-acme/acme/issues/436
>>
>> spt
>>
>> > On Aug 8, 2018, at 21:48, Richard Barnes  wrote:
>> >
>> > Without looking at them in context that seem pretty reasonable.   Happy
>> to review a PR.
>> >
>> > On Wed, Aug 8, 2018, 21:03 Sean Turner  wrote:
>> > These are all minor so I didn’t send them to i...@ietf.org.  Also,
>> once we settle on whether these are okay, I can submit a PR if you’d like
>> (or not if that’ll be faster).
>> >
>> > 0) abstract
>> >
>> > r/certificate authorities/certification authorities
>> >
>> > and then you can:
>> >
>> > r/certification authority (CA)/CA
>> >
>> > 1) s1
>> >
>> > r/certificate authorities/certification authorities (CAs)
>> > r/certificate authorities/CAs
>> > r/CA web page/CA’s web page
>> > r/confusion/frustration and confusion
>> > r/infrastructural/infrastructure (?)
>> > r/PKIX authentication/PKIX-based authentication (?)
>> > r/WebPKI/Web PKI (? or should it go: r/Web PKI/WebPKI)
>> >
>> > 2) s3
>> >
>> > r/TLS certificates/certificates for TLS
>> >
>> > 3) s4
>> >
>> > r/in that certificate in order for
>> >the CA to sign the requested certificate./
>> > in that request certificate in order for
>> >the CA to issue the requested certificate.
>> >
>> > 4) s6.1
>> >
>> > Add reference for Access-Control-Allow-Origin header.
>> >
>> > 4) s6.2
>> >
>> > r/For newAccount requests, and for revokeCert requests authenticated by
>> >certificate key, there MUST be a "jwk" field./
>> > For newAccount requests, and for revokeCert requests authenticated by
>> >certified keys, there MUST be a "jwk" field.
>> >
>> > 5) s6.4 - since the previous section was JWS headers maybe:
>> >
>> > r/the Replay-Nonce header/the HTTP Replay-Nonce header
>> >
>> > 6) s6.4.1 - I assume it’s ABNF there, but based on RFC 7231 I guess
>> it’s worth a reference:
>> > New header field values ***typically*** have their syntax defined using
>> ABNF ([RFC5234]) …
>> > So maybe add the following right before the ABNF:
>> >
>> >   The ABNF [RFC5234] for the Replay-Nonce header field follows:
>> >
>> > 7) s6.5: need references?
>> >
>> > r/"Retry-After” header/"Retry-After" header [RFC7231]
>> > r/"Link” header/"Link" header [RFC8288]
>> >
>> > 8) s6.6: maybe the reference for the ACME URN namespace should be to
>> section 9.6?
>> >
>> > r/(within the
>> >"urn:ietf:params:acme:error:" namespace):/
>> > (within the ACME URN namespace
>> >"urn:ietf:params:acme:error:"):
>> >
>> > r/ACME URN [RFC3553] namespace/ACME URN namespace (see Section 9.6)
>> >
>> > 9) s7.1: add reference for REST?
>> >
>> > r/REST/REST [REST]
>> >
>> > [REST]Fielding, R., "Architectural Styles and the Design of
>> >   Network-based Software Architectures", 2000,
>> >
>> http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
>> >
>> > 10) s7.1.1: Should the "URL in values” in the table match the examples
>> later in the section? i.e.,:
>> >
>> > r/New nonce/new-nonce
>> > r/New account/new-account
>> >
>> > and so on?
>> >
>> > 11) s7.4.2: add reference for Accept Header?
>> >
>> > r/an Accept header/an Accept header {RFC7231]
>> >
>> > 12) s7.4.2: could also point to application/pkcs7-mime for PKCS7
>> certs-only messages.
>> >
>> > 13) s7.6: If the revocation request fails, which error is returned?
>> THe draft often
>> >
>> > 14) s9.1: Was there any thought given to an optional parameter
>> indicating how many certs would be in the chain?
>> >
>> > 15) s9.3: Should the reference be: [this-RFC, Section 6.4.1] to match
>> some of the other entries in the registry?  Or at least refer to [this-RFC]?
>> >
>> > Cheers,
>> >
>> > spt
>> >
>> >
>> >
>>
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard

[Richard Barnes]

Without looking at them in context that seem pretty reasonable.   Happy to
review a PR.

On Wed, Aug 8, 2018, 21:03 Sean Turner  wrote:

> These are all minor so I didn’t send them to i...@ietf.org.  Also, once
> we settle on whether these are okay, I can submit a PR if you’d like (or
> not if that’ll be faster).
>
> 0) abstract
>
> r/certificate authorities/certification authorities
>
> and then you can:
>
> r/certification authority (CA)/CA
>
> 1) s1
>
> r/certificate authorities/certification authorities (CAs)
> r/certificate authorities/CAs
> r/CA web page/CA’s web page
> r/confusion/frustration and confusion
> r/infrastructural/infrastructure (?)
> r/PKIX authentication/PKIX-based authentication (?)
> r/WebPKI/Web PKI (? or should it go: r/Web PKI/WebPKI)
>
> 2) s3
>
> r/TLS certificates/certificates for TLS
>
> 3) s4
>
> r/in that certificate in order for
>the CA to sign the requested certificate./
> in that request certificate in order for
>the CA to issue the requested certificate.
>
> 4) s6.1
>
> Add reference for Access-Control-Allow-Origin header.
>
> 4) s6.2
>
> r/For newAccount requests, and for revokeCert requests authenticated by
>certificate key, there MUST be a "jwk" field./
> For newAccount requests, and for revokeCert requests authenticated by
>certified keys, there MUST be a "jwk" field.
>
> 5) s6.4 - since the previous section was JWS headers maybe:
>
> r/the Replay-Nonce header/the HTTP Replay-Nonce header
>
> 6) s6.4.1 - I assume it’s ABNF there, but based on RFC 7231 I guess it’s
> worth a reference:
> New header field values ***typically*** have their syntax defined using
> ABNF ([RFC5234]) …
> So maybe add the following right before the ABNF:
>
>   The ABNF [RFC5234] for the Replay-Nonce header field follows:
>
> 7) s6.5: need references?
>
> r/"Retry-After” header/"Retry-After" header [RFC7231]
> r/"Link” header/"Link" header [RFC8288]
>
> 8) s6.6: maybe the reference for the ACME URN namespace should be to
> section 9.6?
>
> r/(within the
>"urn:ietf:params:acme:error:" namespace):/
> (within the ACME URN namespace
>"urn:ietf:params:acme:error:"):
>
> r/ACME URN [RFC3553] namespace/ACME URN namespace (see Section 9.6)
>
> 9) s7.1: add reference for REST?
>
> r/REST/REST [REST]
>
> [REST]Fielding, R., "Architectural Styles and the Design of
>   Network-based Software Architectures", 2000,
>   http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
>
> 10) s7.1.1: Should the "URL in values” in the table match the examples
> later in the section? i.e.,:
>
> r/New nonce/new-nonce
> r/New account/new-account
>
> and so on?
>
> 11) s7.4.2: add reference for Accept Header?
>
> r/an Accept header/an Accept header {RFC7231]
>
> 12) s7.4.2: could also point to application/pkcs7-mime for PKCS7
> certs-only messages.
>
> 13) s7.6: If the revocation request fails, which error is returned?  THe
> draft often
>
> 14) s9.1: Was there any thought given to an optional parameter indicating
> how many certs would be in the chain?
>
> 15) s9.3: Should the reference be: [this-RFC, Section 6.4.1] to match some
> of the other entries in the registry?  Or at least refer to [this-RFC]?
>
> Cheers,
>
> spt
>
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] DE review comment draft-ietf-acme-acme

[Richard Barnes]

Seems reasonable. I filed ,
which I'll handle with the rest of LC comments in a couple of days.

On Tue, Aug 7, 2018 at 7:59 PM Jim Schaad  wrote:

> It would be nice to have the description for the JOSE header 'url' be more
> descriptive that the string 'URL'.  From the description in the text I
> would
> assume that 'Targeted URL' or similar is correct and more descriptive
> unless
> the usage is going to be application specific.
>
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-ip-03.txt

[Richard Barnes]

You beat me to it.

On Wed, Jul 25, 2018 at 1:59 PM Salz, Rich  wrote:

> Use ip-addr.arpa names?
>
>
> ___
> 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] Consensus on WGLC for draft-ietf-acme-star-03

[Richard Barnes]

As a point of order, I'm pretty sure the chairs don't need consensus to
move to WGLC, they can just do it.

On Wed, Jul 18, 2018 at 3:53 PM Salz, Rich  wrote:

> For context: this is draft-ietf-acme-star-03 as mentioned in the Subject
> but not the body.
>
>
>
> *From: *Rich Salz 
> *Date: *Wednesday, July 18, 2018 at 2:50 PM
> *To: *"Salz, Rich" , "acme@ietf.org" <
> acme@ietf.org>
> *Subject: *Re: [Acme] Consensus on WGLC for draft-ietf-acme-star-03
>
>
>
> Please reply by Wednesday, a week.
>
>
>
> *From: *"Salz, Rich" 
> *Date: *Wednesday, July 18, 2018 at 2:49 PM
> *To: *"acme@ietf.org" 
> *Subject: *[Acme] Consensus on WGLC for draft-ietf-acme-star-03
>
>
>
> At London, the WG decided to have draft-ietf-acme-star to WGLC, but the
> chairs dropped the ball.
>
>
>
> Does anyone object to doing this?  We would particularly like to also know
> if you have read the document.
>
>
>
> Thanks.
> ___
> 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] Confirming consensus

[Richard Barnes]

On Thu, Jul 19, 2018, 17:05 Ilari Liusvaara 
wrote:

> On Thu, Jul 19, 2018 at 01:03:14PM -0700, Roland Shoemaker wrote:
> > One thing that I forgot to bring up during the meeting was an issue
> > that was brought up with regards to the order in which the ACME-TLS-ALPN
> > and ACME-IP drafts are standardized. ACME-IP defines how to use IP
> > addresses with existing challenges and we’d like to include guidance
> > on how to do so with TLS-ALPN, but (as far as I’m aware) we are unable
> > to reference IDs in RFCs so we cannot directly reference
> > draft-ietf-acme-tls-alpn
>
> This is incorrect. IDs can normatively reference other IDs, if
> there is a "plan" on getting the referenced ID ready to be published.
> If needed, the referencing draft waits for the referenced one in
> RFC-Editor queue.
>
> So I think the easiest way is to just have normative reference
> ACME-IP -> TLS-ALPN.
>

+1


>
> -Ilari
>
> ___
> 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] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

 and based on feedback at the meeting, I went ahead and merged this.  I
understand that EKR will be issuing an IETF last call soon, so if you have
concerns about this change, please raise them there.  Or on this thread,
but in any case, ASAP.

Thanks,
--Richard

On Tue, Jul 17, 2018 at 4:27 PM Richard Barnes  wrote:

> I went ahead and posted a PR implementing EKR's suggestion:
>
> https://github.com/ietf-wg-acme/acme/pull/429
>
>
> On Wed, May 30, 2018 at 4:23 PM Daniel McCarney 
> wrote:
>
>> We have multiple CA’s that support it, and other implementations as well.
>>
>>
>> Of the multiple CAs that support ACME, which support something resembling
>> the current draft? When I looked last the non-Let's Encrypt ACME server
>> implementations all seemed to be targeting Certbot and the "ACMEv1" era of
>> this draft (e.g. are not using the order based issuance flow at all). There
>> have been substantial backwards compatibility breaking changes in the draft
>> since this time.
>>
>> I second EKR's sentiment that there has been little true ACME inter-op
>> testing of the protocol as described in draft-12 outside of that done with
>> Let's Encrypts ACMEv2 endpoint.
>>
>> - Daniel / cpu
>>
>> On Wed, May 30, 2018 at 3:56 PM, Salz, Rich <
>> rsalz=40akamai@dmarc.ietf.org> wrote:
>>
>>>
>>>- Well, we have a fair bit of experience of a lot of people talking
>>>to Let's Encrypt. That's not really the same as a lot of servers and a 
>>> lot
>>>of clients.
>>>
>>>
>>>
>>> We have multiple CA’s that support it, and other implementations as
>>> well.  Certainly LE dominates, but it’s not the only usage.  And certainly
>>> not the only anticipated future usage.
>>>
>>>
>>>
>>>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA
>>>with X25519.
>>>
>>>
>>>
>>> That would make the MTI limited to a subset of the WebPKI supported by
>>> the latest browsers, which seems wrong.  But let’s not bikeshed too much
>>> and see what the WG consensus is.
>>>
>>>
>>>
>>> ___
>>> 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] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

I went ahead and posted a PR implementing EKR's suggestion:

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


On Wed, May 30, 2018 at 4:23 PM Daniel McCarney  wrote:

> We have multiple CA’s that support it, and other implementations as well.
>
>
> Of the multiple CAs that support ACME, which support something resembling
> the current draft? When I looked last the non-Let's Encrypt ACME server
> implementations all seemed to be targeting Certbot and the "ACMEv1" era of
> this draft (e.g. are not using the order based issuance flow at all). There
> have been substantial backwards compatibility breaking changes in the draft
> since this time.
>
> I second EKR's sentiment that there has been little true ACME inter-op
> testing of the protocol as described in draft-12 outside of that done with
> Let's Encrypts ACMEv2 endpoint.
>
> - Daniel / cpu
>
> On Wed, May 30, 2018 at 3:56 PM, Salz, Rich <
> rsalz=40akamai@dmarc.ietf.org> wrote:
>
>>
>>- Well, we have a fair bit of experience of a lot of people talking
>>to Let's Encrypt. That's not really the same as a lot of servers and a lot
>>of clients.
>>
>>
>>
>> We have multiple CA’s that support it, and other implementations as
>> well.  Certainly LE dominates, but it’s not the only usage.  And certainly
>> not the only anticipated future usage.
>>
>>
>>
>>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA
>>with X25519.
>>
>>
>>
>> That would make the MTI limited to a subset of the WebPKI supported by
>> the latest browsers, which seems wrong.  But let’s not bikeshed too much
>> and see what the WG consensus is.
>>
>>
>>
>> ___
>> 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] Do we need/want mandatory-to-implement signature algorithms?

[Richard Barnes]

On Thu, May 31, 2018 at 5:09 PM Eric Rescorla  wrote:

>
>
> On Thu, May 31, 2018 at 2:03 PM, Richard Barnes  wrote:
>
>>
>>
>> On Wed, May 30, 2018 at 5:41 PM Stephen Farrell <
>> stephen.farr...@cs.tcd.ie> wrote:
>>
>>>
>>> Hi Russ,
>>>
>>> On 30/05/18 22:31, Russ Housley wrote:
>>> > It seems to me that ACME is being used to support certificate
>>> > enrollment for many different applications, so the same approach
>>> > seems appropriate.
>>> I agree with your description of the past:-)
>>>
>>> I don't agree with not specifying MTI algs though.
>>>
>>> My main reasons are that I think having MTI algorithms for
>>> acme may lead to better interop and less proliferation of
>>> algorithms/suites and less broken/non-tested code. (I
>>> forget what I thought about this years ago, but I may have
>>> changed opinion - it was reasonable for PKIX to not specify
>>> MTI algs a decade or two ago, but that that is no longer a
>>> good plan, as we now do really use all this stuff.)
>>>
>>> That said, I don't feel too strongly about it - in practice
>>> I reckon all acme clients will in any case want to implement
>>> and be able to use whatever works with LE, at least for the
>>> next while, and so this won't be a practical problem either
>>> way.
>>>
>>
>> I am also not that sanguine about this topic, but I lean in the opposite
>> direction.  The list of JWS algorithms [1] is not that long, and not
>> growing quickly.  And there's no Ed25519.  So if we were to pick one or
>> more MTIs out of this list, we would basically be locking in to ECDSA or
>> RSA-PSS.
>>
>> As far as MTnotI: The SHA-1-based algorithms are already marked
>> "Prohibited".  I guess you could ban RSA with PKCS#1v1..5, but that seems
>> fairly low-value.
>>
>> Basically, it seems like the burden of those who want MUSTs here to make
>> a proposal for what the MUSTs would be.
>>
>
> I made that proposal in a separate message: ECDSA w/ P-256 MUST,  EdDSA
> X25519 SHOULD.
>

Sorry, missed that in the thread switch.

I could live with that.  I was incorrect when I said Ed25519 doesn't exist
for JWS; I had missed the "EdDSA" value defined in RFC 8037.

--Richard


>
> -Ekr
>
>
>> --Richard
>>
>> [1]
>> https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
>>
>> ___
>> 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] Do we need/want mandatory-to-implement signature algorithms?

[Richard Barnes]

On Wed, May 30, 2018 at 5:41 PM Stephen Farrell 
wrote:

>
> Hi Russ,
>
> On 30/05/18 22:31, Russ Housley wrote:
> > It seems to me that ACME is being used to support certificate
> > enrollment for many different applications, so the same approach
> > seems appropriate.
> I agree with your description of the past:-)
>
> I don't agree with not specifying MTI algs though.
>
> My main reasons are that I think having MTI algorithms for
> acme may lead to better interop and less proliferation of
> algorithms/suites and less broken/non-tested code. (I
> forget what I thought about this years ago, but I may have
> changed opinion - it was reasonable for PKIX to not specify
> MTI algs a decade or two ago, but that that is no longer a
> good plan, as we now do really use all this stuff.)
>
> That said, I don't feel too strongly about it - in practice
> I reckon all acme clients will in any case want to implement
> and be able to use whatever works with LE, at least for the
> next while, and so this won't be a practical problem either
> way.
>

I am also not that sanguine about this topic, but I lean in the opposite
direction.  The list of JWS algorithms [1] is not that long, and not
growing quickly.  And there's no Ed25519.  So if we were to pick one or
more MTIs out of this list, we would basically be locking in to ECDSA or
RSA-PSS.

As far as MTnotI: The SHA-1-based algorithms are already marked
"Prohibited".  I guess you could ban RSA with PKCS#1v1.5, but that seems
fairly low-value.

Basically, it seems like the burden of those who want MUSTs here to make a
proposal for what the MUSTs would be.

--Richard

[1]
https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

On Tue, May 29, 2018 at 4:02 PM Eric Rescorla  wrote:

>
>
> On Mon, May 28, 2018 at 9:57 PM, Russ Housley 
> wrote:
>
>> Eric:
>>
>>
>> > > Do you want to specify a set of acceptable signature algorithms here?
 >
 > I am inclined not to.  We have already forbidden "none" and MAC.  We
 > shouldn't specify "MUST"s here, because CABF sets their own list of
 > required algorithms, and we don't want to conflict.  I guess you
 > could specify some MUST NOTs pretty safely, but given that they're
 > already forbidden by CABF, it seems kind of duplicative.

 This is about the signatures that ACME accepts, not the signatures
 in certs. Does CABF have a position on what signature algorithms
 that ACME uses?

>>>
>>> Good point.  As Ryan pointed out, this is not something on which there
>>> is currently CABF guidance.
>>>
>>> Nonetheless, I'm still disinclined to have MUSTs here for other
>>> reasons.  If they're positive "MUST support" requirements, then we would
>>> need to come back and revise this document in the event of an algorithm
>>> break (though admittedly, that would be pretty far down on the TODO list).
>>> And looking at the current list of JWS algorithms, I don't see any I would
>>> MUST NOT, except possibly the ones based on SHA-1
>>>
>>
>> Hmm... Common practice in security protocols is to specify MTI
>> algorithms. Why is this different?
>>
>>
>> PKIX chose not to specify mandatory-to-implement algorithms.  This was
>> done because the application that made use of the certificate needed to be
>> able to impose such requirements.
>>
>> Here is one place from the PKIX WG archive in 2011 that states this
>> approach:
>>
>>(
>> https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs)
>>
>>PKIX defines PKI specs for a very wide range of apps, which is why we
>>do not mandate any alg suite.  Different apps may use different alg
>> suites.
>>TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself.
>>
>> It seems to me that ACME is being used to support certificate enrollment
>> for many different applications, so the same approach seems appropriate.
>>
>
> Hmm... This seems like it would be more persuasive if there weren't a
> dependency on TLS and its MTI algorithms
>
> From my perspective, this is sort of on the bubble. Historically, I've
> seen the IESG insist on MTI algorithms, but it's not consistent. I would
> like to understand if this is something that has strong consensus in the
> WG, in which case I'll support that (though other IESG members may feel
> differently) or if it just happened, in which case I'd ask the WG to
> reconsider.
>

I think it's more in the latter category in the former, but TBH, I think
that kind of argues in favor of the status quo -- we have a fair bit of
implementation / deployment experience, and this has not been an interop
problem.

In a similar vein, where we have had discussion of versioning (a similar
issue) there's been consensus *not* to go the traditional route of having
version numbers -- you just have to know what version of ACME the endpoint
you're talking to speaks.  It doesn't seem totally crazy to me for the same
to be true of the signing algorithms you use.

I guess I don't really know what value you're solving for here.  Just to
try to make this concrete, if you were going to propose some algorithms to
be MTI / MTnotI, what would you list?

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

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

On Tue, May 15, 2018 at 2:37 AM Ilari Liusvaara <ilariliusva...@welho.com>
wrote:

> On Tue, May 15, 2018 at 01:20:14AM +, Richard Barnes wrote:
> >  [ Adding the mailing list ]
> >
> > > S 6.6.
> > > >  |
> > | |
> > > >  | serverInternal  | The server experienced an
> > internal  |
> > > >  | |
> > error   |
> > > >  |
> > | |
> > > >  | tls | The server received a TLS error
> > during  |
> > > >  | |
> > validation  |
> > >
> > > Can you expand on what this means? Suppose instead I got a 500 during
> > > validation?
> >
> > [[ EDIT - 272c754 ]]
> >
> > I think this goes back to when the TLS-SNI challenge.  It's no longer
> > relevant here, so I've removed it.  The new TLS-based challenge can
> re-add
> > it if they need it.
>
> This is incorrect. It is neeed by HTTP-01 already, because that can
> redirect to https://, which then tries to set up TLS, which can fail
> even when the TCP connection succeeded. And given flakyness of
> validation in general, one does not want misleading errors to make
> things even harder.
>

Good point.  I've backed out this change in my working copy.

--Richard



>
> One of the more creative ones I have heard about is misconfigured
> servers that interpret the TLS ClientHello as malformed HTTP request
> and sends back HTTP 400 Bad Request, which the TLS client then tries
> to parse as ServerHello and obviously chokes. This issue is apparently
> not that rare, in fact, Let's Encrypt specifically checks for TLS
> ServerHellos that look like HTTP replies.
>
>
> -Ilari
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

 [ Adding the mailing list ]

Thanks for the thorough review, EKR.  I've posted a PR with proposed
resolutions:

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

You do hit on a couple of moderately technical points, some of which I
would like the WG to take a quick look at.  Those are highlighted with
"DISCUSS" below.  Simple edits are tagged with "EDIT", and questions for
the AD are marked with "QUESTION".  Ones where I don't think there's a need
for a change are unmarked.

Rather than split things out into separate PRs, I've just made one big PR,
with issues in different commits.  The various issue tags below include the
ID of the corresponding commits.

Chairs / AD: While there are a couple of issues here where I'd like some
eyes besides the authors, I would propose that if we do a re-WGLC, it be
abbreviated, say 1 week.  I do not think these changes merit a new IETF LC.

Thanks,
--Richard


> Because I am now the sponsoring AD for this document, I have performed
> my own review.
>
> This document seems technically sound and is well-written. I have
> raised a number of points below for consideration.
>
>
> IMPORTANT
> S 6.2.
> > algorithm in its "alg" field
> >
> >  o  The JWS Payload MUST NOT be detached
> >  o  The JWS Protected Header MUST include the following fields:
> >
> > *  "alg" (Algorithm)
>
> Do you want to specify a set of acceptable signature algorithms here?

I am inclined not to.  We have already forbidden "none" and MAC.  We
shouldn't specify "MUST"s here, because CABF sets their own list of
required algorithms, and we don't want to conflict.  I guess you could
specify some MUST NOTs pretty safely, but given that they're already
forbidden by CABF, it seems kind of duplicative.


> S 6.3.
> >  As noted in Section 6.2 above, all ACME request objects carry a
"url"
> >  header parameter in their protected header.  This header parameter
> >  encodes the URL to which the client is directing the request.  On
> >  receiving such an object in an HTTP request, the server MUST
compare
> >  the "url" header parameter to the request URL.  If the two do not
> >  match, then the server MUST reject the request as unauthorized.
>
> I think you probably need to provide a clear definition of how you
> "compare" them. Is it memcmp? Something else?

This is specified further down:

"""
The server SHOULD perform the corresponding string equality check,
configuring each resource with the URL string provided to clients and
having the resource check that requests have the same string in their “url”
header parameter.
"""


> S 6.4.1.
> >
> >  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.
> >
> >base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
>
> I am surprised you need to define the BNF for this here. Aren't you
> now creating a separate normative definition.

I can see why this is surprising.  After a bit of searching, though, I
can't find another set of ABNF that matches.  For example, RFC 5802 (SASL
SCRAM) defines its own ABNF for Base64 (in the normal "+/=" encoding), as
does RFC 8224 (SIP Identity).  I note that the list of authors on the
latter includes a certain Mr. Rescorla :)

https://tools.ietf.org/html/rfc5802#section-7
https://tools.ietf.org/html/rfc8224#section-4


> S 7.1.2.
> > initiated deactivation.
> >
> >  contact (optional, array of string):  An array of URLs that the
> > 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.
>
> How am I supposed to know the semantics of these strings? And if they
> are non-mailto URLs, what am I supposed to do with them.

To first order, the semantic is defined by the scheme of the URL --
"mailto" says "email me", "sip" or "tel" says "give me a call", etc.  We
have the "unsupportedContact" error type if the server doesn't know how to
leverage a given scheme.

Of course there are URL schemes that don't make sense as a contact point
(e.g., "data:"), but trying to enumerate those seems quixotic.  Better for
the CA to check and reject with the error code we have provided.


> S 7.1.3.
> > authorizations required are dictated by server policy and there
> > may not be a 1:1 relationship between the order identifiers and
> > the authorizations required.  For final orders (in the "valid"
or
> > "invalid" state), the authorizations that were completed.  Each
> > entry is a URL from which an authorization can be fetched with a
> > GET request.
>
> This text seems inconsistent with "immutable" below, because if I have
> completed authorization "a" then I don't need to complete it, but it
> has to stay in the list.

[[ EDIT - 

Re: [Acme] Genart last call review of draft-ietf-acme-acme-11

[Richard Barnes]

Hi Dale,

Thanks for the review.  Responses inline below; changes in this PR:

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


On Wed, Apr 18, 2018 at 9:03 PM, Dale Worley  wrote:

> Reviewer: Dale Worley
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft.  The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> .
>
> Document:  draft-ietf-acme-acme-11
> Reviewer:  Dale R. Worley
> Review Date:  2018-04-18
> IETF LC End Date:  2018-04-18
> IESG Telechat date:  2018-05-10
>
> Summary:
>
>This draft is on the right track but has open issues, described
>in the review.
>
> This draft is much better than the version (-08) that I previously was
> the assigned Gen-ART reviewer for.  The overall work and exposition
> are quite solid, though there are some open technical issues that need
> to be resolved.
>
> * Technical issues
>
> What is the versioning and extensibility system?  -- It seems that the
> natural approach is that structures returned by fetches of Acme
> resources may contain elements that are not defined in this document,
> and a client should ignore them if it doesn't understand them.  This
> allows plenty of flexibility for extending the Acme protocol; in
> particular, by adding further resources to the directory object.
>

The WG discussed versioning / extensibility several times, and concluded
that on the one hand, there are enough extension points in the protocol to
cover many cases (e.g., new challenge types), and on the other hand,
extensions that are not compatible with that approach can be handled with a
new API endpoint.  Clients have always needed to be configured with an HTTP
URL for the directory; this just notes that they also need to know what
flavor of ACME is running there.

In other words, there's no need for version negotiation in-band to the
protocol.



> The handling of "terms of service agreement" seems to be insufficient,
> in that none of the information passed around says *what* agreement
> the client has agreed to.  The client only sends
> "termsOfServiceAgreed:true" in a request, leaving what has been agreed
> to unspecified -- and unauditable.  One possibility is to add an
> argument for the client to provide the URL from which it fetched the
> ToS (so the server knows what agreement the client is referring to)
> and the hash of the ToS document (so the client must attest to what
> the agreement text was).
>

This mechanism has been reviewed by multiple CAs and found to be sufficient
for their needs.  A prior version had an explicit URL, and it was found to
cause interop problems.



> 6.6.1.  Subproblems
>
> What error type should be used in a problem document when there are
> subproblem documents?  It seems that in this situation, the intention
> is that the top-level problem document is not intended to carry error
> information itself, so you want to define a "subproblems" error type,
> to use when there is no natural overall error type.
>
> * Editorial issues
>
> 7.1.  Resources
>
> The position of "newNonce" in the diagram is strange.  Does it have a
> different relationship to the directory resource than newAccount,
> etc.?  Similarly for the "finalize" and "cert" URLs of an order
> object. -- Reading further in the draft suggests that the graphical
> difference indicates that that these values are optional in the
> respective objects, although the text doesn't identify that.
>

I don't think it's all that useful to parse close semantics into this
diagram.  "newNonce" is different, in that it serves an underlying
transport purpose, rather than a certificate management purpose.



> 7.1.2.  Account Objects
>
>contact (optional, array of string):  An array of URLs that the
>   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.
>
> I mentioned this in my review of -08, but it hasn't been fixed:
> Strictly, you want "URIs" here, as tel:, sip:, and mailto: URIs are
> not URLs [RFC 6068].
>

For readability in the implementer community, where "URL" is much more
widely used than "URI", the convention in this document is to use "URL".
It seems unlikely this will lead to interop problems.



> 7.3.5.  External Account Binding
>
>To enable ACME account binding, a CA needs to provide the ACME client
>with a MAC key and a key identifier, using some mechanism outside of
>ACME.  The key identifier MUST be an ASCII string.  The MAC key
>SHOULD be provided in base64url-encoded form, to maximize
>compatibility between non-ACME provisioning systems and ACME clients.
>
> I *think* what this means is 

Re: [Acme] Genart last call review of draft-ietf-acme-acme-11

[Richard Barnes]

Hi Dale,

Thanks for the review.  Responses inline below; changes in this PR:

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


On Wed, Apr 18, 2018 at 9:03 PM, Dale Worley  wrote:

> Reviewer: Dale Worley
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft.  The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> .
>
> Document:  draft-ietf-acme-acme-11
> Reviewer:  Dale R. Worley
> Review Date:  2018-04-18
> IETF LC End Date:  2018-04-18
> IESG Telechat date:  2018-05-10
>
> Summary:
>
>This draft is on the right track but has open issues, described
>in the review.
>
> This draft is much better than the version (-08) that I previously was
> the assigned Gen-ART reviewer for.  The overall work and exposition
> are quite solid, though there are some open technical issues that need
> to be resolved.
>
> * Technical issues
>
> What is the versioning and extensibility system?  -- It seems that the
> natural approach is that structures returned by fetches of Acme
> resources may contain elements that are not defined in this document,
> and a client should ignore them if it doesn't understand them.  This
> allows plenty of flexibility for extending the Acme protocol; in
> particular, by adding further resources to the directory object.
>

The WG discussed versioning / extensibility several times, and concluded
that on the one hand, there are enough extension points in the protocol to
cover many cases (e.g., new challenge types), and on the other hand,
extensions that are not compatible with that approach can be handled with a
new API endpoint.  Clients have always needed to be configured with an HTTP
URL for the directory; this just notes that they also need to know what
flavor of ACME is running there.

In other words, there's no need for version negotiation in-band to the
protocol.



> The handling of "terms of service agreement" seems to be insufficient,
> in that none of the information passed around says *what* agreement
> the client has agreed to.  The client only sends
> "termsOfServiceAgreed:true" in a request, leaving what has been agreed
> to unspecified -- and unauditable.  One possibility is to add an
> argument for the client to provide the URL from which it fetched the
> ToS (so the server knows what agreement the client is referring to)
> and the hash of the ToS document (so the client must attest to what
> the agreement text was).
>

This mechanism has been reviewed by multiple CAs and found to be sufficient
for their needs.  A prior version had an explicit URL, and it was found to
cause interop problems.



> 6.6.1.  Subproblems
>
> What error type should be used in a problem document when there are
> subproblem documents?  It seems that in this situation, the intention
> is that the top-level problem document is not intended to carry error
> information itself, so you want to define a "subproblems" error type,
> to use when there is no natural overall error type.
>
> * Editorial issues
>
> 7.1.  Resources
>
> The position of "newNonce" in the diagram is strange.  Does it have a
> different relationship to the directory resource than newAccount,
> etc.?  Similarly for the "finalize" and "cert" URLs of an order
> object. -- Reading further in the draft suggests that the graphical
> difference indicates that that these values are optional in the
> respective objects, although the text doesn't identify that.
>

I don't think it's all that useful to parse close semantics into this
diagram.  "newNonce" is different, in that it serves an underlying
transport purpose, rather than a certificate management purpose.



> 7.1.2.  Account Objects
>
>contact (optional, array of string):  An array of URLs that the
>   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.
>
> I mentioned this in my review of -08, but it hasn't been fixed:
> Strictly, you want "URIs" here, as tel:, sip:, and mailto: URIs are
> not URLs [RFC 6068].
>

For readability in the implementer community, where "URL" is much more
widely used than "URI", the convention in this document is to use "URL".
It seems unlikely this will lead to interop problems.



> 7.3.5.  External Account Binding
>
>To enable ACME account binding, a CA needs to provide the ACME client
>with a MAC key and a key identifier, using some mechanism outside of
>ACME.  The key identifier MUST be an ASCII string.  The MAC key
>SHOULD be provided in base64url-encoded form, to maximize
>compatibility between non-ACME provisioning systems and ACME clients.
>
> I *think* what this means is