Re: [Acme] Remove the hyphen from the acceptable character set for _acme-challenge TXT records.

[Manger, James]

An Acme CA may choose the dns-01 challenge token, but what goes in the DNS TXT 
record is base64url(SHA-256(f(token and account key))).
So to avoid hyphens in that result the CA would need to: pick a random token; 
do the hash & base64url calculations; then repeat with a new random token if 
any hyphens are present. It will only take 2 tries on average ; - )

--
James Manger

-Original Message-
From: Acme  On Behalf Of Michael Richardson
Sent: Thursday, 26 November 2020 9:37 AM
To: Mark Tomlin ; acme@ietf.org
Subject: Re: [Acme] Remove the hyphen from the acceptable character set for 
_acme-challenge TXT records.

[External Email] This email was sent from outside the organisation – be 
cautious, particularly with links and attachments.

Mark Tomlin  wrote:
> I have a bit of a feature request for you all. It's actually to remove
> the hyphen from the TXT records to make it easier to copy and paste into a
> DNS server record. Here's my scenario. I ran the following command on my
> server (Ubuntu 20.04) that as you can see has cerbot on it and a large
> number of domains to cover.

It is annoying, and I've run into the same problem as well.
The challenge is a base64url encoded (RFC4648) nonce.  It is preferred by web 
programmers because it does not use + or /, which are special in URLs.
The base64 alphabet doesn't use -, but does use + and /, but which would copy 
and paste better.

The format and contents of the nonce are not mandated by RFC8555, so 
LetsEncrypt change this in many different ways.
It would be a unilateral decision on the ACME server only.

I actually think that BASE32 encoding would probably better: you could probably 
write a pull-request to the letencrypt code base to do this.
I don't know how they would feel about this, but it would be worth learning.

> Please deploy a DNS TXT record under the name
> _acme-challenge.mimocad.io with the following value:

> 6-K6v7VjtVpGhJk4d6Zx8qxsg6JFUZbGnnr-bDpKpSc

What annoyed me here when renewing a system with 10 different aliases is that I 
don't know when I've gotten to the last one.  I should be shown all
10 at the same time, so that I can put them all in place, and then reload the 
zone.  Instead, I count (badly), reload the zone too late or too soon...
Even better if they add the entire DNS presentation lines so that I could 
copy the entire set.
But, again, this is a client code issue, and not a protocol issue.

I have since bit the bullet and gotten nsupdate to do the right thing, and it 
now autorenews on it's own, as Ghod intended.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME subdomains

[Manger, James]

>> There’s a lot of mixing of example.org and 
>> example.com here, in ways I’m having trouble making 
>> sense of. I just wanted to confirm those were typos, since we have recently 
>> seen some confusion around this space.

> I followed the patterns used in RFC8555 which consistently uses example.com 
> as the ACME server base domain and example.org as the client certificate 
> identifier base domain, but yes Ryan I did find this a source of confusion 
> too when reading ACME.
>
> For clarity, I replaced all example.com with acmeserver.com, and left all the 
> client identifiers as example.org.

https://tools.ietf.org/html/draft-friel-acme-subdomains-02 and 
https://github.com/upros/acme-subdomains/blob/master/draft-friel-acme-subdomains.md
 don’t seem to follow RFC 8555’s convention at all, which could be the 
confusion.

Trampling on another arbitrary domain name – acmeserver.com – is worse; unless 
you can think of an additional domain name to reserve with an update to RFC 
6761 Special-Use Domain Names.

Stick with the RFC 8555 ACME convention. Maybe tweak it to be, say, 
site.example.org and ca.example.com if that is clearer.
Plus a sentence stating the convention used would help.

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

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

[Manger, James]

I’m confused about what is desired with 
draft-yusef-acme-3rd-party-device-attestation, but I think it may be quite 
different from what draft-ietf-acme-authority-token offers. Here’s my guess:

draft-ietf-acme-authority-token is designed to issue certs for namespaces other 
than domain names, eg for phone numbers. The CA trusts another authority to 
vouch for that namespace.

draft-yusef-acme-3rd-party-device-attestation is designed to issue certs for a 
domain name (as per normal Acme). The cert will be for a specific device whose 
serial number (eg MAC address) the domain-owner knows. The device manufacturer 
can vouch for device keys associated with that serial number.
Curiously, the protocol flow in draft-yusef-acme-3rd-party-device-attestation 
doesn’t seem to involve the device at all – only the domain-owner (client), 
manufacturer, and CA. But surely the device needs to provide the CSR?

It sounds like the client (domain-owner) should be able to confirm the correct 
device is involved (by talking to the device and manufacturer) before sending a 
normal ACME request. That way the ACME CA doesn’t need to know anything about 
the device attestation.

--
James Manger
+61 4 1754 1870
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Manger, James]

>> base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

> base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"

“A” is %x41 (not %x40)

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

Re: [Acme] Implicit vs. explicit keys (was Re: Unparallelizing roll-over)

[Manger, James]

On Sun, Aug 21, 2016 at 8:32 PM, Jacob Hoffman-Andrews 
> wrote:
On 08/21/2016 04:31 PM, Richard Barnes wrote:
> How about this as a compromise proposal: Have the JWS header contain
> *both* the account URL and the account public key.  That way you get
> fast rejection based on crypto failures, and you also get protection
> against any issues related to relying on public keys alone.
This doesn't achieve the goal of making sure that ACME servers are
validating based on account data they already have, rather than
validating based on a key provided in the request.

>What do you mean by "validating"?
>There are two types of validation to do here:
>1. Validating that the signature on the message is good
>2. Validating that the key belongs to a the right account for this request
>
>You can do the first of these without any knowledge of the account status of a 
>key.  Doesn't require any database lookup if you provide the key in >the 
>header.  There's no harm to doing this validation without knowing whether the 
>key is good, and there's benefit in rejecting bad signatures quickly.


The point is that if you: take an account id from message → lookup account → 
use public key from account to verify signature; then it is hard to see how an 
implementer can get #2 wrong. But you have to do the DB lookup before the 
crypto verification.

Richard’s alternative approach takes a public key from a message and tries to 
match that to a public key in an account. That should work, but it is less 
clear that there are not easy implementer traps. Matching keys is less obvious. 
How to do it isn’t specified. You could calculate JWK Thumbprints [RFC7638] and 
match those strings. Thumbprints ignore optional fields; hopefully that’s okay. 
Thumbprints can’t be relied on to be unique (eg shouldn’t be used in a 
blacklist); hopefully Acme implementations only need them to be unambiguous, 
not unique, for security. I hope an implementation doesn’t assume a “kid” 
(key-id) provided by a client is a thumbprint.

Having both (public key and account-id) in a message raises the risk that a 
sloppy implementation verifies with the former, does the lookup with the 
latter, then fails to properly link the two.

--
James Manger
___
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

[Manger, James]

>> Ideally, it [Let's Encrypt] would use the IP of the 
>> requester (of course only after it has verified that the IP is in the
>> DNS) or allow the requester to specify a preferred IP.

This is quite a sensible feature request from Jonas. It supports multiple 
servers for a domain while encouraging keys that are tied to a single piece of 
hardware, without adding extra coordination requirements. It doesn't feel too 
onerous for CAs to implement.

> There's a fairly good solution available with the current protocol, which is 
> to serve a (long lived) redirect from /.well-known/acme-challenge/ on all of 
> the servers to a different URL that is always answered by the machine you run 
> an ACME client on.

This redirect-based workaround feels far from ideal. It assumes 1 server does 
all the ACME bits, which discourages per-hardware keys. It requires more 
coordination between servers (1 is different; others need its IP; need some 
extra mechanism to distribute key+cert once issued). Section 9.2 "Integrity of 
Authorizations" [draft-ietf-acme-acme-01] warns that an ACME CA following 
redirects can be risky as a web site might have a catch-all redirect rule. Even 
worse, the spec hints that CAs might not (or must not?) follow redirects at all 
due to the risk when it says: "suppose an ACME server follows HTTP redirects in 
Simple HTTP validation…".

App-level redirects might be necessary to cope with some load balancing 
schemes, but specifying that an ACME server must prefer the requester's IP or a 
specified IP from the A/ records DNS returns would still be useful.

--
James Manger


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ryan Pendleton
Sent: Friday, 4 December 2015 8:53 PM

Personally, I think that's a more appropriate approach.

Even if a protocol change was made that allowed an ACME client to pin the 
challenge to a certain IP address, the requested IP may not always be returned 
by the authoritative DNS server. Any type of latency, geo or weighted routing 
algorithm could potentially get in the way.


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Peter Eckersley
Sent: Friday, 4 December 2015 7:46 PM
To: Jonas Wielicki 
Cc: acme@ietf.org
Subject: Re: [Acme] Support for domains with redundant but not immediately 
synchronized servers

There's a fairly good solution available with the current protocol, which is to 
serve a (long lived) redirect from /.well-known/acme-challenge/ on all of the 
servers to a different URL that is always answered by the machine you run an 
ACME client on.

Are there any cases where that is sufficiently unworkable to warrant a protocol 
change?


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Jacob Hoffman-Andrews
Sent: Friday, 4 December 2015 10:27 AM

I think there are a few possible approaches to domain validation for hostnames 
that resolve to multiple IP addresses:

1) It is sufficient to deploy a challenge response on any IP address.
2) The challenge response must be deployed on all IP addresses.
3) The server tries one deterministic IP address and succeeds or fails based on 
whether the challenge is deployed there.

Let's Encrypt currently does (3), but it's probably the worst of both worlds 
and we should fix it.

Arguably (2) is the most secure, since a single-machine compromise isn't 
sufficient to issue a certificate.

And (1) is the easiest and most user-friendly. I think it's also similar to 
existing practice in the wild.

Jonas, security-wise your proposal is equivalent to (1). Rather than adding a 
preferred IP address to the spec, why not specif that ACME servers SHOULD 
implement (1)? Alternately we could state in the spec that the choice of IP is 
a policy choice of the CA, and lay out the two most reasonable options (1 and 
2).

On Mon, Nov 30, 2015 at 06:17:21PM +0100, Jonas Wielicki wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi list,
> 
> I have asked this in the IRC and was pointed to this mailing list. I 
> tried to get a certificate for klausurschokola.de via Let’s Encrypt 
> during the currently running limited beta (we have the domain 
> whitelisted). The name has the following address records:
> 
> 1800  IN  A   176.9.101.187
> 1800  IN  A   217.115.12.71
> 
> (in addition, there is one  record for each of the machines 
> addressed by the A records)
> 
> As you can see, two different machines are addressed. Those are 
> physically separated machines with different main administrators.
> Both are pulling their web content from the same source, but it is not 
> supposed to be dynamic, so there is no "fast" (order of seconds) way 
> to mirror the content.
> 
> Our wish would be to be able to use different private keys and 
> certificates for both hosts, and renew these independently from the 
> other host. We thought that this would be possible using Let’s Encrypt.
> 
> The