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
I like using {} for the POST-as-GET payload as well.
Sincerely,
Logan Widick
On Tue, Sep 4, 2018, 12:26 Jacob Hoffman-Andrews wrote:
> New day, new thread for a specific issue I'd like to nail down quickly.
>
> > ISSUE 2: How should we signal that POST-as-GET request is different
> > from
On Tue, Sep 4, 2018 at 1:44 PM Felipe Gasper
wrote:
> FWIW, it seems to me like, if the HTTP verb being used is, in fact,
> “POST”, then a more appropriate term for the proposed fix for the identity
> correlation problem identified last week would be “GET-as-POST” rather than
> “POST-as-GET”.
>
FWIW, it seems to me like, if the HTTP verb being used is, in fact, “POST”,
then a more appropriate term for the proposed fix for the identity correlation
problem identified last week would be “GET-as-POST” rather than “POST-as-GET”.
“POST-as-GET” sounds to me like the actual HTTP verb is a
On 08/31/2018 03:08 PM, Richard Barnes wrote:
ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing
the privacy analysis?
Agreed we're solved on this.
ISSUE 2: How should we signal that POST-as-GET request is different
from other POST requests?
Started a separate thread on this.
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.
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
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.
Ergo, a CA **MUST** support SPF as validation method, both for sending and
receiving, and a ~ MUST be treated same as -,
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
