Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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. > 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 >> 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 for phone numbers. The CA trusts another >> authority to vouch for that namespace. >> >> >> >> draft-yusef-acme-3rd-party-device-attestation is designed to issue certs >> for a domain name (as per normal Acme). The cert will be for a specific >> device whose serial number (eg MAC address) the domain-owner knows. The >> device manufacturer can vouch for device keys associated with that serial >> number. >> > > Yes, and that was captured in section 2.2: > > https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01#section-2.2 > > > >> Curiously, the protocol flow in >> draft-yusef-acme-3rd-party-device-attestation doesn’t seem to involve the >> device at all – only the domain-owner (client), manufacturer, and CA. But >> surely the device needs to provide the CSR? >> >> > This is out of scope for this document, as the document is focusing on the > ACME interface. But you are correct that the device will be the one that > provides the CSR. > > >> >> >> It sounds like the client (domain-owner) should be able to confirm the >> correct device is involved (by talking to the device and manufacturer) >> before sending a normal ACME request. That way the ACME CA doesn’t need to >> know anything about the device attestation. >> > > Correct. This the the OAuth interaction, which is out of scope for this > document. > > Regards, > Rifaat > > > >> >> >> -- >> >> James Manger >> >> +61 4 1754 1870 >> > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 > 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 for phone numbers. The CA trusts another > authority to vouch for that namespace. > > > > draft-yusef-acme-3rd-party-device-attestation is designed to issue certs > for a domain name (as per normal Acme). The cert will be for a specific > device whose serial number (eg MAC address) the domain-owner knows. The > device manufacturer can vouch for device keys associated with that serial > number. > Yes, and that was captured in section 2.2: https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01#section-2.2 > Curiously, the protocol flow in > draft-yusef-acme-3rd-party-device-attestation doesn’t seem to involve the > device at all – only the domain-owner (client), manufacturer, and CA. But > surely the device needs to provide the CSR? > > This is out of scope for this document, as the document is focusing on the ACME interface. But you are correct that the device will be the one that provides the CSR. > > > It sounds like the client (domain-owner) should be able to confirm the > correct device is involved (by talking to the device and manufacturer) > before sending a normal ACME request. That way the ACME CA doesn’t need to > know anything about the device attestation. > Correct. This the the OAuth interaction, which is out of scope for this document. Regards, Rifaat > > > -- > > James Manger > > +61 4 1754 1870 > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 for phone numbers. The CA trusts another authority to vouch for that namespace. draft-yusef-acme-3rd-party-device-attestation is designed to issue certs for a domain name (as per normal Acme). The cert will be for a specific device whose serial number (eg MAC address) the domain-owner knows. The device manufacturer can vouch for device keys associated with that serial number. Curiously, the protocol flow in draft-yusef-acme-3rd-party-device-attestation doesn’t seem to involve the device at all – only the domain-owner (client), manufacturer, and CA. But surely the device needs to provide the CSR? It sounds like the client (domain-owner) should be able to confirm the correct device is involved (by talking to the device and manufacturer) before sending a normal ACME request. That way the ACME CA doesn’t need to know anything about the device attestation. -- James Manger +61 4 1754 1870 ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 is authoritative for multiple identifier spaces
>> (e.g.
>>TNAuthList with telephone numbers and service providers), while a
>> Device
>>Authority is responsible for one identifier space, i.e. the devices
>>manufactured by a specific vendor.
>>
>
> Just because the framework can address the case where a single authority
> can speak for multiple identifier spaces doesn't mean it can't also address
> the single identifier space case.
>
> True, but it slightly complicates the solution for this use case (see more
below).
>
>
>> 2. A certificate issued to an entity controlled by a Token Authority is
>> specific
>>to that entity independent of any domain, while a certificate issued
>> to
>>a device controlled by a Device Authority is specific to the device
>> *and* the
>>Client domain (based on a Client account with ACME).
>>
>
> What do you mean by "domain" here?
>
>
By domain I am talking about a service that the device is expected to
consume.
For example, a SIP phone that is expected to connect to a SIP network to
get
configuration and SIP services.
What I am trying to achieve is that the certificate that would be issued to
the
device is not only an attestation to the device as an independent entity,
but a
valid device with permission to access a specific service.
>
>>
>> Also, I noticed that the TNAuthList proposal does support redirection, as
>> an
>> optional feature. In the Device Authority case this is not critical and
>> could be
>> left as optional too, which will simplify the flow even further, as it
>> would
>> allow us to drop Steps 3 & 4 from the flow described in section 2.4,
>> which would
>> look as follows without the redirection:
>>
>> Client Device Authority
>> ACME CA
>> (customer.com) (as.vendor.com) (
>> acme.com)
>> ||
>> |
>> | [01] POST /new-order [kid=customer.com, url=vendor.com,
>> identifier={mac}|
>>
>> |>|
>> ||
>> |
>> |[02] 201
>>|
>> | [authorizations=vendor.com/acme/authz/1234,
>>|
>> | finalize=
>> customer.com/acme/order/asdf/finalize] |
>>
>> |<|
>> ||
>> |
>> | [03] Use OAuth to obtain a device JWT
>>|
>> |<==>|
>> |
>> ||
>> |
>> | [04] POST /vendor.com/acme/authz/1234 [JWT]
>>|
>>
>> |>|
>> ||
>> |
>> ||[05] 200
>> [status=valid] |
>>
>> |<|
>> ||
>> |
>> | [06] POST /customer.com/acme/order/asdf/finalize [CSR]
>> |
>>
>> |>|
>> ||
>> |
>> |[07] 200 [certificate=customer.com/acme/cert/asdf]
>> |
>>
>> |<|
>> ||
>> |
>> | [8] GET /customer.com/acme/cert/asdf
>> |
>>
>> |>|
>> ||
>> |
>> || [8] 200
>> [certificate] |
>>
>> |<|
>> ||
>> |
>>
>>
>> Unless I missed something, because of the above and to keep this
>> mechanism as
>> simple as possible, I would like to keep this proposal independent of the
>> Token
>> Authority framework at this stage.
>>
>
> I'm confused. Issuing with authority tokens entails exactly the flow
> you've laid out. It's just that the interaction between the client and the
> token authority is undefined in that doc, so you can fill it in with your
> step 03.
>
>
There are few differences between the Device Authority (DA) and the Token
Authority (TA) flows.
Let's discuss the flow without redirection. Here is what I think is the TA
flow:
Client Token Authority ACME
CA
(customer.com) (ta.example.com) (
acme.com)
||
|
|
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 telephone numbers and service providers), while a
> Device
>Authority is responsible for one identifier space, i.e. the devices
>manufactured by a specific vendor.
>
Just because the framework can address the case where a single authority
can speak for multiple identifier spaces doesn't mean it can't also address
the single identifier space case.
> 2. A certificate issued to an entity controlled by a Token Authority is
> specific
>to that entity independent of any domain, while a certificate issued to
>a device controlled by a Device Authority is specific to the device
> *and* the
>Client domain (based on a Client account with ACME).
>
What do you mean by "domain" here?
>
>
> Also, I noticed that the TNAuthList proposal does support redirection, as
> an
> optional feature. In the Device Authority case this is not critical and
> could be
> left as optional too, which will simplify the flow even further, as it
> would
> allow us to drop Steps 3 & 4 from the flow described in section 2.4, which
> would
> look as follows without the redirection:
>
> Client Device Authority
> ACME CA
> (customer.com) (as.vendor.com) (
> acme.com)
> ||
> |
> | [01] POST /new-order [kid=customer.com, url=vendor.com,
> identifier={mac}|
>
> |>|
> ||
> |
> |[02] 201
> |
> | [authorizations=vendor.com/acme/authz/1234,
>|
> | finalize=customer.com/acme/order/asdf/finalize]
> |
>
> |<|
> ||
> |
> | [03] Use OAuth to obtain a device JWT
> |
> |<==>|
> |
> ||
> |
> | [04] POST /vendor.com/acme/authz/1234 [JWT]
>|
>
> |>|
> ||
> |
> ||[05] 200
> [status=valid] |
>
> |<|
> ||
> |
> | [06] POST /customer.com/acme/order/asdf/finalize [CSR]
> |
>
> |>|
> ||
> |
> |[07] 200 [certificate=customer.com/acme/cert/asdf]
> |
>
> |<|
> ||
> |
> | [8] GET /customer.com/acme/cert/asdf
> |
>
> |>|
> ||
> |
> || [8] 200
> [certificate] |
>
> |<|
> ||
> |
>
>
> Unless I missed something, because of the above and to keep this mechanism
> as
> simple as possible, I would like to keep this proposal independent of the
> Token
> Authority framework at this stage.
>
I'm confused. Issuing with authority tokens entails exactly the flow
you've laid out. It's just that the interaction between the client and the
token authority is undefined in that doc, so you can fill it in with your
step 03.
--Richard
>
> Thoughts?
>
> Regards,
> Rifaat
>
>
> On Thu, Jan 17, 2019 at 1:51 AM Richard Barnes 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
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 for one identifier space, i.e. the devices
manufactured by a specific vendor.
2. A certificate issued to an entity controlled by a Token Authority is
specific
to that entity independent of any domain, while a certificate issued to
a device controlled by a Device Authority is specific to the device
*and* the
Client domain (based on a Client account with ACME).
Also, I noticed that the TNAuthList proposal does support redirection, as
an
optional feature. In the Device Authority case this is not critical and
could be
left as optional too, which will simplify the flow even further, as it
would
allow us to drop Steps 3 & 4 from the flow described in section 2.4, which
would
look as follows without the redirection:
Client Device Authority
ACME CA
(customer.com) (as.vendor.com) (
acme.com)
||
|
| [01] POST /new-order [kid=customer.com, url=vendor.com,
identifier={mac}|
|>|
||
|
|[02] 201
|
| [authorizations=vendor.com/acme/authz/1234,
|
| finalize=customer.com/acme/order/asdf/finalize]
|
|<|
||
|
| [03] Use OAuth to obtain a device JWT
|
|<==>|
|
||
|
| [04] POST /vendor.com/acme/authz/1234 [JWT]
|
|>|
||
|
||[05] 200 [status=valid]
|
|<|
||
|
| [06] POST /customer.com/acme/order/asdf/finalize [CSR]
|
|>|
||
|
|[07] 200 [certificate=customer.com/acme/cert/asdf]
|
|<|
||
|
| [8] GET /customer.com/acme/cert/asdf
|
|>|
||
|
|| [8] 200 [certificate]
|
|<|
||
|
Unless I missed something, because of the above and to keep this mechanism
as
simple as possible, I would like to keep this proposal independent of the
Token
Authority framework at this stage.
Thoughts?
Regards,
Rifaat
On Thu, Jan 17, 2019 at 1:51 AM Richard Barnes 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
> wrote:
>
>> All,
>>
>> I have just submitted new updated version to address the
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
"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 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 https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 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 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.i...@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: >>> 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 >>> >>> >>> >>> 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 >>> >> ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 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 > 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: >> 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 >> >> >> >> 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 >> > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 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: > 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 > > > > 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 > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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 defined in section 7.4 in the acme draft: https://tools.ietf.org/html/draft-ietf-acme-acme-18#section-7.4 The only difference is that the url will contain the new order with the vendor.com to indicate that it is requesting a certificate for a device controlled by this Device Authority. Hope this helps. I will try to expand on this in the next version of the document. Regards, Rifaat On Wed, Jan 16, 2019 at 4:15 PM Ilari Liusvaara wrote: > 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: draft-yusef-acme-3rd-party-device-attestation > > Revision: 01 > > > https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt > > Other comments: > > - How the ACME server can look up the client account with kid field > (which normally contains the client account identifier) now contains > the client domain? > - URL field in first request seems to be also overloaded. Considering > that this field actually has security significance (prevent misrouting > to different resource), this seems questionable. > - Constructing URL poiting to the client without knowledge of used paths > is very questionable. > - It seems to me that this should be handled by defining a new validation > method for the mac identifiers, without touching rest of ACME. Then > the CA would send those back for mac identifiers (together with the > needed references) and then take the JWT as reply. > > > -Ilari > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
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: draft-yusef-acme-3rd-party-device-attestation > Revision: 01 > https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt Other comments: - How the ACME server can look up the client account with kid field (which normally contains the client account identifier) now contains the client domain? - URL field in first request seems to be also overloaded. Considering that this field actually has security significance (prevent misrouting to different resource), this seems questionable. - Constructing URL poiting to the client without knowledge of used paths is very questionable. - It seems to me that this should be handled by defining a new validation method for the mac identifiers, without touching rest of ACME. Then the CA would send those back for mac identifiers (together with the needed references) and then take the JWT as reply. -Ilari ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
