James,
"That way the ACME CA doesn’t need to know anything about the device
attestation."
No, the ACME CA would need to validate the JWT provided by the Device
Authority.
Regards,
Rifaat
On Fri, Jan 25, 2019 at 8:06 AM Rifaat Shekh-Yusef
wrote:
> Thanks for the review and feedback, James.
Thanks for the review and feedback, James.
See my reply inline below.
Regards,
Rifaat
On Thu, Jan 24, 2019 at 8:27 PM Manger, James <
james.h.man...@team.telstra.com> wrote:
> I’m confused about what is desired with
> draft-yusef-acme-3rd-party-device-attestation, but I think it may be quite
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
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
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 is authoritative for multiple identifier spaces (e.g.
>TNAuthList with
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 is authoritative for multiple identifier spaces (e.g.
TNAuthList with telephone numbers and service providers), while a Device
Authority is responsible
"Always be closing" :)
Or to cite a more ancient source:
"Quidquid facies, respice ad mortem"
"Whatever you do, contemplate death"
-- Seneca
On Thu, Jan 17, 2019 at 4:09 PM Salz, Rich wrote:
> Richard always wants to close WG’s. :) His views don’t necessarily
> reflect those of the AD’s or
Richard always wants to close WG’s. :) His views don’t necessarily reflect
those of the AD’s or Chairs or the WG itself. Don’t worry about it being more
than just one opinion of an involved person. :)
___
Acme mailing list
Acme@ietf.org
I would add that if this is just another token type, it might not be
necessary to keep the WG open for it. Good exercise for the secdispatch
process.
On Thu, Jan 17, 2019 at 12:49 Rifaat Shekh-Yusef
wrote:
> Thanks Richard,
>
> The redirection is not critical part, and your explanation makes
Thanks Richard,
The redirection is not critical part, and your explanation makes sense.
I looked at the "authority token" documents a while ago; I will take a look
again to see if I can align this document with that framework.
Regards,
Rifaat
On Thu, Jan 17, 2019 at 1:51 AM Richard Barnes
It seems like the core of this draft is identifier delegation. Namely, the
CA recognizes the DA as an authority for a certain identifier space (e.g.,
the first few octets of a MAC address), and the JWT delegates permission to
issue certificates for some identifier in that space to the Client.
Thanks Ilari,
Section 2.4 is a informative section that meant to provide a high level
view of the full flow.
Remember that the assumption is that the Client already has an account with
ACME and already proved it controls customer.com domain.
The first request in this flow will be the same as
On Wed, Jan 16, 2019 at 03:32:57PM -0500, Rifaat Shekh-Yusef wrote:
> All,
>
> I have just submitted new updated version to address the issues raised by
> Ilari and Ryan.
> I would appreciate any more reviews and comments.
>
> -- Forwarded message -
> Name:
13 matches
Mail list logo
