support for RFC8823(s/mime)

[orangepizza]

created for s/mime certificate for smime (RFC8823): problem is for email-reply-00 challenge solver really can't return fast enough for interfacee expections, because acme server need to send challenge mail to us before client can do any solving. a dummy solver and do actual solving+waiting in waiter? would that work?

[mholt]

Thanks for the PR. This change looks good!

problem is for email-reply-00 challenge solver really can't return fast enough for interfacee expections, because acme server need to send challenge mail to us before client can do any solving. a dummy solver and do actual solving+waiting in waiter? would that work?

Some solvers, like the DNS challenge solver, do take a while sometimes -- several minutes, even more. ACMEz is designed to support slow solvers by having the Present and Wait methods separate: as long as present is fast, wait can be slow.

I'd love to see your implementation of an email solver!

[orangepizza]

there is decent chance for present can fail because it called right after challenge created, but server side challenge email doesn't arrive to our inbox yet. that's why I think I need to waiter do the actual presenting or presenter will lock a bit like (10s was enough for most but not hard limit) until we find the mail

[orangepizza]

and now just notice 8822 acme server will give new from address as part of challenge object, should've used it too

[mholt]

@orangepizza Gentle ping, in case you missed my above comments ^ :+1: Thanks!

[orangepizza]

@orangepizza Gentle ping, in case you missed my above comments ^ 👍 Thanks!

sorry not yet Showable state, imap idle could reply just about anything. (if nooy need to golang see my fork of acme-tiny, email) will reply back when it's done. not sure if present being stuck about 10s so mail server sent be would be allowed, or throw goroutine be better(which closed by waiter)

[mholt]

Hey @orangepizza Sorry for the trouble, but there's now a merge conflict -- want to resolve that and I can take another look at this?

[mholt]

Awesome, this is starting to look good! But I noticed that the "From" field isn't used anywhere...

[orangepizza]

th

Awesome, this is starting to look good! But I noticed that the "From" field isn't used anywhere...

what field will given to Email client to recieve/reply challange mail: I don't think this lib will want implement entire SMTP/IMAP in it.

[orangepizza]

maybe I should make email builder so write entire email for it

[mholt]

I think that's what I don't really understand. Can you maybe give a simple example of how that field is used / why it is useful, then?

[orangepizza]

email reply challange involves receiving another token from email acme server send, and reply to that address. as they need to know which mail acme will send from, it's the parameter to search our inbox.

[orangepizza]

I added mailbuilder for response, I hope this helps you understand

[mholt]

Thanks! This is looking much better. When I have a moment I'll push some polish to the comments and such, and then probably merge this in.

[orangepizza]

that was oversight of RFC8823 writters,

"The From header field MUST be the same email address as specified in the "from" field of the challenge object."

and exemple challange object https://www.rfc-editor.org/rfc/rfc8823.html#section-3-6.3.1

{
  "type": "email-reply-00",
  "url": ["https://example.com/acme/chall/ABprV_B7yEyA4f"](https://example.com/acme/chall/ABprV_B7yEyA4f),
  "from": ["[email protected]"](mailto:[email protected]),
  "token": "DGyRejmCefe7v4NfDGDKfA"
}

however there is no from field in rfc8555 as it doens't send email and they don't written explicitly they added a field on challenge object from there

P.S replying github notification Email doesn't send reply here 😢

[mholt]

@orangepizza Ok, thanks -- so it looks like the actual problem is with the RFC, and this implementation seems to be a hack to work around an oversight with the RFC.

I think at this point the best thing to do is to post on the relevant IETF mailing list for discussing problems with RFCs and see if the actual authors of the document have any input on this. I'd like to be assured by the standards committee that this approach is the expected way to do things.

If, after that, it seems like this is the generally accepted way to implement the spec, then I'm happy to merge this. Overall the change looks fine to me. I just want to be extra sure about this one because we strive to be spec compliant and elegant as much as possible.

[mholt]

@orangepizza I'd be interested in wrapping this up if you're able to help. :) I'm about to push a v2 of this library with a slightly different API for the acmez package, and I know that the S/MIME ACME spec has made progress in the last ~year. Would you be willing to help finish this up after I push the v2 changes?

[orangepizza]

yes I am willing to finish this, when api will updated?

but I was not really tracking acme wg update about smime. (and I think I actually missed this paragraph last time, which would've whole need to update RFC thing nothing burger):

The ACME server responds to the POST request, including an "authorizations" URL for the requested email address. The ACME client then retrieves information about the corresponding "email-reply-00" challenge, as specified in Section 7.5 of [RFC8555]. The "token" field of the corresponding challenge object (from the "challenges" array) contains token-part2. token-part2 should contain at least 128 bits of entropy. The "type" field of the challenge object is "email-reply-00". The challenge object also contains the "from" field, with the email address that would be used in the From header field of the "challenge" email message (see the next step

[mholt]

@orangepizza I just pushed my v2 branch here: #23

Only the high-level API is changing, to make it easier to support more ACME extensions down the road.

[mholt]

@orangepizza I've merged the v2 changes into master, if you are interested in polishing S/MIME support :smiley:

[mholt]

@orangepizza Any interest in finishing this up? Sorry for the suuuuper long feedback loop (a couple years)

[orangepizza]

I think it's able to merge as-is, most of difficult part of email-reply-00 is grep:replying mail but that (filling challenge resource) is out of scope of this repository: one tricky part is email solver can't satisfy present()'s return quickly requirement: it must wait until acme server sends challenge email to us, so present() must be mock and actual solver need to be waiter() : I commented it solver.go present function but not sure it's best place

[mholt]

@hslatman Since I think you know more about this than I do, would you be willing/able to give it one more review? Once it has your approval I will be happy to iron out any details and see about merging it :)

[hslatman]

@mholt will do. I can probably squeeze it in this week. I'll also retry it in my POC.

[mholt]

Thank you! No rush, just grateful for your help.

[hslatman]

@mholt as mentioned in the commit comment, I'm about to open a PR with some fixes and a test.

[mholt]

Awesome. Thank you so much.

[hslatman]

@mholt PR is up: https://github.com/mholt/acmez/pull/25. It changes some of the behavior of the reply / key authorization behavior that were changed in the last few commits of this PR.