Re: [Acme] High level comments on draft-barnes-acme (the GitHub version)

[Martin Thomson]

On 25 March 2015 at 17:21, Jacob Hoffman-Andrews j...@eff.org wrote:
 This seems like a big deal, no? That is, since SNI is one of the few
 things not protected in the TLS handshake, it does seem spoofable. If
 there's not something I'm missing, it seems like the proposal should
 just drop DVSNI altogether.

 An attacker who fully controls the network is explicitly not part of the
 threat model for any Domain Validation. None of the available techniques
 for DV, whether they involve fetching a file, sending an email, or doing
 a TLS handshake can fully mitigate a network attacker.

It has been suggested that some measure of network control can be
mitigated by originating the validation requests from multiple network
locations.  That would be down to CA policy though.

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

Re: [Acme] Want client-defined callback port

[Martin Thomson]

On 22 April 2015 at 19:33, Peter Eckersley p...@eff.org wrote:
 Perhaps those policies can be stored out of band, or perhaps we can add
 a separate REST API endpoint where clients ask what ports the server
 considers acceptable for DV Challenges.


Or just pick port 100 (or another that isn't already taken) and say
443 or _that_.  I can't imagine you would need to have many numbers
before you found one that was free.

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

Re: [Acme] Proposed ACME Charter Language

[Martin Thomson]

On 13 May 2015 at 16:39, Salz, Rich rs...@akamai.com wrote:
 I'd prefer if we just recorded issues there, but discussed them in the 
 mailing list.

I'd go further and treat that as a private enterprise.  They might
help track our issues for us, but until we have an official tracker,
it has no real standing.

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

Re: [Acme] Current Charter language

[Martin Thomson]

On 15 May 2015 at 11:09, Salz, Rich rs...@akamai.com wrote:
 Any other obvious edits needed?

 LGTM


Shipping is a feature.

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

Re: [Acme] draft-ietf-acme

[Martin Thomson]

On 12 August 2015 at 11:18, Tony Arcieri basc...@gmail.com wrote:
 It represents a conceptual misuse of digital signatures, and seems to me
 like a very fundamental design flaw which is easily addressed. I'm confused
 why you don't want to address it before adopting the draft.

If we set a precondition on adoption that said no open issues or
maybe even no open issues that I think are serious we would never
ever adopt anything.

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

[Acme] PR to implement Ted's suggestion

[Martin Thomson]

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

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

Re: [Acme] Open issues on GitHub

[Martin Thomson]

Others might disagree, but those look largely editorial to my reading.
My guess is that the editors are busy and will address your concerns
when they are able.

If you think that there is a technical deficiency with the
specification, definitely bring it here.  Opening an issue as well
helps with tracking, but it isn't necessary.

On 12 November 2015 at 14:31, Niklas Keller  wrote:
> Hello,
>
> how are issues on GitHub handled? Should they always be brought to the list?
> Seems like there isn't that much activity there.
>
> I opened a few while implementing my PHP client with no answers during the
> last few days.
>
> https://github.com/ietf-wg-acme/acme/issues/31
> https://github.com/ietf-wg-acme/acme/issues/33
> https://github.com/ietf-wg-acme/acme/issues/34
>
> Regards, Niklas
>
> ___
> 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] Content-Type and file extensions for HTTP01 challenges

[Martin Thomson]

On 12 November 2015 at 16:44, Peter Eckersley  wrote:
> But is 3 the best answer?

Of those presented, I think so.  I know that this isn't a great answer
(it's bad already, so bad must be OK), but being able to drop things
into .well-known opens a raft of other interesting attacks.

More seriously, I think that the other options all have deployment
complications that far outweigh the marginal benefit that extra
checking might provide.

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

Re: [Acme] Adding an Extension to http-01 Answers

[Martin Thomson]

At the meeting, we concluded that you would not have to include a
specific MIME media type in responses.  Serializing the octets of the
base64-encoded string would be enough.  Does that make your problem
easier?

On 10 November 2015 at 16:58, Bryan Livingston
 wrote:
> I'm implementing an ACME client for windows and have run into some trouble
> with IIS handling extensionless static files.
>
> I've described the problem on these two links.
>
> https://github.com/ebekker/letsencrypt-win/issues/15
> https://community.letsencrypt.org/t/how-letsencrypt-work-for-windows-iis/2106/12?u=lonecoder
>
> Would it be possible to have the answers be changed to have a .txt extension
> added to them? I'm just worried about creating hassle and configuration
> problems (messing with Handler Mappings can easily take a web app down) and
> maybe even a security hole (might leak source code files by giving
> StaticFile handler a higher priority).
>
> Maybe the ACME server could check for a .txt file if the extensionless
> answer was a 404?
>
> Thanks.
>
> Bryan
>
> ___
> 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 draft and DANGER

[Martin Thomson]

On 28 September 2015 at 13:43, Ted Hardie  wrote:
> I'm not sure this quite right.  If I understand the proposal correctly, when
> a client sees http-01 but understands only http-00, the idea that one is
> related to the other has no meaning, as the client can only respond to
> challenges when type and version match what it has code for, right?

A-00 + B-01 is a bit odd, but if the server wants to support multiple
versions, then it can enumerate all the combinations.  Otherwise, A-00
and A-01 are treated as completely different challenges in every
regard.

I think that keeps it simple.  An implementation that does only one
version (the sensible thing at this point) doesn't have any complexity
to swallow.  An implementation that supports multiple versions should
probably just do the simple thing.

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

Re: [Acme] Support for domains with redundant but not immediately synchronized servers

[Martin Thomson]

This seems to be a common problem, so I opened a PR that someone on
that project can merge.

On 4 December 2015 at 08:08, Salz, Rich  wrote:
>> Should I open an issue on the protocol draft repository? (Which I assume is 
>> at [1])
>>   [1]: https://github.com/letsencrypt/acme-spec
>
>
> No!  Please use the IETF WG repo, at 
> https://github.com/ietf-wg-acme/acme/issues
>
> ___
> 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] Agreement integrity checksum

[Martin Thomson]

Two comments: Echoing an etag would be easier.  SHA-512 is overkill.

On 9 December 2015 at 10:15, Michael Tandy  wrote:
> Currently in the new-reg stage, the client POSTs a signed message, which may
> contain the URI of a user agreement. If the content of the URL changes, the
> results could be confusing - client software updating certificates might
> post the agreement URL without the user having agreed to the revised terms.
>
> Is it worth adding an optional agreement integrity field? We could use a
> format like this:-
>
> "agreement":
> "https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf;,
> "agreement-integrity":
> "sha512-3Ys8QL9di54ggXIGBAS2RHr_W6cMurZPizhZihkQjwl3VG2dpXZYmsYZ0B7LG-tWlVE9-Hwp9hL3Mosvbr6lCA"
>
> where the checksum is calculated like so:-
>
> $ cat LE-SA-v1.0.1-July-27-2015.pdf  | openssl dgst -sha512 -binary |
> openssl base64 -A | tr -- '+/' '-_' | tr -d '='
> 3Ys8QL9di54ggXIGBAS2RHr_W6cMurZPizhZihkQjwl3VG2dpXZYmsYZ0B7LG-tWlVE9-Hwp9hL3Mosvbr6lCA
>
> That way if the CA updates the agreement without updating the URL, it'll be
> clear which version the user has agreed to.
>
> The main downsides to this are:
>
> 1. It complicates setting up the client; realistically, instead of
> downloading, reading, and checksumming the user agreement most users will
> simply copy-and-paste the configuration data from some website. Why add to
> the boilerplate configuration, making the software harder to use for no real
> benefit? We all know in reality enforcement of the user agreement will be by
> certificate revocation, not by the courts; why add to the sound and fury of
> threatening legalese when it signifies nothing?
>
> 2. Perhaps allowing CAs to update their user agreements without the user's
> knowledge is preferable to CAs breaking users' certificate renewal scripts
> without the user's knowledge. The latter could mean that a server that is
> running fine and securely one day will become inaccessible the next day,
> unable to renew its certificate without manual intervention to accept a new
> agreement. Reliably sending e-mail is difficult due to spam filtering, so
> many servers aren't set up to push notification to administrators when
> problems like this arise.
>
> 3. The checksummed agreement could refer to other documents; those would not
> be covered by the checksum, so they could be changed. The only thing
> preventing this is good faith on the part of the CAs. Given that we rely on
> that, why not also rely on the good faith of the CA to update the URL when
> they update the agreement?
>
> 4. If SHA-512 becomes obsolete, manual intervention may be required to
> calculate a new checksum using an updated algorithm. In the event there were
> multiple CAs and SHA-512 approached obsolescence, some CAs might only accept
> SHA-512 while others didn't accept SHA-512. Clients might be complicated
> with an ability to send multiple checksums, or to negotiate the checksum
> algorithm.
>
> 5. This proposal is similar to http://www.w3.org/TR/SRI/ except this
> proposal uses URL- and filename-safe base64 encoding (RFC4648 Section 5 with
> padding removed), only requires SHA-512, and doesn't explicitly support
> multiple hash algorithms; whereas the SRI recommendation uses traditional
> base64 encoding (RFC4648 Section 4); requires SHA-256, SHA-384 and SHA-512;
> and explicitly includes support for multiple hash algorithms. Designs so
> similar yet incompatible may be a recipe for confusion; perhaps additional
> differences should be introduced so the incompatible standards are more
> obviously different.
>
> 6. People are already writing client software; maybe it's too late to update
> the spec for such a marginal improvement.
>
> What do you think?
>
> ___
> 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] The path to the "directory" resource should not be "/" and should be specified in draft-ietf-acme-acme-01

[Martin Thomson]

On 9 January 2016 at 08:46, Albert ARIBAUD  wrote:
> Actually, I withdraw this statement: acme-v01.api.letsencrypt.org's
> "/directory" is just as compliant as "/acme" or "/". There is no
> reason to constrain the path of the directory object to a specific
> value.
>
> In fact, not constraining the directory path allows running several
> ACME servers on a single HTTP host (if anyone finds a need for that),
> as long as each server has a unique directory URL (and unique
> resource URIs, to avoid collisions with other ACME servers).


That's right.  This string
"https://acme-v01.api.letsencrypt.org/directory; is what you need to
know to use the LE service.  That part isn't subject to
standardization.

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

Re: [Acme] Issue: Allow ports other than 443

[Martin Thomson]

On 23 November 2015 at 10:09, Douglas Calvert
 wrote:
> How does showing control over port 443 convey more information than showing
> control over port 22, 80, 487, 1023?

Basic information theory:
p(control over 443) < p(control over any port under 1024) < p(control
over arbitrary port)

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

Re: [Acme] Server on >= 1024 port

[Martin Thomson]

On 25 November 2015 at 02:13, Paul Millar  wrote:
> Therefore, there seems no reason to limit ACME to the traditionally secure
> port number.


I would be OK with having an ACME server validate against any port,
but only if it were going to issue a certificate with a subjectAltName
that references the port number in question.  Otherwise, for the
reason ekr noted, a user that happens to get shell access on a shared
hosting environment could get certificates issued to them for the
entire domain.

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

Re: [Acme] Revoking certificates issued by an unknown ACME server

[Martin Thomson]

On 15 January 2016 at 17:26, Hugo Landau  wrote:
> This isn't sanely automatable.


Correct.  But it doesn't require any work to define.  Do you have
evidence that suggests this scenario (a certificate issued by an ACME
server needs revocation by someone other than the one who requested
the certificate) would be commonplace enough to warrant automation?

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

Re: [Acme] tls-sni-01 validation compromise

[Martin Thomson]

On 22 January 2016 at 13:38, Jehiah Czebotar  wrote:
> 1) Change the requirement that the self signed cert have one DNSName,
> and require the response to have TWO DNS names. One that matches the
> requested hostname, and a second that is secret which proves it can
> only be created by the appropriate party initiating validation
> 2) Remove reliance on SNI matching, and make the challenge `tls-01`
> and fulfill the same HTTP response requirements as `http-01` where the
> Hostname, and request path are untrusted, but the response body with
> full keyAuthorization proves the connection to the requestor. This
> opens up the possibility of TLS validation against the $domain being
> validated instead of relying on a .acme.invalid hostname.

I think that the suggestion that the challenge response include
something unique to the challenge (as http-01 already does) is a fine
suggestion.  I don't think that it matters much how that is done.  If
the intent is to verify that the requester exercises control over the
TLS server, having this restricted to things that are part of the TLS
server configuration is probably advisable.

To that end, adding a key authorization to the certificate would seem
to be the best option.  Whether that is done as a second
subjectAltName or as a separate extension probably doesn't matter
much.

Following through with a challenge like http-01 would work, but it
means playing with the configuration of the server in two places.

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

Re: [Acme] On multiple CAs and contact-based recovery

[Martin Thomson]

On 24 March 2016 at 09:33, Karthik Bhargavan
 wrote:
> Emails with clickable links are *BAD*; we should enhance their security by
> linking them better with
> the ACME account key.


FWIW, I think that a clickable link could be possible, it just
wouldn't be able to point to the server.  If, as you suggest, the
point is to give the ACME client a fresh secret, then the link could
be changed from:

https://acme.server.example/recover/

to

acme:recover:

Most operating systems understand how to invoke local software in
response to that and your proposed flow behaves much the same from a
user perspective.

That isn't *as* good as your proposal, I don't think, but it might
have some usability advantages.

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

Re: [Acme] Paging for authorizations and certificates lists

[Martin Thomson]

I hope, for everyone's sake, that (assuming we accept this PR, which
is a good idea in general) implementations will be setting limits
quite low before triggering paging.  Otherwise, we will have a feature
that is surprising when developers first encounter it.  If you set the
limit to 1000 entries in the list, then you will find that very few
people encounter the problem, but those that do will find their tools
fail them.

You should recommend a limit that is a small number, like 10.  That
might appear often enough that developers get the message.

On 1 March 2016 at 16:30, Jacob Hoffman-Andrews  wrote:
> I posted this pull request:
> https://github.com/ietf-wg-acme/acme/pull/86/files
>
> For some accounts, the list of authorizations or certificates will be
> too large to reasonably return in a single request. This adds a notion
> of paging: you get an initial list of resources, with a link rel=next
> pointing at a URL for more, if there are more.
>
> ___
> 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] On the entropy of the nonce

[Martin Thomson]

On 12 May 2016 at 04:48, Michele Orrù  wrote:
> I also gave a look at letsencrypt/boulder[2], and as far as I've
> been able to understand there is a in64 counter, and 7 bytes of
> randomness that determine the nonce. Am I wrong to say that there
> are less than 128 bits of entropy here then?


Yes, that is less than 128 bits, and maybe lower still if you were
talking about predictability, but it's still probably plenty
(depending on how that counter is set and reset).  I believe that the
important point here is not predictability in the crypto sense, but
uniqueness.  The nonce needs to be generated such that an attacker has
very low odds of being able to find and use a collision.

Of course, having very low odds of collision is a good way of managing
that (128 bits of randomness gives pretty low odds).

I'll bet that boulder is doing that so that they good space efficiency
when the nonce is encoded in base64.  The last octet in a 128 bit
value takes a whole extra byte to encode.  A 32 bit counter and 11
bytes of randomness would better meet the above goals, or just 15
octets of randomness.

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

Re: [Acme] Preconditions

[Martin Thomson]

On 9 July 2016 at 08:00, Peter Eckersley  wrote:
> With a bit of warning I might have been able to put that together for this
> deadline.

Please don't treat meeting deadlines as anything special.  Generate
discussion and pull requests at any time.  The reason we have the
deadline is so that we can create a snapshot of where the working
group is at and to marshal efforts so that there can be productive
discussion, sometimes with a wider audience than the core group.

Given that this list is often quite productive outside of meetings,
I'm sure that a good amount of progress could be made on these issues
without being subject to the constraints around having face-to-face
time.

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

Re: [Acme] Post-IETF-96 PRs

[Martin Thomson]

On 9 August 2016 at 02:53, Richard Barnes  wrote:
> Again, I'm not totally convinced that semantic mismatches are that big a
> deal.  The "url" parameter already scopes the signed object to a specific
> resource, so the only risk would be if that specific resource accepts
> different object formats that are confusable with one another.  You need
> some signal to disambiguate, but it's not clear to me that having one big
> version is the best solution.

Let's not overwork this one, I don't care that much either way on this
point.  The suggestion seemed to have a low complexity cost for some
gain.  That cost doesn't seem to be as low as first expected
(surprise!).  Thus, I'm not willing to spend too much extra effort to
keep this.

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

Re: [Acme] Nonces for GETs

[Martin Thomson]

On 7 August 2016 at 04:55, Jacob Hoffman-Andrews  wrote:
> The rationale from the notes is that nonces are not a scarce resource.
> However, cachability and idempotence of GETs were not addressed. I think
> it's worth not requiring nonces on GETs purely for those reasons. In
> practical terms, this difference has caused real bugs for Let's Encrypt.

The hazard here is that you generate a cacheable response that
contains a nonce.  That means that clients could see the same nonce
twice if they pull from cache.  But the downside there is that you
could end up with a rejection when the nonce is used the second time.
The upside is that the rejection will contain a new nonce.  (If you
aren't retrying requests when you get a 4xx, then you will have a bad
day anyway).

Not sure about your question regarding idempotence.  Maybe you are
concerned about GET being safe (in the RFC7231 sense) and the
side-effects of the request.  To that, I'd suggest that if generating
a nonce is not safe in your server implementation, you have bought
yourself a lot of pain for nought.  Generating a nonce safely (e.g.,
without committing state) is fairly trivial.

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

Re: [Acme] Post-IETF-96 PRs

[Martin Thomson]

On 8 August 2016 at 12:39, Richard Barnes  wrote:
> So I'm honestly not that convinced that we need versioning at all here.
> Maybe we could get away with just versioning the directory?  (As I think the
> original issue proposed :) )


I believe that it was PHB who requested this originally, the rationale
being that you might create a new version of the same resource/request
that looked similar, but had different semantics.  Rather than rely on
having us (in all our possible future incarnations) not doing that, a
version indicator would make signatures invalid.

If that is a requirement that you accept, then a much simpler scheme
than the one you wrote up is possible.  Versioning the directory isn't
sufficient to achieve that goal though.  The first part of your PR
would work though: include a version, and require that it be checked.

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

Re: [Acme] Post-IETF-96 PRs

[Martin Thomson]

On 7 August 2016 at 03:46, Jacob Hoffman-Andrews  wrote:
>> #162 - Add a protocol version
>> https://github.com/ietf-wg-acme/acme/pull/162
>
> Still thinking about this one. Seems sound at first glance, but I'm thinking
> about TLS version intolerance and
> https://www.imperialviolet.org/2016/05/16/agility.html.

For similar reasons, I think that this change might be a little
overwrought.  It's certainly a non-trivial amount of added complexity.

Would it be acceptable to have a much simpler scheme that included the
version (a simple string that has to match) in the payload of all
messages?  That keeps this as a sanity check that you aren't
transporting things between incompatible versions.  The server can
provide new endpoints if it wants to support new (incompatible)
versions.

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

Re: [Acme] Add a special token parameter in ACME registration

[Martin Thomson]

On 17 August 2016 at 06:48, Richard Barnes  wrote:
> a. Infer the certificate type from the CSR.  For example, if the Subject in
> the CSR has (C, O, CN), infer that the applicant wants EV.
> b. Have a field in the new-application request that the client can use to
> indicate what type of certificate, e.g., {"certType": "ev"} to indicate EV.
> c. Have a field in the new-application request that indicates which CA the
> applicant would like to issue the certificate, e.g., {"ca":
> "identifier-for-CA"}.

Or have entirely separate ACME endpoints for the DV and EV CA.  i.e.,
https://acme.example/dv will issue DV certs, and
https://acme.example/ev will issue EV certs.

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

Re: [Acme] UX design by standards

[Martin Thomson]

On 18 February 2017 at 00:42, Josh Soref  wrote:
>
> I'm reminded ... there was one specification (i can't remember if it
> was Cookie, HTTP, or HTML) which had a UAs must tell users about
> something (redirects? cookies?).


HTTP did, at one time have such text.  I would agree with you that
attempting to push messages on users is foolish.  Record the details
in a log, sure, but trying to find a user, that's not gonna happen if
you are running acme clients on 1000s of machines.

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

Re: [Acme] UX design by standards

[Martin Thomson]

On 19 February 2017 at 05:40, Jacob Hoffman-Andrews  wrote:
> Do you have proposed alternate langauge, given the above?

Simply state the the description is designed for human consumption.
It's not localized, but it might help in more precisely identifying
the issue.  Then, let the clients decide what to do with that.

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

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

[Martin Thomson]

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

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

S6.3.2

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

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

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

S6.3.4

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

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

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

S5.2

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

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

S5.7

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

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

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

S6.1.4

   [[ Open issue: More flexible scoping? ]]

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

S6.4.1

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

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

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

S6.5.1

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

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

S6.6

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

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

S9.2

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

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

S9.3

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

S9.4

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

S10.2

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

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

[Martin Thomson]

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

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

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

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


Meta

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

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

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


S5.1

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

and

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

and

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

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

S5.2

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

MUST?

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

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

  server MUST return an error

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

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

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

S5.3

   JWK thumbprint [citation needed]

S5.4

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

S5.5

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

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

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

S5.6

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

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

"may" or "could"?

S5.7

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

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

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

S6.1

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

S6.1.2

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

Re: [Acme] Specify account by kid (reg URL) rather than key. #193

[Martin Thomson]

I am inclined to think that this is a good change, on the basis that
it means that the server is minting the identifiers that the client
uses.  I think that Jacob is probably understating the potential for
bugs here.  And key canonicalization is a bad smell.

On 27 September 2016 at 14:51, Jacob Hoffman-Andrews  wrote:
> I understand the concern, but I think that clients already have to store
> a significant amount of state: the ACME directory URL, the private key,
> and the domain names, certificates, and private keys of existing
> certificates. I think that one more item, the account URL, is not a
> heavy burden, especially when weighed against a real flaw in the
> protocol. You could consider it akin to storing a username and password
> for a more traditional login.
>
> All that said, for clients that find it to be a big savings, there is
> always the method of finding the account URL by POSTing again to new-reg
> with the same key.
>
> On 09/24/2016 06:16 PM, Hugo Landau wrote:
>> I'm somewhat against this on the grounds that it introduces unnecessary
>> state into clients (the registration URI), increasing their complexity.
>>
>> ___
>> 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] IETF 97 follow-up PRs

[Martin Thomson]

On 29 November 2016 at 13:37, Richard Barnes  wrote:
> I actually thought you were the one that suggested we keep the "status"
> fields :)   The minutes not being dispositive, I pulled up the audio
> recording of the meeting ([1], around 35:00), and didn't find anything there
> either.  ¯\_(ツ)_/¯

FWIW, I remember you mentioning that you would like to retain the
status fields, but it might have been non-verbal communication that
indicated assent.

Both approaches have their merits: either pick simplicity, or make the
extra information available where it is immediately useful.  As you
say, there's a pretty big saving if status is there.  A client then
only has to act on unresolved challenges.

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

Re: [Acme] Minor fix for JWS signature algorithms

[Martin Thomson]

On 30 November 2016 at 15:52, Richard Barnes  wrote:
> So, dear HTTP editor, which code should we use?

No need to be facetious :)

I was agreeing with Ted, if that wasn't clear.  400 is your grab bag
for "requests you don't like".  403 is generally used for cases where
authentication has been dealt with, but that is (still) insufficient.
I think that it's perfectly good for cases where the account or
signature is forbidden from making a change.

Changes of Terms of Service [sic - Changed?] 403 => 400 seems like a
better choice
Pre-Authorization 403 is probably OK here

There doesn't seem to be a good rule in these cases, but the risk is
that you slap 403 on every request that the server might want to
reject on the basis of ...stuff.

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

Re: [Acme] Generating nonces probabilistically in 6.4.1. Replay-Nonce

[Martin Thomson]

I agree with Jacob here.  MUST seems appropriate, but requiring
uniqueness absolutely imposes a constraint on server design that is so
onerous that I would see it as impractical.  (Also, the document
doesn't really identify a scope for this uniqueness, which would
probably be necessary if you had to avoid random generation.)

On 27 March 2017 at 16:46, Jacob Hoffman-Andrews  wrote:
> Forwarding on behalf of Erica Portnoy.
>
> I agree, the uniqueness should be a MUST, but I think "high probability"
> should stay so random generation of nonces is acceptable. PR:
> https://github.com/ietf-wg-acme/acme/pull/289
>
>
>  Forwarded Message 
> Subject:Generating nonces probabilistically in 6.4.1. Replay-Nonce
> Resent-Date:Fri, 24 Mar 2017 18:19:35 -0700 (PDT)
> Resent-From:alias-boun...@ietf.org
> Resent-To:  r...@ipv.sx, j...@eff.org, jdkas...@umich.edu
> Date:   Fri, 24 Mar 2017 18:03:53 -0700
> From:   erica 
> To: draft-ietf-acme-a...@ietf.org
>
>
>
> In section 6.4.1. Replay-Nonce, it states: "The server should generate
> the value provided in Replay-Nonce in such a way that they are unique to
> each message, with high probability."
>
> Should this not be: "The server MUST generate the value provided in
> Replay-Nonce in such a way that they are unique to each message."
>
> This is actually two separate items:
> - First, that the server must, not should, generate a unique
> Replay-Nonce. I can't imagine that we're ok with the spec allowing a
> server to come under replay attacks, so this should probably be MUST.
> - Second, do Replay-Nonces need to be certainly unique to each message?
> Or are we merely attempting to mostly rule out replay attacks? If we
> want to disable them completely, not just with extremely high
> probability, then we should remove "with high probability".
>
> Best,
> Erica Portnoy
>
>
> ___
> 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] Just the technical comments (was: ACME draft is now in WGLC.)

[Martin Thomson]

Yes, many of these things were already addressed by Jacob and others.

On 7 March 2017 at 05:32, Richard Barnes  wrote:
>> S6.3.2
>>
>>[...] and MUST reflect [the?] value of the
>>"external-account-binding" field in the resulting account object
>>
>> Is this a direct copy of the MAC that was provided?  Do you realize
>> that this enables a user with access to any account that was created
>> with a binding to replay the binding in new accounts without actually
>> having the MAC key?
>
>
> How would that work?  ISTM that since the MAC is calculated over the JWK
> representation of the account public key, you couldn't re-use the MAC to
> convey this authorization to another key.

Yeah, that is a detail I missed (that the MAC has a very specific form
isn't established by this point in the doc).

> If there is an issue here, we do need to fix it, since the major purpose of
> external account binding is to convey authorization, e.g., for EV.
>
> It is probably overkill to reflect the whole object.  I think my preferred
> solution would be to just reflect the "kid" value as you suggest.

That would be fine.

>> [re: Revocation on account deletion]
>
>
> As with all server behaviors here, we can't really be too prescriptive; CAs
> will have compliance needs dictated by things like customers or root
> programs that will be will override voluntary protocol specifications.  Some
> cautionary text might be warranted.

I realize that there might be cases where termination of an account
might result in revocation, but the protocol doesn't need to require
it.  (I think that this was discussed and resolved by saying that the
certificates will not be directly affected by this action.)

>> S6.5.1
>>
>>In responding to poll requests while
>>the validation is still in progress, the server MUST return a 202
>>(Accepted) response
>>
>> The 202 is an odd choice here.  The resource exists and has content,
>> so 200 works perfectly well for this purpose.
>
>
> WFM.  200 + Retry-After is OK?

Probably.  It's a little odd to include Retry-After on a successful
response, (503 being more common), but I can't think of anything
better.

>> S9.4
>>
>> Does an ACME server send Referer[sic]?  What should it set it to?
>
> You mean as an SSRF mitigation?  In that case, the real question is what
> headers the ACME server should send in order to minimize the probability
> that an attacked resource would respond to the request.  I'm not sure
> Referer is great for that; wouldn't Origin be better?  And in the Origin
> case, I would think the right thing to set it to would be the origin for the
> server.

I don't mean as anything.  The question is simply whether it does or
not.  It might make it easier to construct a valid response, though
I'm not sure that has reads on the ability of an attacker to generate
a valid response given the challenge structure.

It would set the value to some part of the URL that referred it.

Origin is very specific to the web security model.  It refers to the
origin that is making a request.  I wouldn't use it here.

> Proposed edits [...]
>
> https://github.com/ietf-wg-acme/acme/pull/271

I'll review that, thanks.

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

[Acme] Comments on draft-barnes-acme-service-provider

[Martin Thomson]

This document is a key piece of the STIR/SHAKEN infrastructure, as
such, I think that this is worth working on and a good basis for that.
I have a few questions, some of which might touch on the
stir-certificates draft (which I see is in the RFC editor's queue,
hmm).

STIR certificates define TNAuthList to be a list of service provider
codes, number ranges and numbers.  Is there any reason why this needs
have more than one service provider code?  Indeed, is there any reason
that service provider codes and telephone numbers need to be merged
into a single type?  Reading RFC 5280, subjectAltName can include
multiple otherName values, each of which could be a
serviceProviderCode or a telephone number set.  I see several
alternatives, for instance each otherName could be:

1. a mix of SPC and TN sets (today)
2. either a SPC or a TN set as two separate types
3. a single SPC with an associated TN set
4. a TN set with a optional SPC associated
5. a TN set with an optional SPC set

It's not obvious, but I assume that there are cases where service
providers end up with multiple service provider codes over time.  If
the numbers allocated to that provider get all mixed up so that there
is no longer a clean mapping from a number to a service provider code,
then option 1 (or 5) seem like the best choice.

I ask because the encoding of TNAuthList into JSON isn't specified in
the draft.  It seems like the interactions here with the STI-PA are
largely based on service provider code and the example is actually
showing a service provider code (and not an E.164 range as might be
inferred from the hypen).

Is this the intended interaction model:

a. the service provider sends its codes to the CA,
b. the CA asks the STI-PA about the service provider codes,
c. the STI-PA returns in the affirmative (possibly including
associated telephone numbers),
d. the CA authorizes the certificate issuance (possibly including the
telephone numbers or using the telephone numbers to validate the
subjectAltName proposed in the CSR).

Or is the model intentionally flexible about what the service provider
can request authorization for?  Can the service provider request
authorization for a telephone number range that is orthogonal to the
codes that it might use?

Having this explained in more details would help a lot.  A ladder
diagram for the interaction above might help too - existing ACME
challenges mostly involve talking back to the ACME client, this goes
to a third party.

If there is some directed association between service provider codes
and telephone numbers, then option 5 above might be a more natural fit
for the certificate (or 4 if the TN-SPC mapping is forced to be
many-to-one at the STI-PA).  Otherwise, I'm not sure why the two types
of data are intermixed.  From the ACME perspective, I want to
understand why there is a TNAuthList type rather than separate
"service-provider-code" and "tn-set" identifiers.

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

Re: [Acme] Comments on draft-barnes-acme-service-provider

[Martin Thomson]

I just realized that I misunderstood and there is a bearer token being
used to resolve the challenge and the service provider is responsible
for talking to the STI-PA to get this.  I think that this needs to
have a bit more detail for it to be understood.

On 10 July 2017 at 11:36, Martin Thomson <martin.thom...@gmail.com> wrote:
> This document is a key piece of the STIR/SHAKEN infrastructure, as
> such, I think that this is worth working on and a good basis for that.
> I have a few questions, some of which might touch on the
> stir-certificates draft (which I see is in the RFC editor's queue,
> hmm).
>
> STIR certificates define TNAuthList to be a list of service provider
> codes, number ranges and numbers.  Is there any reason why this needs
> have more than one service provider code?  Indeed, is there any reason
> that service provider codes and telephone numbers need to be merged
> into a single type?  Reading RFC 5280, subjectAltName can include
> multiple otherName values, each of which could be a
> serviceProviderCode or a telephone number set.  I see several
> alternatives, for instance each otherName could be:
>
> 1. a mix of SPC and TN sets (today)
> 2. either a SPC or a TN set as two separate types
> 3. a single SPC with an associated TN set
> 4. a TN set with a optional SPC associated
> 5. a TN set with an optional SPC set
>
> It's not obvious, but I assume that there are cases where service
> providers end up with multiple service provider codes over time.  If
> the numbers allocated to that provider get all mixed up so that there
> is no longer a clean mapping from a number to a service provider code,
> then option 1 (or 5) seem like the best choice.
>
> I ask because the encoding of TNAuthList into JSON isn't specified in
> the draft.  It seems like the interactions here with the STI-PA are
> largely based on service provider code and the example is actually
> showing a service provider code (and not an E.164 range as might be
> inferred from the hypen).
>
> Is this the intended interaction model:
>
> a. the service provider sends its codes to the CA,
> b. the CA asks the STI-PA about the service provider codes,
> c. the STI-PA returns in the affirmative (possibly including
> associated telephone numbers),
> d. the CA authorizes the certificate issuance (possibly including the
> telephone numbers or using the telephone numbers to validate the
> subjectAltName proposed in the CSR).
>
> Or is the model intentionally flexible about what the service provider
> can request authorization for?  Can the service provider request
> authorization for a telephone number range that is orthogonal to the
> codes that it might use?
>
> Having this explained in more details would help a lot.  A ladder
> diagram for the interaction above might help too - existing ACME
> challenges mostly involve talking back to the ACME client, this goes
> to a third party.
>
> If there is some directed association between service provider codes
> and telephone numbers, then option 5 above might be a more natural fit
> for the certificate (or 4 if the TN-SPC mapping is forced to be
> many-to-one at the STI-PA).  Otherwise, I'm not sure why the two types
> of data are intermixed.  From the ACME perspective, I want to
> understand why there is a TNAuthList type rather than separate
> "service-provider-code" and "tn-set" identifiers.

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

Re: [Acme] Comments on draft-barnes-acme-service-provider

[Martin Thomson]

On 11 July 2017 at 07:29, Mary Barnes  wrote:
> Hi Martin,
>
> Thanks for taking the time to review.   We're actually working on a revision
> right now addressing your comments and agree totally with your point that
> more detail is definitely needed in this draft.  Since we were still
> reviewing letter ballot comments on the document at the draft deadline, we
> decided to wait for the revision until we knew how those would be handled
> and whether we might need additional changes to accommodate any of those
> comments. But, we plan to submit once the draft submissions re-open.
>
> One important note is that this document is dealing only with challenges
> associated with the Service Provider Codes and related token.  Jon has a
> separate draft outlining challenges for telephone numbers:
> https://tools.ietf.org/html/draft-ietf-acme-telephone-00  I do have a
> few inline comments below [MB].

I reviewed the number one also, but didn't have any concrete
questions.  I was going to provide comments on automating the process,
but it's been one of those weeks.

>> Indeed, is there any reason
>> > that service provider codes and telephone numbers need to be merged
>> > into a single type?
>
> [MB] That's a good question for STIR WG, but again I think it was for
> flexibility, although I guess you could still define each separately and if
> you had a mix, then you have both. [/MB]

subjectAltName more or less relies on this.  The only cost is
inefficiency.  You wouldn't want to have a SAN otherName for every
telephone number, but I think that you could easily pay that cost for
the service provider code.

>> > 1. a mix of SPC and TN sets (today)
>> > 2. either a SPC or a TN set as two separate types
>> > 3. a single SPC with an associated TN set
>> > 4. a TN set with a optional SPC associated
>> > 5. a TN set with an optional SPC set
>
> [MB] So, I don't think we've explored all those combinations.  Right now for
> SHAKEN obviously we are only using a single SPC.  Obviously, SPs will have a
> way of associating TNs with an SPC, but at this point, there's no intent to
> use certificates or do validation per TN (or a set of).Jon talks a
> little bit about cases with both in section 4.1 of his draft.  But, I don't
> think we have a definitive approach yet. [/MB]

I see that the IESG approved stir-certificates.  I'm a little
concerned that it's going to be published without ever having
discussed this rather fundamental piece.  I'll ping Jon and STIR
(YAML, FML); maybe this was discussed and there is a good story.

> [MB] The intent for this draft is to encode the TNAuthList as an array of
> strings to support multiple service provider codes.
> Now perhaps we should rename it from TNAuthList to SPAuthList since we don't
> intend for this challenge type to support
> TNs. [/MB]

That's an improvement better.  To be consistent with domain names, you
probably want to include just a single service provider code.  You can
gain authorizations for multiple codes separately, and ACME supports
that.

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

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

[Martin Thomson]

The biggest concern I have is the text regarding certificate lifetime
and the handling of the possibility that IP addresses are dynamically
allocated.  This seems a little weak and it leaves a lot to the CA to
manage.  Is there anything that can be done to gain a stronger
assertion that the allocation is (more) persistent?  An affirmation
from someone higher in the tree perhaps?

Some nits:

You definitely want to reference RFC 5952 here when it comes to IPv6 addresses.

Break the long line with the ip6.arpa example.

I would also recommend a shorter label, maybe _acme-ip.  You don't
want a very long name in case the base name is long (which is
relatively commonplace).


On 18 July 2017 at 02:03, Jacob Hoffman-Andrews  wrote:
> This looks good! Nice work.
>
> On 07/16/2017 04:29 PM, Roland Bracewell Shoemaker wrote:
>> There was some previous discussion about possibly using a slightly
>> simpler DNS based verification method on the list last time I posted
>> this as an individual submission. After reading through the CABF BRs for
>> IP validation I'm pretty sure the proposed solution (checking for a TXT
>> record in the reverse mapping zone) would not be considered BR compliant
>> so I've stuck with the originally proposed challenge.
>>
>> On 07/16/2017 04:24 PM, internet-dra...@ietf.org 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 of the IETF.
>>>
>>> Title   : ACME IP Identifier Validation Extension
>>> Author  : Roland Bracewell Shoemaker
>>>  Filename: draft-ietf-acme-ip-00.txt
>>>  Pages   : 7
>>>  Date: 2017-07-16
>>>
>>> Abstract:
>>>This document specifies identifiers and challenges required to enable
>>>the Automated Certificate Management Environment (ACME) to issue
>>>certificates for IP addresses.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-acme-ip-00
>>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-00
>>>
>>>
>>> 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
>>
>
> ___
> 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-ip-00.txt

[Martin Thomson]

On 19 July 2017 at 03:45, Jacob Hoffman-Andrews <j...@eff.org> wrote:
> On 07/17/2017 10:48 PM, Martin Thomson wrote:
>> The biggest concern I have is the text regarding certificate lifetime
>> and the handling of the possibility that IP addresses are dynamically
>> allocated.  This seems a little weak and it leaves a lot to the CA to
>> manage.  Is there anything that can be done to gain a stronger
>> assertion that the allocation is (more) persistent?  An affirmation
>> from someone higher in the tree perhaps?
>
> I think ultimately this is a policy question and outside the scope of
> ACME (except for pointing out that it's worth thinking about). If we
> want a mechanism for owners of IP space to express the policy they'd
> like CAs to apply to that space, it should probably look something like CAA.

In this case, I disagree.  With names, there is an expectation that
certificates can be issued for them.  This is not the default case for
IP addresses, so the defender is not naturally aware that they need to
defend this way.

I don't think that this needs to be onerous, but an explicit opt in
(as opposed to an opt out) would be preferable.

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

Re: [Acme] Consensus -- CAA draft to WGLC?

[Martin Thomson]

On 6 July 2017 at 20:07, Hugo Landau  wrote:
> Vendor-assigned identifiers could be supported as such:
>   vnd:example.com/custom-method

RFC 6648 explains why vendor-prefixes can be a bad idea.  I think that
you should do as Yaron suggested and establish a registry.  Set the
bar low (specification required would be my choice) and then CABF can
make a new entry as they see fit.  In particular, do away with
attaching some sort of semantic to prefixes.

> 2. Adding a reference to CABF is weird

This I agree with.

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

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

[Martin Thomson]

On 24 June 2017 at 02:24, Yaron Sheffer  wrote:
>>> Expires is to ensure that the certificate is not
>>> cached beyond the point where a newer certificate will be issued.  You
>>> should remove this text.
>>
>> OK
>
> Is there some other common header to denote that the value of a URL is only
> good for X time?

Isn't enough to rely on the server echoing your parameters?  (Another
reason to use absolute values for the end of the recurring interval.)

>>> Don't mention time-sensitive policy actions by the CA/B Forum.
>>
>> Makes sense.
>
> I disagree. CA/B forum decisions (unlike IETF standards) are mandatory for
> some parties to follow and so can be relied upon by the DNO.

This is a protocol.  What CABF do with it is entirely up to them.
They aren't the only ones creating policy that might affect someone
using this protocol.

>>> Can't you simply ensure that the CDN can't modify the CAA record?
>>
>> This is the minimum we could say.  At this point, I think we are trying
>> to explore a bit what other mitigations can be put in place.
>
> Unfortunately this is insufficient, because in the case of CDN's, some of
> the authorization methods are subject to spoofing.

If the CAA record exists, then spoofing won't result in the
certificate being issued, so what is the problem?

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

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

[Martin Thomson]

One further thought. ACME uses an absolute time for expiration. This uses a
relative time. I think that I prefer the former. I realize that consistency
might be impossible in this case, since the recurrent duration is
necessarily relative, but I though it worth raising.

On 19 Jun. 2017 10:08 am, "Martin Thomson" <martin.thom...@gmail.com> wrote:

> A few brief comments on this draft.
>
> On 16 June 2017 at 22:19,  <internet-dra...@ietf.org> wrote:
> >This memo proposes an ACME extension to enable the issuance of short-
> >term and automatically renewed certificates.  This allows a domain
> >name owner to delegate the use of certificates to another party,
> >while retaining the capability to cancel this delegation at any time
> >with no need to rely on certificate revocation mechanisms.
>
> I found the introduction overly specific.  The generic use case is to
> simplify the deployment of certificates to unprivileged nodes.  The
> unprivileged nodes then only need to be configured with a URL for
> their certificates.
>
> That requires a couple of paragraphs of exposition at most.  This
> extends to Section 2, which describes a system architecture that
> implies the existence of protocol elements that are simply not defined
> in this document.
>
> Sections 1 and 2 could much more clearly describe what *this* document
> provides.  It provides an extension to ACME that allows for the
> creation of a certificate that automatically renews.
>
> The focus on the CDN case affects the entire document.  The point is
> that the authorized entity is delegating the ability to use a
> certificate for its name to an unprivileged node.  Don't use "CDN",
> "content owner" or any of these highly specific terms.  Use generic
> terms; make new terms if necessary.  FWIW, while NDC is a cute
> reversal, "consumer" really isn't accurate.
>
> draft-iab-web-pki-problems has been abandoned.  It's not a great idea
> to cite it.
>
> In Section 3.1.1, I think that the resolution of these fields, being
> in days, is not conducive to reducing granularity.  (Or will you
> permit 5.7e-3 as a value?)
>
> Section 3.1.1 needs to clearly articulate how
> "recurrent-certificate-validity" (could this be any more verbose and
> hard to type?) relates to "expires".
>
> Please include a definition for the new attributes, rather than just
> providing an example and commenting the JSON.
>
> In Section 3.1.2, you REALLY, REALLY need to authenticate this
> request.  My suggestion is to change this to a POST request with {
> "recurrent": false }.  (I'd have suggested PUT or PATCH, but ACME's
> reliance on JWS perverts that in ways that is incompatible with those
> methods.)
>
> In Section 3.2, the discussion about a Proxy is misleading.  The only
> relevant actor in this is an ACME client.  This section could be
> reduced to:
>
> An ACME client discovers whether a server supports this extension by
> examining a newly created order.  The "recurrent" member will exist if
> the server supports automatic recurring certificate issuance; the
> "recurrent" member will be true if the server accepts the request.
>
> Can the server specify a shorter value for "recurrent-total-lifetime"?
>
> I don't understand Section 3.3 at all.  I'd recommend removing this
> section.  The DNO will decide what authorizations it requests amply
> without this level of proscription in standards.
>
> In Section 3.4, the use of the Expires header field is a common
> mistake.  This is an HTTP caching directive.  It should probably be
> shorter than the expiration time of the certificate (half in fact),
> but not for the reasons that you might think.  The purpose of a
> recommendation on Expires is to ensure that the certificate is not
> cached beyond the point where a newer certificate will be issued.  You
> should remove this text.
>
> Section 5.1 should be promoted to Section 5
>
> Don't mention time-sensitive policy actions by the CA/B Forum.
>
> Can't you simply ensure that the CDN can't modify the CAA record?
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Before entering WGLC ...

[Martin Thomson]

Like Russ, I find the statement very difficult to read.  Would
inverting it be better?

> A CA MUST NOT issue authorize issuance if a CAA record is present unless the 
> "account-uri" parameter identifies the account making a certificate issuance 
> request.


On 19 June 2017 at 00:16, Salz, Rich  wrote:
> Thank you.  For me, it addresses the issue.  Russ, are you ok?
>
> ___
> 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-star-00.txt

[Martin Thomson]

A few brief comments on this draft.

On 16 June 2017 at 22:19,   wrote:
>This memo proposes an ACME extension to enable the issuance of short-
>term and automatically renewed certificates.  This allows a domain
>name owner to delegate the use of certificates to another party,
>while retaining the capability to cancel this delegation at any time
>with no need to rely on certificate revocation mechanisms.

I found the introduction overly specific.  The generic use case is to
simplify the deployment of certificates to unprivileged nodes.  The
unprivileged nodes then only need to be configured with a URL for
their certificates.

That requires a couple of paragraphs of exposition at most.  This
extends to Section 2, which describes a system architecture that
implies the existence of protocol elements that are simply not defined
in this document.

Sections 1 and 2 could much more clearly describe what *this* document
provides.  It provides an extension to ACME that allows for the
creation of a certificate that automatically renews.

The focus on the CDN case affects the entire document.  The point is
that the authorized entity is delegating the ability to use a
certificate for its name to an unprivileged node.  Don't use "CDN",
"content owner" or any of these highly specific terms.  Use generic
terms; make new terms if necessary.  FWIW, while NDC is a cute
reversal, "consumer" really isn't accurate.

draft-iab-web-pki-problems has been abandoned.  It's not a great idea
to cite it.

In Section 3.1.1, I think that the resolution of these fields, being
in days, is not conducive to reducing granularity.  (Or will you
permit 5.7e-3 as a value?)

Section 3.1.1 needs to clearly articulate how
"recurrent-certificate-validity" (could this be any more verbose and
hard to type?) relates to "expires".

Please include a definition for the new attributes, rather than just
providing an example and commenting the JSON.

In Section 3.1.2, you REALLY, REALLY need to authenticate this
request.  My suggestion is to change this to a POST request with {
"recurrent": false }.  (I'd have suggested PUT or PATCH, but ACME's
reliance on JWS perverts that in ways that is incompatible with those
methods.)

In Section 3.2, the discussion about a Proxy is misleading.  The only
relevant actor in this is an ACME client.  This section could be
reduced to:

An ACME client discovers whether a server supports this extension by
examining a newly created order.  The "recurrent" member will exist if
the server supports automatic recurring certificate issuance; the
"recurrent" member will be true if the server accepts the request.

Can the server specify a shorter value for "recurrent-total-lifetime"?

I don't understand Section 3.3 at all.  I'd recommend removing this
section.  The DNO will decide what authorizations it requests amply
without this level of proscription in standards.

In Section 3.4, the use of the Expires header field is a common
mistake.  This is an HTTP caching directive.  It should probably be
shorter than the expiration time of the certificate (half in fact),
but not for the reasons that you might think.  The purpose of a
recommendation on Expires is to ensure that the certificate is not
cached beyond the point where a newer certificate will be issued.  You
should remove this text.

Section 5.1 should be promoted to Section 5

Don't mention time-sensitive policy actions by the CA/B Forum.

Can't you simply ensure that the CDN can't modify the CAA record?

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

Re: [Acme] v2

[Martin Thomson]

I don't see the distinction between what LE deploy and ACME as defined
by the IETF being any different to the distinction between whatever
any other CA currently deploy and the IETF spec.  It's a thing that
exists, but I see no reason to accord the LE proprietary protocol any
special status other than by acknowledging provenance.

This is the IETF version of ACME, and as such it needs no version
qualification.  I doubt that there will be any confusion from this
being deployed alongside the proprietary LE protocol.

On 13 June 2017 at 16:26, Richard Barnes  wrote:
> (Everyone get your bike shed paint out)
>
> In talking with a few folks around the community, I've heard people refer to
> the IETF version of ACME as "v2", where implicitly "v1" is the initial
> version deployed by Let's Encrypt and its clients right now.
>
> How would people feel about reflecting this in the draft / RFC?  I've posted
> a PR with the changes this would entail:
>
> https://github.com/ietf-wg-acme/acme/pull/321
>
> The only question this raises for me is what to do about v1.  Given that
> Let's Encrypt has evolved their interface some since the first version, I'm
> not sure there's one consolidated spec out there for what they currently
> have deployed.  So while it would be nice to have a reference to v1 in this
> document if we make it v2, I'm not inclined to worry about it too much.  I'm
> willing to leave it up to the LE folks if they want to submit a v1 later for
> historical purposes.
>
> Any objections to merging the above PR?
>
> --Richard
>
>
> ___
> 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] Revisiting Proactive Issuance & new-order CSR

[Martin Thomson]

On Fri, Sep 22, 2017 at 4:40 AM, Richard Barnes  wrote:
> Daniel noted that there might be some issues with GET idempotency here, but
> I don't think this actually makes GET non-idempotent.

It's still idempotent, because doing the GET twice has the same effect
as doing it once.  You are concerned about the GET no longer being
safe.  That is, it is no longer side-effect free.

It is OK to do things in response to a GET as long as the server owns
the consequences.  Servers frequently log GET requests, which isn't
safe or even idempotent, but servers do it because there is an
advantage to them that exceeds the costs.  As long as clients aren't
held accountable for these side-effects, it's OK.

Or, you could consider the resource to have been updated at some point
in the past as though the authorization triggered proactive issuance,
but it's just that the GET has taken a little while to "find" the
updated state.  Think of it as a lazy load, or maybe an extreme case
of the server cache needing to be populated.

If you like, we could also dive into whether this specific type of
request is safe to send in 0-RTT, but I don't have the brain cells for
that right now.

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

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

[Martin Thomson]

On Fri, Sep 1, 2017 at 10:47 AM, Adam Roach  wrote:
> On 8/31/17 19:25, Stephen Farrell wrote:
>>
>> I really like the idea that the acme WG aims to figure out a way to enable
>> people at home to use https with their home n/w routers.
...
> There was some musing at the W3C TPAC in Lisbon last year on this topic. The
> tricky part is figuring out what kind of model makes sense for the certs at
> all. I suspect we'd need to come to some agreement on that issue before
> trying to work out how ACME can be used to issue them. There's some
> background reading at
> , mostly in
> the form of slide decks.

I don't see acme-ip being the solution here.  Everyone has - or could
have - a 10.0.0.1.  The same applies to .local (see below).  The
movement needs to come from the relying party side.

Thanks for sharing the link Adam, I was not aware of this.  For the
benefit of folks in the galleries, the three talks discuss two
options.

The first two talk about providing *real* names for the devices
(..com for example).  The nice thing with
that is that that solution already works today.  With ACME, if the
manufacturer is willing to answer the challenges, the device only
needs some way to talk to the manufacturer when it wants a
certificate, not have an actual online presence.  (Insert usual
concerns about the manufacturer going out of business, etc...)

I'm not sure that I fully grok the last one, but it talks about an
ACME-like protocol that is mediated by a browser.  It also talks about
creating certificates for non-unique names on .local, so I'm not sure
that it's feasible.

Not discussed here, but we've talked a bit about using key continuity
for network-local devices and changing the "bad certificate" page we
show on first connection (with a different page when a different key
is presented by the device).

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

Re: [Acme] Returning multiple errors

[Martin Thomson]

Is this better cast as "sub" problems, or just "additional" problems?

On Tue, Nov 21, 2017 at 10:19 AM, Jacob Hoffman-Andrews  wrote:
> I've submitted a PR adding this to the spec:
>
> https://github.com/ietf-wg-acme/acme/pull/354
>
> commit a6cc0aedf96067e8b3aaf37662785fcf8b38dd18
> Author: Jacob Hoffman-Andrews 
> Date:   Mon Nov 20 15:14:29 2017 -0800
>
> Define sub-problems.
>
> diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
> index a2c11ab..a9e3535 100644
> --- a/draft-ietf-acme-acme.md
> +++ b/draft-ietf-acme-acme.md
> @@ -521,6 +521,53 @@ set to a URI other than those defined above.
> Servers MUST NOT use the ACME URN
>  namespace for errors other than the standard types.  Clients SHOULD
> display the
>  "detail" field of all errors.
>
> +### Sub-problems
> +
> +Sometimes a CA may need to return multiple errors to a single
> +request. Additionally, the CA may need to attribute errors to specific
> +identifiers.  For instance, a new-order request may contain multiple
> +identifiers for which the CA cannot issue. In this situation, an ACME
> +problem document MAY contain the "sub-problems" field, contains a JSON
> +array of problem documents, each of which MAY contain an "identifier"
> +field. If present, the "identifier" field MUST contain an ACME identifier
> +({{iana-identifier}}). The "identifier" field MUST NOT be present at
> +the top level in ACME problem documents. It can only be present in
> sub-problems.
> +Sub-problems need not all have the same type, and do not need to match
> the top level type.
> +
> +ACME clients may choose to use the "identifier" field as a hint that
> +an operation would succeed if certain identifiers were omitted. For
> +instance, if an order contains ten DNS identifiers, and the new-order
> +request returns a problem document with two sub-problems, referencing two
> +of those identifiers, the ACME client may choose to submit another order
> +containing only the eight identifiers not listed in the problem document.
> +
> +~
> +HTTP/1.1 403 Forbidden
> +Content-Type: application/problem+json
> +
> +{
> +"type": "urn:ietf:params:acme:error:malformed",
> +"detail": "Some of the identifiers requested were rejected",
> +"sub-problems": [
> +{
> +"type": "urn:ietf:params:acme:error:malformed",
> +"value": "Invalid underscore in DNS name \"_example.com\"",
> +"identifier": {
> +"type": "dns",
> +"value": "_example.com"
> +}
> +},
> +{
> +"type": "urn:ietf:params:acme:error:rejectedIdentifier",
> +"value": "This CA will not issue for \"example.net\"",
> +"identifier": {
> +"type": "dns",
> +"value": "example.net"
> +}
> +}
> +]
> +}
> +~
>
>  # Certificate Management
>
> ___
> 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] Returning multiple errors

[Martin Thomson]

On Wed, Nov 22, 2017 at 5:55 AM, Jacob Hoffman-Andrews <j...@eff.org> wrote:
> On 11/20/2017 08:24 PM, Martin Thomson wrote:
>> Is this better cast as "sub" problems, or just "additional" problems?
>
> I think "additional" is the wrong semantic, because it implies that the
> first error is hoisted to the top position, so a naive client would only
> show the first error. Instead, there's a top-level generic error ("some
> identifiers were rejected"), and then there are potentially multiple
> errors that are part of it (_example.com, example.net).

I ask because your example highlighted two types of problems.  That
they could be aggregated doesn't seem an necessary or innate property.

The difficulty with the sort of aggregation design you propose is that
you need to aggregate and I don't know what the logic would be in the
general case.  On the other hand, additional problems are easy to
accumulate and emit.  They are also easy to consume, either by just
doing the dumb thing and handling only the first, or by working
through a list.

The alternative is to provide a specific type (e.g.,
"urn:ietf:params:acme:error:multiple"), that says "there were multiple
problems", and list the real problems in the body.  The text for the
specific type could be more helpful - just as in your example - or
not.

"sub-problems" seems like the worst of these options.

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

Re: [Acme] Returning multiple errors

[Martin Thomson]

Have you considered json text sequences: https://tools.ietf.org/html/rfc7464 ?

I don't know what a random JSON parser would do with your stacked error codes.

On Thu, Nov 16, 2017 at 3:54 PM, Jacob Hoffman-Andrews  wrote:
> On 11/15/2017 07:07 PM, Richard Barnes wrote:
>> Following Daniel's lead on looking for implementation: Is this
>> something LE would be implementing?
> Yep, we would definitely implement this. I'll send a PR.
>
> ___
> 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] Returning multiple errors

[Martin Thomson]

Oh, my bad, my eyes turn out to be a terrible JSON parser.

On Thu, Nov 16, 2017 at 4:49 PM, Matthew A. Miller
<linuxwolf+i...@outer-planes.net> wrote:
> On 17/11/16 16:47, Jacob Hoffman-Andrews wrote:
>> On 11/16/2017 12:45 AM, Martin Thomson wrote:
>>> I don't know what a random JSON parser would do with your stacked error 
>>> codes.
>> I don't understand. What I'm proposing is an array of JSON objects under
>> the sub-problems field, which should be supported by any JSON parser.
>>
>
> I don't think JSON text sequences is the right solution here, either.  A
> JSON array seems perfectly appropriate to me.
>
>
> - m
>
> Matthew A. Miller
>

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

Re: [Acme] Fixing the TLS-SNI challenge type

[Martin Thomson]

If you are using a new protocol, all of the concerns Peter have come
into play.  If you are there, why wouldn't you do the challenge
validation within the new protocol rather than using the certificate
(which is sent in the clear in current TLS versions).  That might be
easier to implement than generating the self-signed certificate...

On Fri, Jan 12, 2018 at 2:06 PM, Roland Bracewell Shoemaker
 wrote:
> I'm actually going to roll back my thoughts on the SNI value. Thinking
> about this more I think it does actually make sense to revert to using
> the actual host name here.
>
> In the initial design of the TLS-SNI challenge the XXX.acme.invalid
> value was used as a way to allow servers to dynamically serve both
> regular and validation traffic. Since we would be using ALPN here we no
> longer need a special SNI value in order to differentiate validation
> traffic from regular traffic so this token value is no longer needed.
>
> If we change that I think we can also remove the need to compute a pair
> of SAN values for the cert contents. The original purpose of this was to
> prevent a 'dumb' client from simply constructing a certificate on the
> fly by sticking the SNI value it received into the SAN and automatically
> allowing validation of anything that hit it. If we switch to using the
> host name in the SNI then this is no longer necessary as the token value
> is no longer present in the request.
>
> If we make these changes I think the challenge would be different enough
> that at that point it should probably be given a completely new name in
> order to differentiate it from the original TLS-SNI challenges. I'd
> suggest the incredibly imaginative TLS-ALPN (or tls-alpn-01).
>
> On 01/11/2018 04:49 PM, Roland Bracewell Shoemaker wrote:
>> This seems like a silver bullet for the problems we’ve been seeing. Given 
>> that blindly responding to an unknown ALPN value would be an RFC violation 
>> this seems safe (although, hey, who knows what servers/cloud providers 
>> actually do). Definitely interested in the results of the scan. There could 
>> still be some argument about ‘misuse’ of the SNI extension but unless we 
>> have a concrete reason to the host name being validated I’m not sure I’m 
>> convinced we should.
>>
>> Does anyone have any objections/spot any major issues with doing this?
>>
>>> On Jan 11, 2018, at 2:41 PM, Jonathan Rudenberg  
>>> wrote:
>>>
>>> As many of you are probably aware, Frans Rosén of Detectify discovered a 
>>> method of exploiting many shared hosting providers to obtain unauthorized 
>>> certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt 
>>> is in the process of removing support for these challenge types[1].
>>>
>>> Obviously this is not ideal, as the TLS-SNI challenge is useful in a 
>>> variety of use cases. The good news is that TLS-SNI-02 appears to be 
>>> fixable.
>>>
>>> In order to get the ball rolling on a fixed version (aka TLS-SNI-03), 
>>> here’s a straw proposal, based on something originally publicly suggested 
>>> by Ryan Sleevi[2]:
>>>
>>> Start with the TLS-SNI-02 challenge specification, and add the requirement 
>>> that the ACME server MUST send an ALPN extension in the ClientHello with a 
>>> single “acme” protocol name, and the ACME server MUST confirm that the 
>>> ServerHello also includes an ALPN extension with a single “acme” protocol 
>>> name.
>>>
>>> The only concern I’ve seen about this is the theoretical possibility that 
>>> servers might just repeat back the ALPN extension with the same protocol 
>>> name, which I believe we can remedy by doing a scan of the Alexa Top 1M (or 
>>> similar) to see if this behavior exists in the wild.
>>>
>>> Jonathan
>>>
>>> [0] 
>>> https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996
>>> [1] 
>>> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
>>> [2] 
>>> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08984.html
>>> ___
>>> 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] Fixing the TLS-SNI challenge type

[Martin Thomson]

The confidentiality point was a minor one, certainly, but it would
represent an improvement.

TLS-SNI is a protocol already, but it's more complicated than it needs
to be.  Certificate generation is a pretty big lift compared to the
other challenges.


On Fri, Jan 12, 2018 at 2:29 PM, Jonathan Rudenberg
<jonat...@titanous.com> wrote:
>
>> On Jan 11, 2018, at 22:26, Martin Thomson <martin.thom...@gmail.com> wrote:
>>
>> If you are using a new protocol, all of the concerns Peter have come
>> into play.  If you are there, why wouldn't you do the challenge
>> validation within the new protocol rather than using the certificate
>> (which is sent in the clear in current TLS versions).  That might be
>> easier to implement than generating the self-signed certificate…
>
> I don’t think an entirely new protocol makes sense. In order to do the 
> TLS/SNI/ALPN handshake a certificate is already sent in the ServerHello, so 
> there’s no reason not to use it to transport the authorization token. 
> Generating a self-signed certificate is trivial, and I’m not aware of any 
> relevant security concerns around fetching the authorization in the clear 
> (the dns-01 and http-01 challenge types are plaintext as well).

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

Re: [Acme] ALPN based TLS challenge

[Martin Thomson]

Now is probably the time to publish in internet-draft form:
https://datatracker.ietf.org/submit/

On Fri, Feb 23, 2018 at 12:48 PM, Roland Bracewell Shoemaker
 wrote:
> Hey all,
>
> After the issues with the SNI based TLS challenges were discovered there was 
> interest from a number of parties in developing another challenge that did 
> validation at the TLS layer. After some discussion about possibilities we’ve 
> come up with a new challenge type based on ALPN which we believe provides the 
> required security properties which the SNI based methods did not have.
>
> I’ve attached the rough draft of a document which defines this new method and 
> lays out the security considerations and design rationale for it. Given the 
> interest in getting a new TLS method specified would the WG chairs be 
> amenable to directly adopting this as a WG work product (assuming there is 
> consensus on list) so that we can start work on it or is it required to be 
> submitted as a individual draft first?
>
> Happy to field any questions about the details. I’d also like to thank 
> everyone who provided initial input and editorial opinions on this.
>
> Thanks,
> Roland
>
>
> ___
> 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] WGLC comments: draft-ietf-acme-tls-alpn-01 (Re: Confirming consensus)

[Martin Thomson]

On Thu, Aug 9, 2018 at 12:32 PM Sean Turner  wrote:
> 5) General: Okay so I’m no cryptographer, but should the hash algorithm used 
> in the challenge correspond to the hash algorithm used in the PRF/HKDF?  I 
> mean if I’m going to use TLS 1.3 and TLS_AES_256_GCM_SHA384 should I really 
> use SHA-256?

The same input isn't fed into two different PRFs, so I believe that this is OK.

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

Re: [Acme] nomenclature: “POST-as-GET”

[Martin Thomson]

On Wed, Sep 5, 2018 at 4:33 AM Richard Barnes  wrote:
>> 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.

One does not merely define a new verb.  The limited set of verbs in
HTTP is a feature, not a bug.  That means occasionally using POST in
ways that are suboptimal, but the alternative is struggling with an
unrecognized verb.

There is a proposal to add something with similar semantics to what
you describe, in SEARCH [1], but that has not been successful and it's
been a long time.  Don't kill ACME on this mountain.  Use POST and
learn to like it.

(Arguably, header fields are the way to deal with this class of
problem, but then we're into request signing territory and ACME
decided a long time ago not to tilt at that particular windmill.)

[1] https://tools.ietf.org/html/draft-snell-search-method-00 - which
died only partly because it conflicted with RFC 5323...

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

Re: [Acme] Certificate chains including roots

[Martin Thomson]

The usage model I think we should aim for is where chains are used
as-is.  For instance, the chain is fed straight to the HTTPS server.
There is reasonably strong advice against sending trust anchor
certificates over the wire, and most software simply spools out
everything it is given.

I thought that we already had this discussion and concluded that roots
wouldn't be included.  That's consistent with the above.

Obviously that would leave this open to some discretion, but that's
OK.  For instance, during the period that a new CA has a
cross-signature on their root, they might include their own anchor for
maximum compatibility, but they might phase that out over time.  But
the CA is in a reasonable position to know when to move, and it isn't
as though this would prevent clients from adding or removing as they
see fit.

On Mon, Mar 12, 2018 at 3:14 PM, Jörn Heissler
 wrote:
> On Mon, Mar 12, 2018 at 16:01:24 +0100, Philipp Junghannß wrote:
>> But isn't the point of this proposal that the client CANNOT be expected
>> knowing the root like with DANE/TLSA'd servers with a custom root or
>> whatever?
>
> I must admit that I'm not very familiar with DANE.
>
> What would be a typical use case where you use ACME but you don't
> already know the root cert?
>
> ___
> 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] Certificate chains including roots

[Martin Thomson]

On Wed, Mar 14, 2018 at 9:23 PM, Jacob Hoffman-Andrews  wrote:
> On 03/12/2018 05:25 AM, Hugo Landau wrote:
>>   3. Clarify the specification to state that the root certificate must
>>  not appear in the chain, and that roots must be retrieved using the
>>  AIA URL inside the final certificate in the chain if it is needed.
>>  This minimises the chance of clients for non-DANE applications
>>  messing up and provides a viable method for discovery of the root
>>  CA for applications which need it.
> This seems fine to me.

MUST NOT is too strong.  Advise against it in the same way that TLS
does.  Even point to TLS.

Adding a note that when intended for a particular use (such as for
securing HTTPS), the chain that is provided should be directly usable
in that context and might need some assumptions about what relying
parties in that context need.

Don't require AIA or even use it.  It's a mess and not widely
deployed.  It's mostly just a waste of bytes - it's not like you can
remove it from a certificate once added (sure, if your intermediate
has it, then that's fine, but I'd content that this is a mistake).
You could use an "up" link relation (or whatever we decided works for
that) on the response if you feel that providing a link to the root is
necessary.

> To push a little more on why it's required, though: In DANE, you might
> indicate a trust anchor in your records. Presumably that trust anchor
> could be either a self-signed root, or an intermediate issuer
> certificate, right?

DANE adds a whole new dimension to this problem.  I think that if the
expectation is that DANE is used, then the server will need to be told
about this so that it can adjust as needed.  Often that means a
shorter chain.  However, I think that this sort of optimization is an
extension and doesn't really belong in the core spec (i.e., ship the
damned thing already and stop messing with it).

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

Re: [Acme] Specify which JWS serialization is used

[Martin Thomson]

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 with a
> content type, and a series of ACME-specific restrictions on root JWS and
> nested JWS instances.  A "root JWS" is a JWS used to encapsulate an entire
> ACME request payload, and a "nested JWS" is a JWS contained within the ACME
> request payload (such as the "externalAccountBinding" described in
> {{external-account-binding}} or the "key-change" object described in
> {{account-key-roll-over}}). Below are the JWS serialization formats that
> are defined for use in ACME:
>
> [same list as before but with the default format coming first]
>
> If no Content-Type is provided, the default serialization type is [insert
> selected default here]. Servers MUST support [insert selected default
> here]. [NOTE: If a JSON format is selected as the default, say that a
> server SHOULD support the other JSON format.] A server MAY support
> additional serializations, such as [insert serialization(s) not picked
> here], by including a "supportedSerializations" field in the directory
> "meta" object as described in {{directory}}.
>
> If a server receives a request using a serialization it does not support,
> the server MUST send a response with HTTP status code 415 (Unacceptable
> Media Type) and a problem document with error type
> "unsupportedSerialization". This problem document SHOULD contain a
> "supportedSerializations" array of strings indicating the acceptable
> serialization content types.
>
> [TODO: If a client uses the General JSON Serialization but it turns out
> the server only supports the Flattened JSON Serialization (or vice-versa),
> explain that a 415 response indicates that the client will need to switch
> JSON formats]
>
> [TODO: Insert a sentence or two specifying what happens if a supported
> serialization is used but the serialization is malformed? Should this be
> 400 Bad Request + malformed error code + supportedSerializations?]
>
> In the examples below, JWS objects are shown in the Flattened JSON
> serialization, with the protected header and payload expressed as
> base64url(content) instead of the actual base64-encoded value, so that the
> content is 

Re: [Acme] Specify which JWS serialization is used

[Martin Thomson]

There needs to be a stronger benefit demonstrated than this. As Richard
says, implementing flat serialization is near trivial. Rather than add more
complexity, settling on precisely one format solves the problem neatly.

On 5 Mar. 2018 02:43, "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 with a
content type, and a series of ACME-specific restrictions on root JWS and
nested JWS instances.  A "root JWS" is a JWS used to encapsulate an entire
ACME request payload, and a "nested JWS" is a JWS contained within the ACME
request payload (such as the "externalAccountBinding" described in
{{external-account-binding}} or the "key-change" object described in
{{account-key-roll-over}}). Below are the JWS serialization formats that
are defined for use in ACME:

[same list as before but with the default format coming first]

If no Content-Type is provided, the default serialization type is [insert
selected default here]. Servers MUST support [insert selected default
here]. [NOTE: If a JSON format is selected as the default, say that a
server SHOULD support the other JSON format.] A server MAY support
additional serializations, such as [insert serialization(s) not picked
here], by including a "supportedSerializations" field in the directory
"meta" object as described in {{directory}}.

If a server receives a request using a serialization it does not support,
the server MUST send a response with HTTP status code 415 (Unacceptable
Media Type) and a problem document with error type
"unsupportedSerialization". This problem document SHOULD contain a
"supportedSerializations" array of strings indicating the acceptable
serialization content types.

[TODO: If a client uses the General JSON Serialization but it turns out the
server only supports the Flattened JSON Serialization (or vice-versa),
explain that a 415 response indicates that the client will need to switch
JSON formats]

[TODO: Insert a sentence or two specifying what happens if a supported
serialization is used but the serialization is malformed? Should this be
400 Bad Request + malformed error code + supportedSerializations?]

In the examples below, JWS objects are shown in the Flattened JSON
serialization, with the protected header and payload expressed as
base64url(content) instead of the actual base64-encoded value, so that the
content is readable. [Example readability is a very high priority
regardless of which serialization format is actually chosen as the default,
and the current convention of Flattened JSON + base64url(content) is about
as readable as it gets, so I don't think any changes will need to be made
here]


On Sun, Mar 4, 2018 at 8:33 AM, Jörn Heissler 
wrote:

> On Sun, Mar 04, 2018 at 07:45:36 -0600, Logan Widick wrote:
> > Good catch. Should it be 415 (Unsupported Media Type) plus which of the
> > following (or which combination of the following):
> >
> >- A new problem document field (tentatively named
> >"supportedSerializations": an array of media type strings)?
> >- A new directory field (tentatively named "supportedSerializations":
> an
> >array of media type strings)?
> >   - Should this go in the directory's "meta" object, or in the
> >   directory object itself?
> >- A HTTP header?
> >- Something else?
>
> I like the directory 

Re: [Acme] Specify which JWS serialization is used

[Martin Thomson]

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 <r...@ipv.sx> 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 <martin.thom...@gmail.com>
> 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" <r...@ipv.sx> 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 <logan.wid...@gmail.com>
>> 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 with a
>>> content type, and a series of ACME-specific restrictions on root JWS and
>>> nested JWS instances.  A "root JWS" is a JWS used to encapsulate an entire
>>> ACME request payload, and a "nested JWS" is a JWS contained within the ACME
>>> request payload (such as the "externalAccountBinding" described in
>>> {{external-account-binding}} or the "key-change" object described in
>>> {{account-key-roll-over}}). Below are the JWS serialization formats that are
>>> defined for use in ACME:
>>>
>>> [same list as before but with the default format coming first]
>>>
>>> If no Content-Type is provided, the default serialization type is [insert
>>> selected default here]. Servers MUST support [insert selected default 

Re: [Acme] Specify which JWS serialization is used

[Martin Thomson]

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 <r...@ipv.sx> 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 <martin.thom...@gmail.com>
> 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 <r...@ipv.sx> 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
>> > <martin.thom...@gmail.com>
>> > 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" <r...@ipv.sx> 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 <logan.wid...@gmail.com>
>> >> 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,

Re: [Acme] Concerning alternative formats …

[Martin Thomson]

Sure.  Plenty of ways to do that.

If your primary concern is issuance, then you don't even need server
push, you can just long-poll.  In HTTP/1.1, that's gross because it
ties up a connection and has some disgusting keep-alive properties.
In h2 there is no opportunity cost to worry about, the connection
remains usable for other things while you wait.  (You can use
prefer:wait to control timing if you want a standards-based solution:
https://tools.ietf.org/html/rfc7240#section-4.3)

On Tue, Mar 6, 2018 at 9:27 AM, Richard Barnes  wrote:
> Thomson: Could h2 push replace some of the polling here?
>
> On Mon, Mar 5, 2018 at 4:50 PM, Felipe Gasper 
> wrote:
>>
>>
>> > 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] AD Review: draft-ietf-acme-ip-04

[Martin Thomson]

On Tue, Dec 25, 2018, at 07:32, Eric Rescorla wrote:
> IMPORTANT
> S 3.
> >  used to refer to fully qualified domain names.  If a ACME server
> >  wishes to request proof that a user controls a IPv4 or IPv6 address
> >  it MUST create an authorization with the identifier type "ip".  The
> >  value field of the identifier MUST contain the textual form of the
> >  address as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC4291]
> >  Section 2.2 for IPv6.
> 
> Are all three variants here valid?

I think that now is a good moment to mention RFC 5952.

I suspect that most implementations use something other than a canonical 
representation, and probably accept all valid formats, but maybe now is the 
time to tighten that down.

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

Re: [Acme] 2nd working group call for adoption

[Martin Thomson]

Just read it. Reasonable thing to specify.

Not sure why this doesn't talk about delegations of the domain and the effect 
that might have. That seems relevant. Though control over the parent implies 
control over delegations, it might be a consideration when setting policy.

Not sure why "domainNamespace" is used as the field when "subdomains" is 
shorter and easier to understand.

On Thu, Oct 14, 2021, at 23:16, 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

Re: [Acme] 2nd working group call for adoption

[Martin Thomson]

On Fri, Oct 15, 2021, at 18:00, Owen Friel (ofriel) wrote:
> Not sure why "domainNamespace" is used as the field when "subdomains" 
> is shorter and easier to understand.
>
>
> [ofriel] there was early discussion on the mailer about what exactly a 
> 'subdomain' meant. So we quoted the CA/B Browser baseline definitions 
> and used that terminology instead.  Note that the draft is not 
> restricted to web use cases, so basing terminology on CA/B is not by 
> any means mandatory. I have no strong preference on what we call the 
> field at all -  subdomains and namespaces are both used in the draft, 
> so happy to change to whatever is clearest.

RFC 8499:

   Subdomain:  "A domain is a subdomain of another domain if it is
  contained within that domain.

I found "namespaces" confusing.  I don't think we need to borrow CA/BF 
obfuscations.

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

Re: [Acme] Validation methods for alternative services and SVCB/HTTPS targets

[Martin Thomson]

On Fri, Oct 28, 2022, at 06:04, Ilari Liusvaara wrote:
> It looks like the proposed dns-account-01 method would be very useful
> here. The key problem of dns-01 here is that it only allows one
> persistent authorization, whereas dns-account-01 allows multiple.

So relying on another authorization is going to work in a lot of cases, so 
using this is probably a good place to start.

> The problem with coming up with variants of TLS-ALPN or whatever is that
> it would require hooking in CA/Browser Forum into defining a new
> validation method that can be used in the web.

This sounds right to me.  I'm not engaged in CA/BF, but I will give notice to 
those at Mozilla who are so that they are aware of this.  It seems like some 
amount of responsiveness to changes in HTTP resolution practices could 
eventually need to be addressed in CA/BF, but my sense is that the degree to 
which legacy clients need basic A/+CNAME support means that there is no 
real urgency here.

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

[Acme] Artart last call review of draft-ietf-acme-tls-alpn-06

[Martin Thomson via Datatracker]

Reviewer: Martin Thomson
Review result: Ready with Nits

This is a clear description of a simple protocol that addresses a well-defined
problem.  I didn't find any real issues, though I have some suggestions that
might improve the document a little.  My view is that publication without these
would still produce a useful RFC.

Suggestions:

The document should probably talk about minimum TLS versions and expected
algorithms.  I think that it would be enough to say TLS 1.2 minimum with the
mandatory cipher suites from that spec.  You might also want to require
certificates with a PKCS#1v1.5 RSASSA key (as much as those are terrible), but
to permit use and negotiation of other alternatives.  If your CA supports
ECDSA, I see no reason not to prepare an ECDSA certificate on that basis, but
that would be based on extra-textual knowledge, it's no guarantee of
interoperability.

Section 4
I have two suggestions here for making the properties you rely on with the
protocol clearer to readers.

You should explicitly say that the "acme-tls/1" protocol as negotiated here
does not carry application data, it only requires that the server provide
certificate-based authentication.  AND that the certificate-based
authentication provided uses an alternative method than that described in RFC
5280, even though it uses X.509 certificates.  Both of these are already
implicit in the text here, but I think that it would help to be very clear
about these as they are a little surprising ways to use TLS.

You might also want to explicitly point out that though the protocol does not
depend on the server providing a valid signature, or even that it successfully
complete the TLS handshake, these are both required by the protocol and a
validator MAY withhold authorization if the TLS handshake does not complete
successfully.  (This is implied in Step 4, but not explained.)

Nits:

Section 1
The history lesson in the appendix is useful.  It helps to articulate why the
design is this way.  However, I don't think that you need to spend a third of
the introduction on a reference to that historical information.  I'd cut that
paragraph entirely.

Section 3
https://www.quickanddirtytips.com/sites/default/files/styles/insert_large/public/images/937/use-utilize-pin.png?itok=Bt7A6RQq

Step 3: s/AMCE/ACME; this sentence is two with a comma-splice

Section 4
This is taste only, but I find the extra version decoration on these
identifiers unnecessary.  Decorate v2 if you are unfortunate enough to need one.

Section 5

The parallel list construction in this sentence is a little awkward:

   "This means that if User A registers Host A and User B registers Host B the
   server should not allow a TLS request using a SNI value for Host A to be
   served by User B or Host B to be served by User A."

The first part of this sentence is fine, but the second part "or Host B to be
served by User A" might be clearer if it said "or a TLS connection with a
server_name extension identifying Host B to be answered by User A."  Or similar.

Section 6.2
Please don't use uppercase for an identifier when the actual protocol is
identified using lowercase ASCII.  I know that RFC 7301 did this for HTTP/1.1,
but that was a confusing mistake that doesn't need to be propagated.

Section 7
This is not an appendix.  You can make appendices using `` in XML or by
moving the section under `---back` in kramdown-rfc2629.

The implication of this text is to say that this is a replacement for an
important part of ACME.  I would instead say that this is an iteration on an
earlier design that used the TLS server_name extension to carry the challenge. 
And that that earlier design was shown to have some serious issues in practice.

My understanding of the problem differs from what is described here though: the
problem - as I recall - was that this used high-entropy, generated values for
the server_name extension and an HTTP or absent ALPN identifier.  These names
might not have as strong a binding to the user that controlled the validated
portion of that name (the suffix) as desired.  Some servers would route these
SNI values to a "default" handler.  The "default" handler could be under the
control of any user; in fact, users could in some cases choose a name that
would greatly improve their chances of having their certificate used as a
default (e.g., a.example.host or z.example.host.  As formulated here,
particularly with the User A/Host B phrasing, you are almost implying that the
security property you rely on in the ALPN design doesn't hold.  As far as I'm
aware, that security property does hold because you are including exactly the
validated name in the SNI.


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