Re: [Acme] I-D Action: draft-ietf-acme-email-smime-05.txt

2019-07-15 Thread Gerd v. Egidy
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

Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt

2018-09-04 Thread Gerd v. Egidy
Hi Alexey, > > SMTP does allow choosing an arbitrary "From:" address, so just being able > > to send an email with a specific "From:" address alone doesn't prove > > anything. > This is true, the document needs to add some text about some form of > validation. Possibly DKIM/DMARC. fair enough. >

Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt

2018-09-04 Thread Gerd v. Egidy
Hi Sebastian, > I think SPF / DKIM is more of a suitable method of verifying authenticity > for mails, since these can be verifyed automatically by most email server > software without any plugins. For servers yes, but for email clients the opposite is true. Most clients already automatically ve

Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt

2018-09-04 Thread Gerd v. Egidy
Hi Alexey, thanks for working on the "email-reply-00" challenge. I would very much welcome a good mechanism to automatically distribute certificates for use with S/MIME. I have two questions / suggestions to your proposal: 3.2. ACME response email - You suggest to sen

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

2018-01-12 Thread Gerd v. Egidy
> > I think you also need: > > > > - A user is able to trick the server into serving his document root as > > default vhost > > > > - The webserver serves the default tls vhost, even if the CA requested a > > specific vhost via SNI > > Well, I think both are impiled by default vhost. The first

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

2018-01-12 Thread Gerd v. Egidy
> That is still vulernable to default-vhost issues if: > > - The hoster does not explicitly reserve default vhost (I have seen that > kind of behavior with http:// too). > - The hoster lets customers upload arbitrary certificates. I think you also need: - A user is able to trick the server int

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

2018-01-12 Thread Gerd v. Egidy
> I did want to say that if an acceptable mechanism is found in this manner, > it does help with some but not all in-band TLS validation mechanisms. It > works for web server cases. It does not fully replace the mechanisms of > the TLS-SNI sort because it would not work for other protocols runnin

[Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

2018-01-12 Thread Gerd v. Egidy
Hi, I've seen the proposal of Jonathan Rudenberg in [1] to use ALPN to fix the recently discovered problems with the TLS-SNI challenge [2]. While I think the usage of ALPN will fix the problem at hand, requiring support for ALPN on the frontend web servers, accelerators and so on at big webhost