Thanks for those details, Matt. I'll do some further work to make sure I'm handling HTTP response codes as you suggest.
Although pkimetal will disable online pwnedkeys checks by default, I am planning to enable online pwnedkeys checks in the public pkimetal instances (https://pkimet.al and https://dev.pkimet.al) and in the pkimetal instances that Sectigo uses for preissuance linting. ________________________________ From: [email protected] <[email protected]> on behalf of Matt Palmer <[email protected]> Sent: 23 October 2024 00:30 To: [email protected] <[email protected]> Subject: Re: Standard PKC Test Keys CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, Oct 22, 2024 at 04:22:14PM +0000, Rob Stradling wrote: > * What's a sensible default HTTP request timeout when calling the > pwnedkeys API? Unless you're on an absolutely backwater Internet connection, if you haven't got a response within a second or so, you're *probably* not going to get one. To give you an indication of actual service times, over the past two weeks, HTTP requests that return an attestation (ie a GET that returns a 200) are consistently between 37 and 38 milliseconds. If you're willing to trust me (highly not recommended) you can do a HEAD, which comes in at between 20 and 21ms. A GET or HEAD that returns a 404 (which should be the overwhelming majority of responses, unless you're extremely unlucky) sits happily at about 12ms. In order to automatically account for terribad network latency, I'd suggest just collecting request time stats and setting the timeout at something like MAX(1s, 2*mean, 3sigma). > * What's a sensible default severity level (error, warning, notice, > info) if a pwnedkeys API request times out? Given that failing to check pwnedkeys is equivalent to the current status quo, info seems reasonable. > * What's a sensible default severity level if the pwnedkeys API call > misbehaves in any other way? In terms of the lint result, info (for the same reasons as timeout). Log entries for 4xx (other than 404/429) should be a fairly high severity, as those *should* indicate a bug in pkimetal's request logic that needs to be fixed. For example, if/when the current API were to be phased out, I intend to serve all 410s for an extended period, which this logic would detect and log, notifying the operator that they need to upgrade. > * What's a sensible default maximum number of concurrent requests > from a pkimetal instance to the pwnedkeys API? Go for your life. I'd be interested in a good load test. The per-IP rate limit *should* shut you down before you can break anything; anyone who wants an API key with a higher rate limit feel free to get in touch. > * Should a pkimetal instance apply a req/sec rate limit on its own > outgoing requests to the pwnedkeys API? No need -- as long as you respect the 429 (including the Retry-After) you shouldn't cause any damage (and if you do, that's my fault, not yours). - Matt -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F0ad2a97d-38ea-4980-9551-fce72f3a7664%2540mtasv.net&data=05%7C02%7Crob%40sectigo.com%7Cb464152977c34830839408dcf2f1775f%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638652366139755791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=l4tIUqfj%2B72DBEg1Jtw3ZgrodpEglKGDJeBpcKTezQY%3D&reserved=0<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0ad2a97d-38ea-4980-9551-fce72f3a7664%40mtasv.net>. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB47298E8FACA614F770920781AA4F2%40MW4PR17MB4729.namprd17.prod.outlook.com.
