Re: [Acme] acme subdomains open items

[Felipe Gasper]

I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to 
choose whether it tries authz against parent domains without the client’s 
requesting it?

This is how our (non-ACME) Sectigo integration works currently, and it suits us 
well.

-F

> On Dec 4, 2020, at 02:23, Owen Friel (ofriel) 
>  wrote:
> 
> 
> Hi all,
>  
> As recommended by the chairs at IETF109, bring the two open items to the list 
> for discussion. These were raised by Felipe and Ryan previously.
>  
> 1: Does the client need a mechanism to indicate that they want to authorize a 
> parent domain and not the explicit subdomain identifier? Or a mechanism to 
> indicate that they are happy to authorize against a choice of identifiers?
>  
> E.g. for foo1.foo2.bar.example.com, should the client be able to specify 
> anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?
>  
> 2: Does the server need a mechanism to provide a choice of identifiers to the 
> client and let the client chose which challenge to fulfil?
>  
> E.g. for foo1.foo2.bar.example.com, should the server be able to specify 
> anywhere from 1 to 4 identifiers that the client can pick from to fulfil?
>  
> Both 1 and 2 require JSON object definition changes. Currently, the document 
> only defines how a client can submit a newOrder / newAuthz for a subdomain, 
> and the server can chose any one parent identifier that it requires a 
> challenge fulfilment on
>  
> Owen
>  
> https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01
>  
> https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4
>  
> ___
> 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] dns-01 challenge limitations

[Felipe Gasper]

> On Sep 11, 2020, at 9:08 AM, Simon Ser  wrote:
> 
> For instance, it would be possible to require users to add a short public key
> in a DNS TXT record, then ask the ACME client to sign challenges with that 
> key.
> Something like this would significantly ease the development of ACME clients.

This would seem to introduce a new vector--key compromise--for being able to 
impersonate the domain, wouldn’t it?

Such an authz method would be proving not access to the domain itself, but 
access to the key, and would be vulnerable to local misconfigurations. It seems 
thus not dissimilar to the erstwhile problem with tls-sni-01/02.

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

Re: [Acme] Review of draft-friel-acme-subdomains-02

[Felipe Gasper]

Hi all,

What if … there’s no need for a standard for this? Or at least, the 
standard would require no significant changes to the protocol?

The application that I help manage integrates alternately with Sectigo 
and with Let’s Encrypt. Sectigo, when they verify domain control, always checks 
parent domains along with the domain(s) given in the certificate order. If any 
of those checks succeeds, the authz is valid. Perhaps the standard could be 
defined merely in those terms, such that CAs who so choose could simply 
indicate in the authz objects that parent/ancestor domains suffice for the 
verification?

This would also allow CAs to mandate that such liberty apply only to 
DNS-based authz, while still requiring HTTP-based authz to be against the 
literal identifier.

A bit of context: our application runs on shared-hosting servers that 
we don’t administer, subject to firewall rules that neither we nor the admin 
may control. The admins run the gamut of competence, from highly-skilled on 
down. The domains are end-user-controlled, not necessarily registered with the 
same organization that administers the server. We’ve seen all kinds of crazy 
setups that complicate SSL issuance, as a result of which our 
certificate-provision logic attempts to accommodate potential 
misconfigurations. Sectigo’s acceptance of ancestor domains for authz helps 
toward that end since all we have to do to capitalize on it is to create the 
relevant HTTP docroot files or DNS records all at once, then send the order. 
Some oddity might frustrate direct authz against “www.whatever.bobs-store.com”, 
but as long as “bobs-store.com” works, we can still secure the subdomain.

An alternate implementation might be for authz objects to include 
challenges against whatever ancestor domains and methods the server allows; 
thus, if I do newAuthz against “foo.bar.example.com”, I might get back:

- http-01, foo.bar.example.com
- tls-alpn-01, foo.bar.example.com
- dns-01, foo.bar.example.com
- dns-01, bar.example.com
- dns-01, example.com

The disadvantage to that, for us, would be that we’d have to recreate 
the authz for every failure. I assume that that’s also disadvantageous for the 
ACME server--more so than simply doing “fallback” authz checks against parent 
domains.

That aside, as to Owen’s proposal document:

- How is the client to indicate that they want to authz the parent domain 
(example.com) rather than the literal identifier (sub0.example.com)? And for 
foo.bar.example.com, how shall the client indicate which parent domain is to be 
used for authz?


Thank you!

cheers,
-Felipe Gasper


> On Sep 2, 2020, at 5:41 AM, Owen Friel (ofriel) 
>  wrote:
> 
> Thanks Russ. I've addressed all these in github at: 
> https://github.com/upros/acme-subdomains/blob/master/draft-friel-acme-subdomains.md.
>  I have not pushed out draft-03 yet, lets see what Jacob and Felipe have to 
> say on the related thread about challenge options, and I will incorporate 
> then.
> 
> 
> -Original Message-
> From: Acme  On Behalf Of Russ Housley
> Sent: 05 August 2020 06:44
> To: IETF ACME 
> Subject: [Acme] Review of draft-friel-acme-subdomains-02
> 
> Document: draft-friel-acme-subdomains-02
> Reviewer: Russ Housley
> Date: 2020-08-04
> 
> Major Concern:
> 
> The TODO markers regarding wildcard domain names, the 200 response code, and 
> the security considerations should be filled in with strawman text before 
> this I-D is adopted by the ACME WG.
> 
> 
> Minor Concerns:
> 
> General: s/certificate authority/certification authority/ (many)
> 
> Abstract: s/certificate authority policy/certificate policy/
> 
> Introduction: s/X.509 (PKIX)/X.509v3 (PKIX) [RFC5280]/
> 
> Terminology: Correct CA, please.  See above.
> 
> Terminology: Please add a definition of subdomain.
> 
> 
> Nits:
> 
> Section 3: says:
> 
>   3.  client sends POST-as-GET requests to retrieve the
>   "authorizations", with the downloaded "authorization" object(s)
>   containing the "identifier" that the client must prove control of
> 
> s/client must prove control of/client must prove that they control/
> 
> There is something wrong with the table formatting in Section 6.2.
> 
> ___
> 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

[Acme] ACME subdomains

[Felipe Gasper]

As regards https://tools.ietf.org/html/draft-friel-acme-subdomains-02 ...

Is the idea that the client will, if requesting authz on sub.example.com, 
*only* be able to do authz against the parent domain (example.com)?

It would seem advantageous—from the client’s perspective, anyway—to allow a 
workflow where the client can do authz against one or the other. For longer 
subdomains, e.g., foo.bar.example.com, likewise, ideally the domain itself or 
either parent domain would work.

Was this considered and deemed infeasible?

Thank you!

-Felipe Gasper___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Felipe Gasper]

> On Jan 21, 2020, at 8:04 AM, Ryan Sleevi  wrote:
> 
> On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel)  wrote:
> > Also, the linked document states:
> > 
> >The call flow illustrates the DNS-based proof of ownership mechanism,
> >but the subdomain workflow is equally valid for HTTP based proof of
> >ownership.
> > 
> > Can’t I have HTTP access to a base domain’s website without having access 
> > to a
> > subdomain’s, though? I thought that was the reason why ACME limits wildcard
> > authz to DNS.
> 
> [ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an ACME 
> limitation.
> 
> Although the CA/Browser Forum / Browser Stores have repeatedly discussed 
> forbidding it. That is, allowing the HTTP and TLS methods of validation to 
> only be scoped for the host in question (and potentially the service in 
> question, if we can work out the safe SRVName transition, due to the 
> interaction of nameConstraints and policy)
> 
> Would it be simpler to remove the statement from the draft, rather than try 
> to clarify equally valid refers to the technology without commenting on the 
> policy?

For what my opinion is worth, that seems reasonable--though perhaps the best 
might be to defer explicitly to the CA/B guidelines, e.g., “whatever validation 
methods CA/B allows for subdomains/wildcards, this also allows.”

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

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Felipe Gasper]

> On Jan 21, 2020, at 7:13 AM, Owen Friel (ofriel)  wrote:
> 
>> 
>> Will this document eventually also describe subdomain authz via the standard
>> ACME workflow?
>> 
>> 
> 
> [ofriel] That’s the exact workflow that the document is attempting to 
> describe, so maybe it needs to be clarified.
> The example section 
> https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.2 (and I 
> realise now looking at it that I messed up the numbered steps - they are all 
> '1') outlines a client authorizing for "example.com" and getting certs for 
> "sub0.example.com", "sub1.example.com" and "sub2.example.com". If its not 
> clear, I can try reword in an update.

Your document seems to confine itself to the pre-authorization workflow, though 
(as per section 4’s 2nd paragraph, anyhow); I’m thinking applicability to 
8555’s default/standard/order-then-authz workflow.

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

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Felipe Gasper]

> On Jan 20, 2020, at 10:44 AM, Daniel McCarney  wrote:
> 
>  I thought that was the reason why ACME limits wildcard authz to DNS.
> 
> I don't think RFC 8555 imposes any restrictions on what challenge types can 
> be used for wildcard identifiers. Limiting wildcard DNS identifiers to the 
> DNS-01 challenge is a policy decision by Let's Encrypt.

You’re right; I was misreading it. Sorry for the confusion.

-F


> 
> On Mon, Jan 20, 2020 at 7:32 AM Felipe Gasper  wrote:
> Will this document eventually also describe subdomain authz via the standard 
> ACME workflow?
> 
> Examples:
> 
> 1) Client wants a certificate for example.com & www.example.com. Ideally, if 
> the client authzs example.com, then authz for www.example.com shouldn’t be 
> necessary.
> 
> 2) Now client also wants a separate certificate for sub.example.com and 
> www.sub.example.com. Since example.com was already authorized, this 
> certificate order should not require any additional authz.
> 
> It seems like the above workflow should “just work”, but since it’s closely 
> related to what your document describes I wonder if there’s benefit to 
> mentioning it?
> 
> Also, the linked document states:
> 
>The call flow illustrates the DNS-based proof of ownership mechanism,
>but the subdomain workflow is equally valid for HTTP based proof of
>ownership.
> 
> Can’t I have HTTP access to a base domain’s website without having access to 
> a subdomain’s, though? I thought that was the reason why ACME limits wildcard 
> authz to DNS.
> 
> 
> cheers,
> -Felipe Gasper
> 
> 
> > On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel)  wrote:
> > 
> > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents 
> > the proposed new authorization object field "basedomain"
> > 
> > 
> >> -Original Message-
> >> From: Acme  On Behalf Of Owen Friel (ofriel)
> >> Sent: 06 December 2019 15:41
> >> To: Salz, Rich ; acme@ietf.org
> >> Subject: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call 
> >> for
> >> adoption draft-frield-acme-subdomains)
> >> 
> >> Any comments on this email on how to explicitly distinguish between 
> >> wildcard
> >> and subdomain authorizations, which hopefully addresses ekr's mic comments.
> >> 
> >> 
> >>> -Original Message-
> >>> From: Acme  On Behalf Of Owen Friel (ofriel)
> >>> Sent: 26 November 2019 22:51
> >>> To: Salz, Rich ; acme@ietf.org
> >>> Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
> >>> 
> >>> DNS wildcards are mentioned in 3 sections in RFC8555 (in addition to
> >>> the IANA Considerations section):
> >>> 
> >>> 1. https://tools.ietf.org/html/rfc8555#section-7.1.3 Order Objects:
> >>> 
> >>>   Any identifier of type "dns" in a newOrder request MAY have a
> >>>   wildcard domain name as its value.  A wildcard domain name consists
> >>>   of a single asterisk character followed by a single full stop
> >>>   character ("*.") followed by a domain name as defined for use in the
> >>>   Subject Alternate Name Extension by [RFC5280].  An authorization
> >>>   returned by the server for a wildcard domain name identifier MUST NOT
> >>>   include the asterisk and full stop ("*.") prefix in the authorization
> >>>   identifier value.  The returned authorization MUST include the
> >>>   optional "wildcard" field, with a value of true.
> >>> 
> >>> 2. https://tools.ietf.org/html/rfc8555#section-7.1.4 Authorization 
> >>> Objects:
> >>> 
> >>>   If an
> >>>   authorization object conveys authorization for the base domain of a
> >>>   newOrder DNS identifier containing a wildcard domain name, then the
> >>>   optional authorizations "wildcard" field MUST be present with a value
> >>>   of true.
> >>> 
> >>> 3. https://tools.ietf.org/html/rfc8555#section-7.4.1 Pre-authorization
> >>> 
> >>>   Note that because the identifier in a pre-authorization request is
> >>>   the exact identifier to be included in the authorization object, pre-
> >>>   authorization cannot be used to authorize issuance of certificates
> >>>   containing wildcard domain names.
> >>> 
> >>> For the subdomains use case, it looks as if it makes sense to define a
> >>> "parentdomain" b

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Felipe Gasper]

Will this document eventually also describe subdomain authz via the standard 
ACME workflow?

Examples:

1) Client wants a certificate for example.com & www.example.com. Ideally, if 
the client authzs example.com, then authz for www.example.com shouldn’t be 
necessary.

2) Now client also wants a separate certificate for sub.example.com and 
www.sub.example.com. Since example.com was already authorized, this certificate 
order should not require any additional authz.

It seems like the above workflow should “just work”, but since it’s closely 
related to what your document describes I wonder if there’s benefit to 
mentioning it?

Also, the linked document states:

   The call flow illustrates the DNS-based proof of ownership mechanism,
   but the subdomain workflow is equally valid for HTTP based proof of
   ownership.

Can’t I have HTTP access to a base domain’s website without having access to a 
subdomain’s, though? I thought that was the reason why ACME limits wildcard 
authz to DNS.


cheers,
-Felipe Gasper


> On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel)  wrote:
> 
> FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents the 
> proposed new authorization object field "basedomain"
> 
> 
>> -Original Message-
>> From: Acme  On Behalf Of Owen Friel (ofriel)
>> Sent: 06 December 2019 15:41
>> To: Salz, Rich ; acme@ietf.org
>> Subject: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for
>> adoption draft-frield-acme-subdomains)
>> 
>> Any comments on this email on how to explicitly distinguish between wildcard
>> and subdomain authorizations, which hopefully addresses ekr's mic comments.
>> 
>> 
>>> -Original Message-
>>> From: Acme  On Behalf Of Owen Friel (ofriel)
>>> Sent: 26 November 2019 22:51
>>> To: Salz, Rich ; acme@ietf.org
>>> Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
>>> 
>>> DNS wildcards are mentioned in 3 sections in RFC8555 (in addition to
>>> the IANA Considerations section):
>>> 
>>> 1. https://tools.ietf.org/html/rfc8555#section-7.1.3 Order Objects:
>>> 
>>>   Any identifier of type "dns" in a newOrder request MAY have a
>>>   wildcard domain name as its value.  A wildcard domain name consists
>>>   of a single asterisk character followed by a single full stop
>>>   character ("*.") followed by a domain name as defined for use in the
>>>   Subject Alternate Name Extension by [RFC5280].  An authorization
>>>   returned by the server for a wildcard domain name identifier MUST NOT
>>>   include the asterisk and full stop ("*.") prefix in the authorization
>>>   identifier value.  The returned authorization MUST include the
>>>   optional "wildcard" field, with a value of true.
>>> 
>>> 2. https://tools.ietf.org/html/rfc8555#section-7.1.4 Authorization Objects:
>>> 
>>>   If an
>>>   authorization object conveys authorization for the base domain of a
>>>   newOrder DNS identifier containing a wildcard domain name, then the
>>>   optional authorizations "wildcard" field MUST be present with a value
>>>   of true.
>>> 
>>> 3. https://tools.ietf.org/html/rfc8555#section-7.4.1 Pre-authorization
>>> 
>>>   Note that because the identifier in a pre-authorization request is
>>>   the exact identifier to be included in the authorization object, pre-
>>>   authorization cannot be used to authorize issuance of certificates
>>>   containing wildcard domain names.
>>> 
>>> For the subdomains use case, it looks as if it makes sense to define a
>>> "parentdomain" boolean flag (or "basedomainname" or similar) to be
>>> included in the authorization object for a domain that authorizes
>>> subdomain certs. The relevant CAB guidelines are quoted in
>>> https://tools.ietf.org/html/draft-friel-
>>> acme-subdomains-00#appendix-A.
>>> 
>>> The authorization object would then explicitly indicate that this is a
>>> base domain authorization and thus subdomain certs may be issued off
>>> this. This is conceptually similar to the current "wildcard" flag
>>> which indicates that a wildcard cert may be issued off the identifier
>>> in the object, and would definitively differentiate wildcard vs. base
>>> domain vs. explicit domain authorizations.
>>> 
>>> Item #3 from section 7.4.1 Pre-authorization is already called out as
>>> a substantive change from RFC8555: i.e. the identifier in the
>>> a

[Acme] Rate limits and ACME

[Felipe Gasper]

Hello,


https://community.letsencrypt.org/t/programmatically-distinguishing-rate-limits/97986/14

^^ W/r/t this LE forum thread, what would be involved in proposing an 
ACME extension that provides a reliable, machine-parsable mechanism to 
distinguish one rate limit from another?

My specific use case is: the client I’m building iterates through users 
on a system and requests certificates as needed: e.g., a newly-added domain, 
expired certificate, etc. On a server that has just enabled automatic 
certificate generation (or even has just transferred in a user with hundreds of 
domains) this will easily run up against Let’s Encrypt’s rate limit of 300 
certificate orders per 3-hour timespan.

We could throttle that locally, but the software we publish runs on 
servers that we don’t administer, so if an admin has requested an adjustment to 
that rate limit (as I suspect many will), we’ll either complicate those admins’ 
lives by making them keep a local configuration in sync manually with their LE 
account, or hard-code 300-per-3hrs and deny them the benefit of their raised 
raite limit, which is even worse.

So the solution we’re looking at right now is that we request 
certificates until we hit that specific orders-per-3hrs rate limit, then we 
stop (until the next cron-scheduled run). This way, from the admin’s 
perspective, stuff Just Works™. But that is the *only* rate limit that we want 
to treat that way; since all of the other rate limits concern specific domains, 
we treat those as nonfatal since a rate limit error for one domain likely won’t 
affect others.

The problem is that right now, the only way we have of identifying that 
specific rate limit is to look for the string “too many new orders” in the 
error document’s “detail”. It’s awfully brittle, but there’s apparently no 
other way.

An ACME extension to solve this, then, seems worth proposing. Thoughts?

Thank you!

-Felipe Gasper
Mississauga, Ontario
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] orders, authorizations, and identifiers (oh my)

[Felipe Gasper]

I get that; what I’m looking to confirm--and I’m reasonably sure is the 
case--is that, given a failed order, it’s up to server policy to spell out 
whether a client may reasonably suppose that a 2nd order against a subset of 
the identifiers from the 1st order would pass all of the 2nd set of authzs.

For LE, for example, a client can simply look at the ids of the failed authzs 
and omit those ids from the 2nd order.

Going back to the hypothetical Fred/Jane/Pat CA, though, for a client to know 
how to submit that 2nd order there would need to be some policy external to 
ACME that would indicate the feasibility of such a thing.

Does that sound right?

-F

> On Jul 16, 2019, at 10:24 AM, Daniel McCarney  wrote:
> 
> So if we tell the human operator, “Jane & Pat gave the OK, but Fred said 
> not”, then it’s left to server policy to determine whether that means a 
> hypothetical order with just one or the other domain would pass all authzs?
> 
> No, if the server returned three authorizations all three must be 
> status=valid for the order to be ready for issuance. Earlier drafts had a 
> notion of challenge combinations that would allow something sort of similar 
> but it was dropped.
> 
> Per 7.1.6:
> 
> Order objects are created in the "pending" state. Once all of the 
> authorizations listed in the order object are in the "valid" state, the order 
> transitions to the "ready" state.
> 
> The server policy is exercised by the choice of authorizations/challenges in 
> the pending order, not by the client deciding which authorizations in an 
> order to satisfy.
> 
> On Tue, Jul 16, 2019 at 10:11 AM Felipe Gasper  
> wrote:
> 
> > On Jul 16, 2019, at 9:28 AM, Daniel McCarney  wrote:
> > 
> > So it would be reasonable for this order to contain a single authz … and 
> > would that authz’s identifier be just “example.com”, then? Thus that authz 
> > object would not reference “www”, even though it is that domain’s 
> > corresponding authz object? Or would a client be accountable for 
> > implementing a “best-match authz” lookup to determine which authz 
> > corresponds to a given domain?
> > 
> > Yes, I would expect the order's one authorization to have the identifier 
> > "example.com".
> > 
> > I believe the confusion here is when you say "even though it is that 
> > domain's corresponding authz object" and "Since the order requires 
> > successful authz for both domains".
> > 
> > For the first part, as I understand there is no guaranteed correspondence 
> > between any of the identifiers in the order request and the identifiers in 
> > the returned authorizations. That's what the sentence you quoted on p26 is 
> > meant to convey. The client shouldn't attempt to match authz's to requested 
> > identifiers at all, it should just look at the identifiers in the 
> > authorizations returned by the server and prove control of those 
> > identifiers with the challenges available.
> 
> Thank your for your response. I think I see what’s going on.
> 
> To flesh out a hypothetical a bit more:
> 
> order identifiers: example.com, www.example.com
> 
> authzs:
>   0)
> - identifier: { type: person, value: Fred }
> - challenge: ask if it’s ok
>   1)
> - identifier: { type: person, value: Jane }
> - challenge: ask if it’s ok
>   2)
> - identifier: { type: person, value: Pat }
> - challenge: ask if it’s ok
> 
> So if we tell the human operator, “Jane & Pat gave the OK, but Fred said 
> not”, then it’s left to server policy to determine whether that means a 
> hypothetical order with just one or the other domain would pass all authzs?
> 
> -F
> ___
> 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] orders, authorizations, and identifiers (oh my)

[Felipe Gasper]

Hi all,

The new RFC (8555) states (on p26), for order objects, that a 1:1 
relationship may not exist between an order’s identifiers and its authzs.

Given that each authz object contains exactly 1 identifier, how would 
this play out for CAs that accept authz against a base domain as substitutive 
for authz on a subdomain?

Consider an order to the hypothetical “AwesomeSSL” CA for example.com 
and www.example.com. AwesomeSSL considers authz against “example.com” to 
implicitly demonstrate control over “www.example.com”. Since the order requires 
successful authz for both domains, and (for AwesomeSSL) authz for “example.com” 
suffices for both domains, having a separate authz against “www” is 
superfluous. So it would be reasonable for this order to contain a single authz 
… and would that authz’s identifier be just “example.com”, then? Thus that 
authz object would not reference “www”, even though it is that domain’s 
corresponding authz object? Or would a client be accountable for implementing a 
“best-match authz” lookup to determine which authz corresponds to a given 
domain?

Thank you!

-Felipe Gasper
Mississauga, Ontario
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] DNS challenge server steps missing detail?

[Felipe Gasper]

> On Nov 27, 2018, at 3:32 PM, Danek Duvall  wrote:
> 
> Section 8.4 of the ACME spec says:
> 
>To validate a DNS challenge, the server performs the following steps:
>  1. Compute the SHA-256 digest of the stored key authorization
>  2. Query for TXT records for the validation domain name
>  3. Verify that the contents of one of the TXT records match the
> digest value
> 
> Regarding point 2, it's not explained exactly what is queried for the
> TXT records. I've not gone looking at Boulder code, but from some
> message board postings, it seems like one of the authoritative DNS
> servers for the domain is queried. It'd be nice if the spec could
> include this information, to make writing automated clients easier.

It doesn’t really need to be explained, IMO, because “query for TXT records” 
implies a query against DNS, which in turn implies a query against a nameserver 
that’s authoritative for the domain.

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

[Acme] vestige of certificate GET

[Felipe Gasper]

Hi all,

Draft 16 has this:

-
   An ACME client MAY attempt to fetch the certificate with a GET
   request.  If the server does not allow GET requests for certificate
   resources, then it will return an error as described in 
Section 6.3
.
   On receiving such an error, the client SHOULD fall back to a POST-as-
   GET request.
-

From what I can discern from this list’s most recent posts on the 
topic, I’m under the impression that plain GET for certificates is not to be 
part of the principal ACME spec; should the above, then, be removed?

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

Re: [Acme] example.com is used all over the draft

[Felipe Gasper]

Are “acmeserver.com” or “caserver.com” reserved domains?


What about:

acme-client.example.com

acme-server.example.com

?


-FG

> On Sep 20, 2018, at 8:58 AM, Kas  wrote:
> 
> From section 2 :
> "The CA verifies that the client controls the requested domain name(s) by 
> having the ACME client perform some action(s) that can only be done with 
> control of the domain name(s). For example, the CA might require a client 
> requesting example.com to provision DNS record under example.com or an HTTP 
> resource under http://example.com.;
> 
> I suggest to use "example.com" only for the client mentioned in section 2, 
> while adding another identifier like "acmeserver.com" or "caserver.com" will 
> enhance the readability of all these examples.
> 
> ___
> 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] nomenclature: “POST-as-GET”

[Felipe Gasper]

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

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

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

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

[Felipe Gasper]

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

[Felipe Gasper]

> 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

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

[Felipe Gasper]

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" , 
> "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
>  
> ___
> 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] tls-alpn-01 spec: TLS-SNI history

[Felipe Gasper]

> On Jun 21, 2018, at 10:53 AM, Ilari Liusvaara  
> wrote:
> 
> On Thu, Jun 21, 2018 at 09:53:07AM -0400, Felipe Gasper wrote:
> 
>> I would guess that the reason why Apache didn’t get much grief over
>> TLS-SNI is that many--most?--hosting services require a certificate
>> to match one or more domains on the associated Apache virtual host.
>> But that’s not universal by any stretch.
> 
> Also, getting the default virtual host on most hosting services is
> probably not easy. And without default vhost, you can only answer to
> names you have.

At least one entity on every IP address has it. And it’s trivial for anyone to 
check to see who it is.

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

[Acme] tls-alpn-01 spec: TLS-SNI history

[Felipe Gasper]

Having read over the history of TLS-SNI as reported in the draft spec, I feel 
like it might be prudent to mention that a significant part of the failure of 
TLS-SNI was Apache httpd and its (nonsensical, IMO) behavior of sending 
certificates for domains that don’t match the SNI request.

The write-up mentions “service providers”; for what it’s worth, I feel like a 
more complete and accurate picture would also indicate that “popular server 
software” (e.g., Apache … maybe others?) will happily serve up a certificate 
that has no connection with the SNI request, and that this is also a 
significant part of why TLS-SNI did not work.

-Felipe Gasper
Mississauga, ON
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] TLS-ALPN implementation

[Felipe Gasper]

Update: I got it working. Seems to have been a server implementation bug on my 
end.

Sorry for the noise!

-F

> On Jun 17, 2018, at 8:01 PM, Felipe Gasper  wrote:
> 
> I’ve been playing with this. As far as I can tell I have it set up correctly, 
> but it’s not working.
> 
> In response to this challenge:
> 
> https://acme-staging-v02.api.letsencrypt.org/acme/challenge/leSSBO7cbljpzjZqGhzqSRm8lphqe1RX_jI3Mx8eEeU/136484133
> 
> … I set up this certificate:
> 
> -BEGIN CERTIFICATE-
> MIIDBDCCAe6gAwIBAgIBADALBgkqhkiG9w0BAQswGzEZMBcGA1UEAwwQY29icmFzc2x0ZXN0Lm9y
> ZzAiGA8yMDE4MDYxNTIzNTg0MFoYDzIwMTgwNjE5MjM1ODQwWjAbMRkwFwYDVQQDDBBjb2JyYXNz
> bHRlc3Qub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyZ7S6Ihzojn36nARYbGY
> 7ZKQCZHUje/yjeOaSFNzgFtIBSjdlEyYZz5DkAv92ciqH7OJ4InuJFoFT0OwbVHxf0na/fA52XwJ
> RjNXWY7p1Qw0ZKqAIyypjcMS4ucnLvPYjGM+xNWtDnLP9Odr/8jNdQDIAehJ4TS11RlX2cv28hwi
> BqUcj1whdPFsdUKbyUCzdpKP7BS3UdL8Z7fkc+WxiTQMCaA8/IO/i+1s5ptJSFEZPVU/ZVVEVZrC
> EFArImmpWowoCiTxtQdWtS0bHY5RlB5IrGal4ZUgKtKe94AewvpPdy4CH8jrbQeBLcssHoaTdLgT
> VsxTAFSRnHcuZ8wfYwIDAQABo1MwUTAbBgNVHREEFDASghBjb2JyYXNzbHRlc3Qub3JnMDIGCSsG
> AQUFBwEeAQEB/wQiBCD/wpQDz3i0tjgUXgWWWyb0tP+DGo99DuOt0y1qokwGDjALBgkqhkiG9w0B
> AQsDggEBACOzSSZJRUu39glasoTdpEQWwgbxqVoQ5/3Ly8P06C4xavEdgQUrsHOubr6Y4HEFpLpS
> U/0tsVmnL3c3AVL6NXY7ffTVRpLYwGA+5oq5tIT/Yp6gqvO0D5JC+y/wfc7OpKU+x7N2NHlBJtPp
> mTUYm6KIwYz6qcHheV4vjZPZzZ1M4FFGCKgFItD+9mIoUyH13oKfkJzAPsALJqZFJ279r+4eT3N2
> yGX3TZPLFUkaN4rNwSY4GwBVbIUiZ1Tgn5Z/TJTMQYlbr3pMwOe8V2YPO4sXCu2CcT53PrB0T4tH
> c0/v1a+kaYYCz3aAgrA9/5VAmnK89h+U/qfvEHSGBzK3w8U=
> -END CERTIFICATE-
> 
> … which has this key:
> 
> -BEGIN RSA PRIVATE KEY-
> MIIEpQIBAAKCAQEAyZ7S6Ihzojn36nARYbGY7ZKQCZHUje/yjeOaSFNzgFtIBSjd
> lEyYZz5DkAv92ciqH7OJ4InuJFoFT0OwbVHxf0na/fA52XwJRjNXWY7p1Qw0ZKqA
> IyypjcMS4ucnLvPYjGM+xNWtDnLP9Odr/8jNdQDIAehJ4TS11RlX2cv28hwiBqUc
> j1whdPFsdUKbyUCzdpKP7BS3UdL8Z7fkc+WxiTQMCaA8/IO/i+1s5ptJSFEZPVU/
> ZVVEVZrCEFArImmpWowoCiTxtQdWtS0bHY5RlB5IrGal4ZUgKtKe94AewvpPdy4C
> H8jrbQeBLcssHoaTdLgTVsxTAFSRnHcuZ8wfYwIDAQABAoIBAQCTwuBTJt2IAO/e
> Uq+KZ3vqcMU7HjMmqrmanzmM1AwL/9nyXha1/sSatZkSUpeCKnvzq8LaWnu7DHZj
> tvnvxGQ2o0vpW0sqRqsNVccojYJ1bvJe7E3oeWzxxgtrW3juAiusB3gTDX483ovl
> sk0GMoXQv/fU3gZ3FAhG2sH1jnO2zvWhvv/z3qyVxcnTFVvmr+RV9xH6ykXQ8qGR
> K+PyqH8IWDwBq3RGofiFS8a0TYapiQp7cFaC0wyZVY+1e1CPwm1A7Koqv3xZBxdH
> /puRtbPnxkFrpdYEr65tAoxHKwAt7ju+DQp7RhPlrS014cDgq2qJ8l73ivhAbX5M
> sS9xzhJBAoGBAPM2KfCfNrNG7ttkYsg21OQ99gxWcTTava58o2Ei1AZyvydzmFam
> uekwJzcLhTRVZg7t5utKRxtbN8DmVJli7132lrxUkn3kzPJGYacSyoSn+XH4lRb0
> E0SAgYUd1WiDazNfcNrYLVzriOVnyiKvWP+yYlUSJAfePCADug5eSsrxAoGBANQ4
> zqbX4XW0DAN5n7ZBtyCqEag2ihqGDCfEZdp9w5iZSm6nqlZRZ+XRxKzijsTt42Ap
> 1CnwbaURswYNJw/ZnxZhuHNKqiz8T2mFwcl4OcQhduHioXDaZT2dy/jTu6ov1VQ0
> mhx1SGRIakkp1yvElZzFLSJoop+bNISwDhDaHQeTAoGBAIfUEx4wPQNotRNQAB8j
> CEikFhsT18uV8mNVdoVURyeGxB0LYOPb325NF0mVpIHyw7nIwbNcW1P64KtZt5um
> dlp60fpCHUI0GwWfqv/87Z+ilBxDoTgdffk+75bhb4McCi25urRuEP+ZB25fRbOT
> TFgZTvOF2xuN0PRsQGev34NxAoGBAK84D/dVOsOR2nFsE9/JNkfz4ww9q5zmnFah
> I29YcwwlVH00VcFbCSuJHJeZn0MdHqShJJlT91NY37TZWy0NAvrZyA740LS/xVlc
> pHmRmDBFaQBru9uPlhNfm69gMgv73mjd3XgtpY2W9Jpfv1ZVwyli6zcDqXGaFayQ
> J6zmSR2dAoGAT+LDNH98ToNrBhKYinM1FJ36jQ0/IJGbTUE67iw9KFYkAsk2/ZMm
> IYbKnkfhoPB/bZlMUYCEA/oJZlaOPgtDEGiSd4bv+x3nkyv+hO2y2YZn2W/8kPSk
> wsTjrSCVrzxb7j7r1R9v56aNdZcp2srHK6W+rBME8OuH/lq509v0A48=
> -END RSA PRIVATE KEY-
> 
> It’s telling me “urn:ietf:params:acme:error:connection” (Connection reset by 
> peer) as the challenge’s failure.
> 
> My server-side debugging says that the handshake succeeds … is there 
> something amiss in the certificate?
> 
> 
> -Felipe
> 
> 
>> On Jun 15, 2018, at 2:39 PM, Roland Bracewell Shoemaker 
>>  wrote:
>> 
>> Let’s Encrypt has deployed an implementation[0] of the 
>> draft-ietf-acme-tls-alpn-01 validation method on our staging environment[1]. 
>> If anyone has a chance to test it out and runs into 
>> implementation/specification issues we’d love to hear about them!
>> 
>> [0] 
>> https://github.com/letsencrypt/boulder/blob/2dadd5e09a8228342aa86e8fa4c8d887a82aa4ac/va/va.go#L701-L768
>> [1] https://acme-staging.api.letsencrypt.org/
>> ___
>> 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] TLS-ALPN implementation

[Felipe Gasper]

I’ve been playing with this. As far as I can tell I have it set up correctly, 
but it’s not working.

In response to this challenge:

https://acme-staging-v02.api.letsencrypt.org/acme/challenge/leSSBO7cbljpzjZqGhzqSRm8lphqe1RX_jI3Mx8eEeU/136484133

… I set up this certificate:

-BEGIN CERTIFICATE-
MIIDBDCCAe6gAwIBAgIBADALBgkqhkiG9w0BAQswGzEZMBcGA1UEAwwQY29icmFzc2x0ZXN0Lm9y
ZzAiGA8yMDE4MDYxNTIzNTg0MFoYDzIwMTgwNjE5MjM1ODQwWjAbMRkwFwYDVQQDDBBjb2JyYXNz
bHRlc3Qub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyZ7S6Ihzojn36nARYbGY
7ZKQCZHUje/yjeOaSFNzgFtIBSjdlEyYZz5DkAv92ciqH7OJ4InuJFoFT0OwbVHxf0na/fA52XwJ
RjNXWY7p1Qw0ZKqAIyypjcMS4ucnLvPYjGM+xNWtDnLP9Odr/8jNdQDIAehJ4TS11RlX2cv28hwi
BqUcj1whdPFsdUKbyUCzdpKP7BS3UdL8Z7fkc+WxiTQMCaA8/IO/i+1s5ptJSFEZPVU/ZVVEVZrC
EFArImmpWowoCiTxtQdWtS0bHY5RlB5IrGal4ZUgKtKe94AewvpPdy4CH8jrbQeBLcssHoaTdLgT
VsxTAFSRnHcuZ8wfYwIDAQABo1MwUTAbBgNVHREEFDASghBjb2JyYXNzbHRlc3Qub3JnMDIGCSsG
AQUFBwEeAQEB/wQiBCD/wpQDz3i0tjgUXgWWWyb0tP+DGo99DuOt0y1qokwGDjALBgkqhkiG9w0B
AQsDggEBACOzSSZJRUu39glasoTdpEQWwgbxqVoQ5/3Ly8P06C4xavEdgQUrsHOubr6Y4HEFpLpS
U/0tsVmnL3c3AVL6NXY7ffTVRpLYwGA+5oq5tIT/Yp6gqvO0D5JC+y/wfc7OpKU+x7N2NHlBJtPp
mTUYm6KIwYz6qcHheV4vjZPZzZ1M4FFGCKgFItD+9mIoUyH13oKfkJzAPsALJqZFJ279r+4eT3N2
yGX3TZPLFUkaN4rNwSY4GwBVbIUiZ1Tgn5Z/TJTMQYlbr3pMwOe8V2YPO4sXCu2CcT53PrB0T4tH
c0/v1a+kaYYCz3aAgrA9/5VAmnK89h+U/qfvEHSGBzK3w8U=
-END CERTIFICATE-

… which has this key:

-BEGIN RSA PRIVATE KEY-
MIIEpQIBAAKCAQEAyZ7S6Ihzojn36nARYbGY7ZKQCZHUje/yjeOaSFNzgFtIBSjd
lEyYZz5DkAv92ciqH7OJ4InuJFoFT0OwbVHxf0na/fA52XwJRjNXWY7p1Qw0ZKqA
IyypjcMS4ucnLvPYjGM+xNWtDnLP9Odr/8jNdQDIAehJ4TS11RlX2cv28hwiBqUc
j1whdPFsdUKbyUCzdpKP7BS3UdL8Z7fkc+WxiTQMCaA8/IO/i+1s5ptJSFEZPVU/
ZVVEVZrCEFArImmpWowoCiTxtQdWtS0bHY5RlB5IrGal4ZUgKtKe94AewvpPdy4C
H8jrbQeBLcssHoaTdLgTVsxTAFSRnHcuZ8wfYwIDAQABAoIBAQCTwuBTJt2IAO/e
Uq+KZ3vqcMU7HjMmqrmanzmM1AwL/9nyXha1/sSatZkSUpeCKnvzq8LaWnu7DHZj
tvnvxGQ2o0vpW0sqRqsNVccojYJ1bvJe7E3oeWzxxgtrW3juAiusB3gTDX483ovl
sk0GMoXQv/fU3gZ3FAhG2sH1jnO2zvWhvv/z3qyVxcnTFVvmr+RV9xH6ykXQ8qGR
K+PyqH8IWDwBq3RGofiFS8a0TYapiQp7cFaC0wyZVY+1e1CPwm1A7Koqv3xZBxdH
/puRtbPnxkFrpdYEr65tAoxHKwAt7ju+DQp7RhPlrS014cDgq2qJ8l73ivhAbX5M
sS9xzhJBAoGBAPM2KfCfNrNG7ttkYsg21OQ99gxWcTTava58o2Ei1AZyvydzmFam
uekwJzcLhTRVZg7t5utKRxtbN8DmVJli7132lrxUkn3kzPJGYacSyoSn+XH4lRb0
E0SAgYUd1WiDazNfcNrYLVzriOVnyiKvWP+yYlUSJAfePCADug5eSsrxAoGBANQ4
zqbX4XW0DAN5n7ZBtyCqEag2ihqGDCfEZdp9w5iZSm6nqlZRZ+XRxKzijsTt42Ap
1CnwbaURswYNJw/ZnxZhuHNKqiz8T2mFwcl4OcQhduHioXDaZT2dy/jTu6ov1VQ0
mhx1SGRIakkp1yvElZzFLSJoop+bNISwDhDaHQeTAoGBAIfUEx4wPQNotRNQAB8j
CEikFhsT18uV8mNVdoVURyeGxB0LYOPb325NF0mVpIHyw7nIwbNcW1P64KtZt5um
dlp60fpCHUI0GwWfqv/87Z+ilBxDoTgdffk+75bhb4McCi25urRuEP+ZB25fRbOT
TFgZTvOF2xuN0PRsQGev34NxAoGBAK84D/dVOsOR2nFsE9/JNkfz4ww9q5zmnFah
I29YcwwlVH00VcFbCSuJHJeZn0MdHqShJJlT91NY37TZWy0NAvrZyA740LS/xVlc
pHmRmDBFaQBru9uPlhNfm69gMgv73mjd3XgtpY2W9Jpfv1ZVwyli6zcDqXGaFayQ
J6zmSR2dAoGAT+LDNH98ToNrBhKYinM1FJ36jQ0/IJGbTUE67iw9KFYkAsk2/ZMm
IYbKnkfhoPB/bZlMUYCEA/oJZlaOPgtDEGiSd4bv+x3nkyv+hO2y2YZn2W/8kPSk
wsTjrSCVrzxb7j7r1R9v56aNdZcp2srHK6W+rBME8OuH/lq509v0A48=
-END RSA PRIVATE KEY-

It’s telling me “urn:ietf:params:acme:error:connection” (Connection reset by 
peer) as the challenge’s failure.

My server-side debugging says that the handshake succeeds … is there something 
amiss in the certificate?


-Felipe


> On Jun 15, 2018, at 2:39 PM, Roland Bracewell Shoemaker 
>  wrote:
> 
> Let’s Encrypt has deployed an implementation[0] of the 
> draft-ietf-acme-tls-alpn-01 validation method on our staging environment[1]. 
> If anyone has a chance to test it out and runs into 
> implementation/specification issues we’d love to hear about them!
> 
> [0] 
> https://github.com/letsencrypt/boulder/blob/2dadd5e09a8228342aa86e8fa4c8d887a82aa4ac/va/va.go#L701-L768
> [1] https://acme-staging.api.letsencrypt.org/
> ___
> 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] missing comma

[Felipe Gasper]

I’m not sure what the best forum is to report minor typographical issues, but:

6.2:

  *  "jwk" (JSON Web Key, for all requests not signed using an
 existing account, e.g. newAccount)

^^ Everyplace else in the spec puts a comma after “e.g.”, so I would think 
there should be one here as well.

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

[Acme] ACME and Authz domain name

[Felipe Gasper]

The latest CAB forum guidelines stipulate that:

1) Demonstration of control of a CNAME for the given FQDN can suffice for 
authorization.

2) “The CA may prune zero or more labels from left to right until encountering 
a Base Domain Name and may use any one of the intermediate values for the 
purpose of domain validation.”

-

ACME doesn’t seem to build in the flexibility to make use of either of these 
options. Was this by design?

I know in the case of HTTP-based validation, Let’s Encrypt, at least, 
consciously decided not to consider demonstration of control of a parent domain 
to imply control of a subdomain (with wildcards, anyhow), but at least for 
DNS-based DCV should demonstration of control of “example.com” not imply 
control of “foo.bar.example.com” for the purposes of authorization?

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

Re: [Acme] Concerning alternative formats …

[Felipe Gasper]

> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman  wrote:
> 
> Especially with CT logging being a pragmatic requirement, time-to-delivery 
> for certificates is likely to increase (slightly) rather than decrease.

Quick point: the alleviation of polling would go for authz status as well as to 
certificate delivery.

A certificate order that has 10 domains needs to poll for the status of all 10 
of those domains’ authorizations as well as the certificate issuance. 
“ACME/bidi” would remove all 11 of those needs to poll.

Thanks for those who have given this suggestion their consideration. I don’t 
mean to “gum up the gears” for the main ACME work, but as I’ve been writing 
ACME clients the polling stuff has stuck out to me like a sore thumb.

It’s worth noting, too, that concerns about overhead may be alleviated if we do 
get a usable WebSocket-over-HTTP/2 implementation. Or, maybe someone will 
expose an SCTP endpoint, or a raw TCP endpoint that implements a simple 
message-boundary layer. I think the question of pure-message, bidirectional 
transport is more relevant than a specific transport implementation.

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

Re: [Acme] Concerning alternative formats …

[Felipe Gasper]

> On Mar 5, 2018, at 9:35 AM, Jörn Heissler <acme-sp...@joern.heissler.de> 
> wrote:
> 
> On Mon, Mar 05, 2018 at 09:11:02 -0500, Felipe Gasper wrote:
>> Regarding alternative formats, I think ACME over WebSocket would be a great 
>> thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
>> certificate unless the connection dropped. The server could send the 
>> certificate as soon as it’s ready. A simple handshake at the start could 
>> take the place of JWS, too.
> 
> Moving to websocket would mean having to specify a new websocket based
> protocol and reimplementing all servers/clients.

I would think “ACME/bidi” could live alongside ACME/HTTP. The bidirectional 
variant could be described in a separate RFC that gives the differences--which 
would basically just be how to translate the HTTP-specific parts of ACME/HTTP 
to “pure messages”.

WebSocket wouldn’t necessarily be the only persistent-connection format; any 
reliable, message-oriented protocol (e.g., SCTP or WAMP “RawSocket”) could work.

> You'd also need to consider MitM (e.g. by CDN or expensive enterprise MitM
> appliances). Doing a handshake at the beginning won't be enough to keep
> those from taking over a session after the handshake.
> 
> If you wanted to eliminate the polling, it would be possible to change
> the finalize endpoint to return the certificate directly, even if it
> takes a while until the HTTP response is sent.

This would alleviate the polling for the certificate but not for authz status. 
If I have an Order with, say, 5 authzs, I’ll still need to poll for the state 
of those.

A transport layer that allows asynchronous server-to-client communication would 
facilitate quicker feedback to the client and a smoother user experience 
overall. 

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

[Acme] Concerning alternative formats …

[Felipe Gasper]

For what it’s worth:

Regarding alternative formats, I think ACME over WebSocket would be a great 
thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
certificate unless the connection dropped. The server could send the 
certificate as soon as it’s ready. A simple handshake at the start could take 
the place of JWS, too.

-F

> On Mar 5, 2018, at 12:02 AM, Martin Thomson  wrote:
> 
> Unless you believe that an alternative format is ever desirable.  CBOR
> for version 2 might be a terrible idea, but I know the IETF well
> enough not to rule that out entirely.
> 
> On Mon, Mar 5, 2018 at 3:38 PM, Richard Barnes  wrote:
>> I also note that there's no issue with Accept if we require the use of the
>> Flattened JSON serialization.
>> 
>> https://i.imgflip.com/25r2ui.jpg
>> 
>> https://github.com/ietf-wg-acme/acme/pull/410
>> 
>> On Sun, Mar 4, 2018 at 6:28 PM, Martin Thomson 
>> wrote:
>>> 
>>> That's a bit silly.  I'll follow-up with httpbis.  I think that's an
>>> error, though probably only an error of omission.  7694 was so fixated
>>> on solving the content-coding issue, it neglected the obvious
>>> accompanying fix.
>>> 
>>> On Mon, Mar 5, 2018 at 9:38 AM, Richard Barnes  wrote:
 How about Accept?  It looks like 7694 gives the server a way to specify
 encodings, but not the content type.  But 7231 says that Accept only
 replies
 to response media types.
 
 On Sun, Mar 4, 2018 at 5:33 PM, Martin Thomson
 
 wrote:
> 
> 415 is for the case where a client provides bad request content, so
> yes.
> See rfc7694 for details.
> 
> 406 is for failed conneg. Not something you expect to see much here.
> 
> 
> On 5 Mar. 2018 09:25, "Richard Barnes"  wrote:
> 
> The lengths of the emails in this thread illustrate the complexity risk
> here :)
> 
> In the interest of simplicity, I would really like to stick to
> Flattened
> JSON unless someone has **strong** objections.
> 
> Logan, to your point about library compatibility, two notes: (1) it's
> OK
> if we front-run libraries a little.  It's not hard for libraries to
> upgrade;
> this is only formatting, no crypto changes needed.  (2) Empirically,
> this
> must not be too big a blocker for people, since as Jacob notes, Let's
> Encrypt only supports Flattened JSON right now and they've got a bunch
> of
> clients talking to them.
> 
> As far as headers / response codes: You're correct that 406 is wrong /
> 415
> is right.  But ISTM that Accept is still the right header to say what
> is
> right.  So the server should return 415+Accept.  Copying Thomson to
> check
> our work here.
> 
> --Richard
> 
> On Sun, Mar 4, 2018 at 10:43 AM, Logan Widick 
> wrote:
>> 
>> How about this: Specify a default format (either "application/jose"
>> for
>> Compact Serialization, or "application/jose+json" with Flattened
>> Serialization - I have no preference which one), with optional support
>> for
>> other formats if needed? Even with JOSE libraries that don't support
>> all
>> serializations and/or don't provide control over which serialization
>> is
>> used, a programmer would at least need to know (or experimentally find
>> out)
>> if a JSON serialization or if the compact one is being produced. If a
>> JSON
>> serialization is selected as the default, a programmer should be able
>> to
>> convert between the two JSON serializations easily as needed before
>> and/or
>> after using a JOSE library. If a JSON format is declared as the
>> default but
>> the JOSE library only has the compact one, or vice-versa, conversion
>> before
>> and/or after the JOSE library would be more complex but should still
>> be
>> doable with guidance.
>> 
>> The directory meta item could be defined as something like:
>> 
>> supportedSerializations: An array of supported serialization formats
>> as
>> described in {{jws-serialization-formats}}. If this is not specified,
>> assume
>> that the server only supports [insert selected default here].
>> 
>> Then, the JWS Serialization Formats section could be changed to
>> something
>> like the following:
>> 
>> The JSON Web Signature (JWS) specification {{!RFC7515}} contains
>> multiple
>> JWS serialization formats. When sending an ACME request with a
>> non-empty
>> body, an ACME client implementation SHOULD use the HTTP Content-Type
>> {{!RFC7231}} header to indicate which JWS serialization format is used
>> for
>> encapsulating the ACME request payload.
>> 
>> Each serialization format defined for use in ACME is described 

Re: [Acme] Optional "Wildcard" authorization field

[Felipe Gasper]

One (fairly) obvious use of the “wildcard” flag is for status reporting without 
the context of the original newOrder. The client can thus more easily say:

Authorization for “*.example.com”: $message

… without having to correlate the authz object with the order.

-FG

> On Mar 2, 2018, at 12:32 PM, Daniel McCarney  wrote:
> 
> Richard: That's up to the client and the situation. In the linked Certbot 
> issues there were questions about error output/UX. In this case if the client 
> saw an error attached to an authorization with the identifier `{ "type": 
> "dns", "value": "example.com"}` and the authorization had `wildcard: true` 
> the client could say "Failed to authorize *.example.com: blah blah blah" or 
> otherwise use the knowledge to inform their actions (whatever they may be).
> 
> In general I think there will be reason for client developers will want to 
> have a standardized way of understanding if an authorization corresponds to a 
> wildcard identifier or not. I'm hopeful some client developers will chime in 
> with more concrete examples, I'm a server-side grunt.
> 
> - Daniel / cpu
> 
> On Fri, Mar 2, 2018 at 12:29 PM, Richard Barnes  wrote:
> Daniel: I don't have a strong objection here, but could you elaborate what 
> the client is expected to do differently based on this flag?
> 
> On Fri, Mar 2, 2018 at 12:22 PM, Daniel McCarney  wrote:
> Hi folks,
> 
> There is a slight disconnect with the current specification between 
> identifiers in newOrder/newAuthz requests and identifiers in authorization 
> objects. The former is allowed to include wildcard domains in the value of 
> DNS type identifiers while the latter is forbidden. 
> 
> Let's Encrypt's implementation of ACME wildcard issuance guessed this might 
> lead to confusion and introduced a non-standardized "Wildcard" boolean field 
> in authorization objects. If true, then the identifier value in the 
> authorization identifier is known to be the base domain corresponding to a 
> wildcard identifier from the newOrder/newAuthz request.
> 
> I think it would be beneficial to the entire ecosystem if this optional 
> "wildcard" authz field could be standardized so I've sent a small PR: 
> https://github.com/ietf-wg-acme/acme/pull/402 Both Certbot and ACME4J have 
> independently bumped into this disconnect, which helps justify the need.
> 
> - Daniel / cpu
> 
> 
> 
> 
> ___
> 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] Specify which JWS serialization is used

[Felipe Gasper]

Could there be some way of using a header like “Accept” for a server to 
indicate whether it supports jose, jose+json, or both?

-F

> On Mar 2, 2018, at 9:50 AM, Richard Barnes  wrote:
> 
> Hey all,
> 
> I merged #395 last night (thanks, Logan!).  While I was reviewing that, I 
> noticed that we need to cover the case where the client sends an encoding 
> that the server doesn't understand.  So I've posted a follow-on that adds an 
> error code and requires its usage.  LMK if you have any objections, otherwise 
> I'll merge before submission on Monday.
> 
> https://github.com/ietf-wg-acme/acme/pull/398
> 
> Thanks,
> --Richard
> 
> On Mon, Feb 12, 2018 at 2:37 PM, Logan Widick  wrote:
> I've created a new pull request 
> (https://github.com/ietf-wg-acme/acme/pull/395) to partially address the lack 
> of serialization format specification. This pull request requires use of the 
> Content-Type HTTP header to indicate the serialization format of the 
> outermost JWS. The pull request also includes restrictions on the 
> serializations (no detached payload, no unencoded payload, no unprotected 
> header, etc.). In addition, the pull request bans multiple signatures, 
> regardless of the serialization used. The use of the Content-Type header, and 
> the list of currently possible serializations, is mentioned in its own 
> subsection of "Message Transport". 
> 
> The pull request does not contain advice on how to convert different 
> serialization formats before and/or after use with a pre-existing JWS 
> library. I have started on a separate conversion guide 
> (https://github.com/u2/jwe-jws-serialization-conversion-guide) for that 
> purpose. 
> 
> The pull request does not specify how a "nested" JWS should be serialized. 
> However, I have included an outline of one possible approach to this in the 
> pull request's description. 
> 
> Please let me know what you think about the pull request  
> (https://github.com/ietf-wg-acme/acme/pull/395), and the separate conversion 
> guide (https://github.com/u2/jwe-jws-serialization-conversion-guide)
> 
> Logan
> 
> On Fri, Jan 12, 2018 at 6:08 PM, Logan Widick  wrote:
> Last night, I briefly surveyed the listings of JWT implementations on jwt.io. 
> I could find only a small handful that appeared to support all 
> serializations, and even fewer that appeared to give programmers control over 
> what serialization was produced. Thus, assuming jwt.io is a sufficiently 
> accurate and comprehensive listing of implementations of all and/or part of 
> the JOSE specs, the developers of many ACME client and server implementations 
> may find themselves needing to convert between serializations before and/or 
> after using JOSE libraries. Such conversion processes, if needed, should be 
> well-documented somewhere. 
> 
> I've started on a very rough draft of a possible JWS and JWE serialization 
> conversion guide at 
> https://github.com/u2/jwe-jws-serialization-conversion-guide. I made the 
> conversion guide draft by copying a few items from the ACME GitHub repository 
> (the Markdown file, the makefile, and the .gitignore), replacing the text 
> from the Markdown file, and renaming the Markdown file. I designed the 
> conversion guide draft to be non-ACME specific, so I've tried to include 
> things like unencoded JWS payloads, JWEs, multiple signatures, detached 
> payloads, etc. If you have any changes or suggestions, please let me know. 
> 
> Logan
> 
> On Fri, Jan 5, 2018 at 7:11 PM, Jörn Heissler  
> wrote:
> On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote:
> > What do you think of the following:
> 
> > Content type application/jose+json: MUST be supported. If used, the JWS
> > will need to be in the Flattened or General serialization. Flattened MUST
> > be supported; General MAY be supported.
> 
> > Content type application/jose: MAY be supported. If used, the JWS MUST use
> > the Compact serialization. Or should this content type not be allowed?
> 
> Agreed. I wouldn't disallow "compact". And it could be clarified:
> 
> The server SHOULD use the "Content-Type" HTTP header as an indication
> for the request format.
> 
> > JWS Unprotected Header: Not currently used in ACME. Should this be banned
> > in ACME?
> 
> I don't see much sense in those. But some client implementations might
> automatically add an unprotected header like e.g. "cty".
> Maybe with a "SHOULD NOT"?
> 
> > Multiple signatures: MAY be supported.
> 
> > Should messages signed by both MAC keys and private keys be allowed?
> 
> This is already forbidden.
> 
> > What about Key IDs not issued by the CA?
> > Or are multiple signatures more trouble than they're worth to the point of
> > banning them entirely?
> >
> > Multiple signatures on messages that need to be signed by account key: At
> > least one signature MUST be from the account key
> >
> > Multiple signatures on revokeCert: Should 

Re: [Acme] -09 draft: Challenge objects?

[Felipe Gasper]

Hi Daniel,

It definitely helps, yes. Would it be sensible to move the common list 
of parameters there as well, for parity with how the other object types are 
described?

-Felipe

> On Mar 2, 2018, at 9:34 AM, Daniel McCarney <c...@letsencrypt.org> wrote:
> 
> Hi Felipe,
> 
> Does this PR from Richard Barnes address your feedback? 
> https://github.com/ietf-wg-acme/acme/pull/399
> 
> Thanks!
> 
> On Sat, Jan 13, 2018 at 8:50 AM, Felipe Gasper <fel...@felipegasper.com> 
> wrote:
> Hello,
> 
> I’ve been looking over the -09 draft and have created a Perl client 
> module against Pebble as well as LE’s new testing endpoint.
> 
> I’m curious about whether the specification intends to define 
> Challenge objects. They appear to exist, of course, but they’re not defined 
> as objects per se in section 7.1 of the draft.
> 
> Thank you!
> 
> -Felipe Gasper
> Mississauga, ON
> ___
> 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] -09 draft: Challenge objects?

[Felipe Gasper]

Hello,

I’ve been looking over the -09 draft and have created a Perl client 
module against Pebble as well as LE’s new testing endpoint.

I’m curious about whether the specification intends to define Challenge 
objects. They appear to exist, of course, but they’re not defined as objects 
per se in section 7.1 of the draft.

Thank you!

-Felipe Gasper
Mississauga, ON
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme