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] AD Review: draft-ietf-acme-ip-04
Comments inline: > On Dec 24, 2018, at 12:32 PM, Eric Rescorla wrote: > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D4180 > > > IMPORTANT > S 3. > > used to refer to fully qualified domain names. If a ACME server > > wishes to request proof that a user controls a IPv4 or IPv6 address > > it MUST create an authorization with the identifier type "ip". The > > value field of the identifier MUST contain the textual form of the > > address as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC4291] > > Section 2.2 for IPv6. > > Are all three variants here valid? I think requiring the canonical representation defined in 5952 Section 4 to be supported makes sense, but would be in favor of also allowing supporting any of the other 4291 representations if the implementer wishes. > > > S 4. > > For the "tls-alpn-01" the subjectAltName extension in the validation > > certificate MUST contain a single iPAddress which matches the address > > being validated. As [RFC6066] does not permit IP addresses to be > > used in the SNI extension the server MUST instead use the IN- > > ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the IP > > address as the SNI value instead of the literal IP address. > > What happens if an attacker forces an incorrect SNI on you here? I > don't see any security analysis below, but I suspect it's bad, > I’m not sure I understand how an attacker would force an incorrect SNI? tls-alpn-01 requires that the server verify that the SNI that it is provided matches what it expects. > > COMMENTS > S 6. > > > > 6. Security Considerations > > > > Given the often short delegation periods for IP addresses provided by > > various service providers CAs MAY want to impose shorter lifetimes > > for certificates which contain IP identifiers. They MAY also impose > > https://tools.ietf.org/rfcmarkup?doc=6919#section-6 > > If the WG thinks that providers ought to do this, then it should say > so. > I don’t think it makes sense for the document to mandate this as it’s not an implementation detail but a policy one which the relevant policy authorities (such as CABF) may dictate themselves in the future putting this document at odds with those requirements. ___ 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] Add badPublicKey error
* Note that since the registration policy is "specification required", doing this in an extension spec instead would not require the consent of the IESG. Right, which is how I prefer to see this move forward. Putting it into the ACME doc, however, *does* require IESG approval. * I think you're confused here, Rich. This error code relates to *account keys*, not keys that are certified by the CA. Not really, which is why I chose the example I did. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Add badPublicKey error
> > As an individual, I dislike putting "here's what's wrong with your key" in > the error message. For example, it encourages a thief to do "venue > shopping" looking for a CA that will certify their stolen keypair. > I don't think this is a meaningful example. The server has to return some kind of error message if it isn't going to accept the key. As an attacker I probably know I've stolen a good key (it was in use, wasn't it?) so if I get an error message of any kind I can shop it out to the next CA. This thread is just addressing the question about whether we should make it a standardized error instead of bucketed into "malformed". On Thu, Jan 24, 2019 at 11:19 AM Salz, Rich wrote: > >- Note that since the registration policy is "specification required", >doing this in an extension spec instead would not require the consent of >the IESG. > > > > Right, which is how I prefer to see this move forward. Putting it into > the ACME doc, however, **does** require IESG approval. > > > >- I think you're confused here, Rich. This error code relates to >*account keys*, not keys that are certified by the CA. > > > > Not really, which is why I chose the example I did. > ___ > 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] Add badPublicKey error
On Thu, Jan 24, 2019 at 10:52 AM Salz, Rich wrote: > As WG co-chair, I am not thrilled with making this addition so very very > late in the process. If the WG wants to do it, we'd need (a) clear > consensus and (b) a quick approval from the IESG. > Note that since the registration policy is "specification required", doing this in an extension spec instead would not require the consent of the IESG.. > As an individual, I dislike putting "here's what's wrong with your key" in > the error message. For example, it encourages a thief to do "venue > shopping" looking for a CA that will certify their stolen keypair. > I think you're confused here, Rich. This error code relates to *account keys*, not keys that are certified by the CA. --Richard > > On 1/24/19, 9:27 AM, "Rob Stradling" wrote: > > I realize it's very late for making non-editorial changes to > draft-ietf-acme-acme, but I'd like to propose adding a new > badPublicKey > error. This error would be returned by the server whenever it does > not > support, or wishes to reject, a "jwk" public key supplied in a > client's > request. > > Proposed text: https://github.com/ietf-wg-acme/acme/pull/478 > > The 'array of supported "alg" values' in a badSignatureAlgorithm > response is useful, but ISTM that it doesn't provide detailed enough > information to assist a client in generating a suitable public key. > > (If the consensus is that it's too late to add a new error type, then > my > alternative proposal will be to use "malformed" instead of adding > "badPublicKey", but keep the rest of PR 478 as is; I think it's a good > idea to call out the need for a server to sanity check each > client-supplied public key). > > -- > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited > > ___ > 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 > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Add badPublicKey error
As WG co-chair, I am not thrilled with making this addition so very very late in the process. If the WG wants to do it, we'd need (a) clear consensus and (b) a quick approval from the IESG. As an individual, I dislike putting "here's what's wrong with your key" in the error message. For example, it encourages a thief to do "venue shopping" looking for a CA that will certify their stolen keypair. On 1/24/19, 9:27 AM, "Rob Stradling" wrote: I realize it's very late for making non-editorial changes to draft-ietf-acme-acme, but I'd like to propose adding a new badPublicKey error. This error would be returned by the server whenever it does not support, or wishes to reject, a "jwk" public key supplied in a client's request. Proposed text: https://github.com/ietf-wg-acme/acme/pull/478 The 'array of supported "alg" values' in a badSignatureAlgorithm response is useful, but ISTM that it doesn't provide detailed enough information to assist a client in generating a suitable public key. (If the consensus is that it's too late to add a new error type, then my alternative proposal will be to use "malformed" instead of adding "badPublicKey", but keep the rest of PR 478 as is; I think it's a good idea to call out the need for a server to sanity check each client-supplied public key). -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ 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] Add badPublicKey error
+1 - this seems like something we should have had already. Thanks for catching & proposing the fix Rob. On Thu, Jan 24, 2019 at 9:30 AM Richard Barnes wrote: > This seems fine to me. It's basically just a table entry, with some > description of how to use it. > > --Richard > > On Thu, Jan 24, 2019 at 9:26 AM Rob Stradling wrote: > >> I realize it's very late for making non-editorial changes to >> draft-ietf-acme-acme, but I'd like to propose adding a new badPublicKey >> error. This error would be returned by the server whenever it does not >> support, or wishes to reject, a "jwk" public key supplied in a client's >> request. >> >> Proposed text: https://github.com/ietf-wg-acme/acme/pull/478 >> >> The 'array of supported "alg" values' in a badSignatureAlgorithm >> response is useful, but ISTM that it doesn't provide detailed enough >> information to assist a client in generating a suitable public key. >> >> (If the consensus is that it's too late to add a new error type, then my >> alternative proposal will be to use "malformed" instead of adding >> "badPublicKey", but keep the rest of PR 478 as is; I think it's a good >> idea to call out the need for a server to sanity check each >> client-supplied public key). >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> Sectigo Limited >> >> ___ >> 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 > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Add badPublicKey error
This seems fine to me. It's basically just a table entry, with some description of how to use it. --Richard On Thu, Jan 24, 2019 at 9:26 AM Rob Stradling wrote: > I realize it's very late for making non-editorial changes to > draft-ietf-acme-acme, but I'd like to propose adding a new badPublicKey > error. This error would be returned by the server whenever it does not > support, or wishes to reject, a "jwk" public key supplied in a client's > request. > > Proposed text: https://github.com/ietf-wg-acme/acme/pull/478 > > The 'array of supported "alg" values' in a badSignatureAlgorithm > response is useful, but ISTM that it doesn't provide detailed enough > information to assist a client in generating a suitable public key. > > (If the consensus is that it's too late to add a new error type, then my > alternative proposal will be to use "malformed" instead of adding > "badPublicKey", but keep the rest of PR 478 as is; I think it's a good > idea to call out the need for a server to sanity check each > client-supplied public key). > > -- > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited > > ___ > 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
[Acme] Add badPublicKey error
I realize it's very late for making non-editorial changes to draft-ietf-acme-acme, but I'd like to propose adding a new badPublicKey error. This error would be returned by the server whenever it does not support, or wishes to reject, a "jwk" public key supplied in a client's request. Proposed text: https://github.com/ietf-wg-acme/acme/pull/478 The 'array of supported "alg" values' in a badSignatureAlgorithm response is useful, but ISTM that it doesn't provide detailed enough information to assist a client in generating a suitable public key. (If the consensus is that it's too late to add a new error type, then my alternative proposal will be to use "malformed" instead of adding "badPublicKey", but keep the rest of PR 478 as is; I think it's a good idea to call out the need for a server to sanity check each client-supplied public key). -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
