Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Rifaat Shekh-Yusef <[e-mail]>]

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 <[e-mail]> wrote:

> 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.
>
> Given that, it seems to me like this could fit under the rubric of the
> "authority token" challenge.  If you were to do what this draft wants to do
> with that framework, the Client would have two separate interactions -- an
> OAuth interaction with the DA to get a token, then an ACME interaction with
> the CA to issue the certificate.  The only specification needed would be to
> specify the identifier and token type, as has been done for TNAuthList [2].
>
> The only thing that would then be missing with regard to this draft is
> that the CA wouldn't provide the redirect to the DA.  Whether that makes
> sense depends on the use case, but I suspect that in most cases it does
> not.  The design in the draft presumes there's a single DA per identifier,
> and that the CA keeps a mapping table from possible identifiers to DAs.
> That seems unlikely for most identifier spaces and most CAs with reasonably
> broad coverage.  So losing this property of the draft doesn't seem like a
> big issue.
>
> So net/net, I think this draft should be restructured along the lines of
> [2], to just define a token type and maybe an identifier type.
>
> --Richard
>
> [1] https://tools.ietf.org/html/draft-ietf-acme-authority-token
> [2]
> https://tools.ietf.org/wg/acme/draft-ietf-acme-authority-token-tnauthlist/
>
> On Wed, Jan 16, 2019 at 12:33 PM Rifaat Shekh-Yusef <[e-mail]>
> 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.
>>
>> Regards,
>>  Rifaat
>>
>>
>> ---------- Forwarded message ---------
>> From: <[e-mail]>
>> Date: Wed, Jan 16, 2019 at 3:28 PM
>> Subject: New Version Notification for
>> draft-yusef-acme-3rd-party-device-attestation-01.txt
>> To: Rifaat Shekh-Yusef <[e-mail]>
>>
>>
>>
>> A new version of I-D, draft-yusef-acme-3rd-party-device-attestation-01.txt
>> has been successfully submitted by Rifaat Shekh-Yusef and posted to the
>> IETF repository.
>>
>> Name:           draft-yusef-acme-3rd-party-device-attestation
>> Revision:       01
>> Title:          Third-Party Device Attestation for ACME
>> Document date:  2019-01-16
>> Group:          Individual Submission
>> Pages:          9
>> URL:
>> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/
>> Htmlized:
>> https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-yusef-acme-3rd-party-device-attestation
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-yusef-acme-3rd-party-device-attestation-01
>>
>> Abstract:
>>    This document defines a Third-Party Device Attestation for ACME
>>    mechanism to allow the ACME CA to delegate some of its authentication
>>    and authorization functions to a separate trusted entity, to automate
>>    the issuance of certificates to devices.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>