Why would you close a an appropriate WG to deal with this, and send us to secdispatch?
On Thu, Jan 17, 2019 at 3:45 PM Richard Barnes <[email protected]> wrote: > 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 <[email protected]> > wrote: > >> 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 <[email protected]> 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 < >>> [email protected]> 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: <[email protected]> >>>> 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 <[email protected]> >>>> >>>> >>>> >>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
