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

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 <rlb@ipv.sx> 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 <rifaat.ietf@gmail.com>
> 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 <rlb@ipv.sx> 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 <
>>> rifaat.ietf@gmail.com> 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: <internet-drafts@ietf.org>
>>>> 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 <rifaat.ietf@gmail.com>
>>>>
>>>>
>>>>
>>>> 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
>>>> Acme@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/acme
>>>>
>>>