Inline...
On Wed, Jan 23, 2019 at 3:07 PM Richard Barnes wrote:
> Inline.
>
> On Sun, Jan 20, 2019 at 3:04 PM Rifaat Shekh-Yusef
> wrote:
>
>> I looked at the TNAuthList draft, and as far as I understand, the
>> framework seems
>> a bit different from this proposal:
>>
>> 1. A Token Authority
Comments inline:
> On Dec 24, 2018, at 12:32 PM, Eric Rescorla wrote:
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4180
>
>
> IMPORTANT
> S 3.
> > used to refer to fully qualified domain names. If a ACME server
> > wishes to request proof that a
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
This seems fine to me. It's basically just a table entry, with some
description of how to use it.
--Richard
On Thu, Jan 24, 2019 at 9:26 AM Rob Stradling wrote:
> I realize it's very late for making non-editorial changes to
> draft-ietf-acme-acme, but I'd like to propose adding a new
I realize it's very late for making non-editorial changes to
draft-ietf-acme-acme, but I'd like to propose adding a new badPublicKey
error. This error would be returned by the server whenever it does not
support, or wishes to reject, a "jwk" public key supplied in a client's
request.
+1 - this seems like something we should have had already. Thanks for
catching & proposing the fix Rob.
On Thu, Jan 24, 2019 at 9:30 AM Richard Barnes wrote:
> This seems fine to me. It's basically just a table entry, with some
> description of how to use it.
>
> --Richard
>
> On Thu, Jan 24,
As WG co-chair, I am not thrilled with making this addition so very very late
in the process. If the WG wants to do it, we'd need (a) clear consensus and
(b) a quick approval from the IESG.
As an individual, I dislike putting "here's what's wrong with your key" in the
error message. For
On Thu, Jan 24, 2019 at 10:52 AM Salz, Rich wrote:
> As WG co-chair, I am not thrilled with making this addition so very very
> late in the process. If the WG wants to do it, we'd need (a) clear
> consensus and (b) a quick approval from the IESG.
>
Note that since the registration policy is
>
> As an individual, I dislike putting "here's what's wrong with your key" in
> the error message. For example, it encourages a thief to do "venue
> shopping" looking for a CA that will certify their stolen keypair.
>
I don't think this is a meaningful example. The server has to return some
kind
* Note that since the registration policy is "specification required",
doing this in an extension spec instead would not require the consent of the
IESG.
Right, which is how I prefer to see this move forward. Putting it into the
ACME doc, however, *does* require IESG approval.
* I
10 matches
Mail list logo
