Hi Watson, I appreciate the concerns with regard to re-using Web PKI certs for cases such as these. Care is required, but I think there is a path here.
1. Clearly there are cross-protocol concerns. I expect that most usage here in reality would be based on ECDSA / EdDSA, not RSA, which helps. I would be comfortable with security considerations recommending that a key pair / certificate used for signing these things be used for no other purpose. 2. Validity times are definitely a challenge for the container signing use case, but from the conversations I've had with that community, they are taking an orthogonal approach. As I tried to sketch in the document, they are establishing authorities that will vouch that a signed thing existed at a given time, so that a relying party can safely rewind their clock and validate as if it were that time. See, e.g., SigStore < https://www.sigstore.dev/>, which has roughly this shape if you squint right. 3. I don't think there's actually any disconnect between HTTPS authentication and proof of authority. The Web PKI is about authenticating domain names, which is what both use cases require. Best, --Richard On Mon, Mar 18, 2024 at 10:23 AM Watson Ladd <watsonbl...@gmail.com> wrote: > On Sat, Mar 16, 2024 at 10:56 PM Richard Barnes <r...@ipv.sx> wrote: > > > > Hi all, > > > > A few of us have been considering use cases for JWTs related to > Verifiable Credentials and container signing, which require better "proof > of authority" for JWT signing keys. Sharon Goldberg and I wrote up a quick > specification for how to sign a JWK set, and how you might extend discovery > mechanisms to present such a signed JWK set: > > > > > https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md > > > > (Just in GitHub for now; will publish as an I-D when the window reopens > tomorrow.) > > > > If we could get this functionality added to OAuth / OIDC, it would make > these use cases work a lot better. As a prelude toward proposing working > group adoption, it would be great to know if this design seems helpful to > other folks as well. Obviously, happy to answer any questions / comments. > > I have concerns about this proposal. First we need to ban any use of > RSA-1.5 encryption (aka TLS 1.2) with the certificates used here. This > is not really possible in TLS as commonly implemented for reasons, and > can't be determined from the certificate alone (unless it's RSA-PSS > certificate with special stuff that hopefully is honored or ECDSA). > Then there's a philosphical issue to reusing keys for different > purposes that requires domain separation ala TLS 1.3, and likely some > X509 extensions as well to really nail it. > > Secondly there are a bunch of layer 8 question with the Web PKI this > raises. The web PKI is moving to short term issuance and possibly > removal of revocation entirely if certificates can be sufficiently > short term. For signatures on containers this is inappropriate: a > verification that a container is the correct container needs to be > possible long after 90 days or a week, and this means the keying > material that was used to make that signature must be held secure > afterwards. This runs straight up into what we're trying to do to > improve the Web PKI, and using the Web PKI for other things often > leads to pain. > > Thirdly the web PKI issuance methods make sense from a web > perspective, but not necessarily from a codesigning perspective. What > we want to validate is different. Organizationally websites and > codesigning often belong in different places. At the same time there's > a barrier to alternatives, especially the ones that don't exist (see > also Roughtime for my personal experience with this). These issues get > real thorny real fast. > > Sincerely, > Watson Ladd > > > -- > Astra mortemque praestare gradatim >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
