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
