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
