[Acme] orders, authorizations, and identifiers (oh my)
Hi all, The new RFC (8555) states (on p26), for order objects, that a 1:1 relationship may not exist between an order’s identifiers and its authzs. Given that each authz object contains exactly 1 identifier, how would this play out for CAs that accept authz against a base domain as substitutive for authz on a subdomain? Consider an order to the hypothetical “AwesomeSSL” CA for example.com and www.example.com. AwesomeSSL considers authz against “example.com” to implicitly demonstrate control over “www.example.com”. Since the order requires successful authz for both domains, and (for AwesomeSSL) authz for “example.com” suffices for both domains, having a separate authz against “www” is superfluous. So it would be reasonable for this order to contain a single authz … and would that authz’s identifier be just “example.com”, then? Thus that authz object would not reference “www”, even though it is that domain’s corresponding authz object? Or would a client be accountable for implementing a “best-match authz” lookup to determine which authz corresponds to a given domain? Thank you! -Felipe Gasper Mississauga, Ontario ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] .well-known for dns challenges
This seems like a clever idea! As Ted said, .well-known probably isn't the right directory for it. If you put something in .well-known, that suggests you plan to standardize it and register it with IANA. I'll also note that you may have a bootstrapping problem: Assuming that you verify certificates on those polling requests to your web server, this solution won't work before you've actually issued your first certificate. Similarly, if there's every a problem that results in your live certificate expiring, this process would fail. It's also worth noting that Let's Encrypt requires DNS challenges for wildcards because they demonstrate more control over the domain namespace, and are less vulnerable to temporary hacks of the web server. You fully control the namespace, so you definitely have the ability to delegate that control in any way you see fit. Just keep in mind that this allows someone with temporary access to your nameserver to get a more powerful wildcard certificate than they otherwise would be able to. If you wanted to add some more security, you could narrow the scope of accepted certificates on the polling connection to your web host, or (even better) have some file-level signing of the fetched JSON. Since you control both sides, an HMAC (rather than a public key signature) would suffice. Lastly, have you seen acme-dns? This might be another way to accomplish the same thing, and has the advantage that more people are using it and therefore more likely to find bugs. https://github.com/joohoi/acme-dns ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] .well-known for dns challenges
Howdy, A reply in-line. On Sun, Jul 14, 2019 at 2:07 PM Stephen Farrell wrote: > > Hiya, > > I've a couple of questions as to 1) whether there are > any security issues with a thing I've done, (described > below) and 2) if it'd be worthwhile documenting something > like this. > > I've been working on encrypted SNI and as part of that > have built a test server. It seems sensible that some > web sites using ESNI might use wildcard certificates > so the DNS names that will be encrypted SNI values > don't need to appear in e.g. CT logs. So that's what > I've done. For wildcard certs, the CA I'm using > (letsencrypt) requires DNS challenges. > > In my setup, I don't have an API that allows the web > server to write to the DNS. Many web server setups > might have such an API, but I suspect many others are > like mine, and do not. Instead I have a separate > "zone factory" machine that manages zone files and can > poll the web server to see if there are any new DNS > challenges that need publishing whenever a wildcard > cert is due for renewal. The zone factory then takes > care of updating the zone, DNSSEC re-signing, AXFR > etc. > > What I've done is setup weekly cronjobs on the web server > and the zone factory machine, so when a wildcard cert > needs renewing and the CA sends some new DNS challenges > for the wildcard cert, I have the web server put those > in a JSON file that can be retrieved at: > >https://$DOMAIN/.well-known/acme/dhs-challenges > > The zone factory polls (a few mins later) for new content > at the above URL, and if there is and all looks good, > updates the zone to put TXT RRs at _acme-challenge.$DOMAIN. > > So, if I were personally configuring a similar system, I would avoid ..well-known, because it makes the information available to anyone who polls for it. That gives information to an attacker about when the renewals are occurring and what the challenges are. They still need to successfully mount an attack to make use of it, but I don't see the reason to put that in a publicly accessible director. I would probably personally use rsync of a directory with a similar check. If I had to use HTTPS for some reason, I would probably put it in a directory which required a distinct authorization from any other data on the web site and pull it that. The rest of this flow looks fine. A few minutes after that's done the web server (via a > another cronjob) checks if the correct new values have > been published in the DNS, and once it sees that's been > done, it finishes off the ACME renewal process with the > CA. > > Note that I'd be entirely happy to change the URL above > and/or the syntactic-sugar around the content expected to > be found there if there were a desire to document this. > > If you did document this, I would suggest modifying it as above. I'm not personally sure that this is any value to making the directory a standard. Just an initial reaction, and I may be missing a goal of the set-up here, Ted > As it happens, I had more or less the same issue with > updating ESNIKeys, and wrote up [1] for that. A read of > that short draft might provide more background if the > above's not clear. > > So, again, I'm wondering if there're any security issues > with doing this - it seems ok for my use-case, but maybe > there're downsides if it were done in other situations, > or maybe I'm being dim and missing something obvious;-) > > And secondly, I wonder if it'd be worth documenting it > and registering some new .well-known value for this. > > Thanks in advance, > S. > > [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni > ___ > 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-email-smime-05.txt
Hi Alexey, thanks for continuing your work on the smime draft. > 1. Do we need to handle text/html or multipart/alternative in email > challenge? Simplicity suggests "no". However, for automated > processing it might be better to use at least multipart/mixed > with a special MIME type. hmm. I guess with "automated processing" you mean an acme client on the user side. How would a multipart/mixed with a special MIME type help implementing the client? The client just needs to detect the challenge email and extract from the Subject:-Header. What other data, that could be in the part with the special mime type, would help implementing such a client? An ACME CA might want to include multipart/alternative and text/html to present nicely formatted usage instructions to the user when the ACME client is not integrated into the MUA. Automated clients should not be confused by such messages. The same is true for the challenge response: When the user manully copies the response from his ACME client program into his regular MUA, the MUA may compose a multipart/alternative mail with text/ html and text/plain or even just text/html. Also some company disclaimers and so on could be added automatically. How about using something like in RFC 7468? -BEGIN ACME RESPONSE- LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy jxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9 fm21mqTI -END ACME RESPONSE- This would allow the ACME server to extract the relevant data from most of such emails by stripping all html tags and ignoring everything outside the BEGIN/END block. We also should not force the response email to use a subject of "Re: ACME: ", just "ACME: " because MUAs with non- english language settings may use something else than "Re:" to denote a reply. Kind regards, Gerd ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
