I am not opposed to adding additional security for JWK key sets. I, however, share concerns about mixing the layering of certificates for transport security and application-level signing.
I am not saying you can’t do it, but it adds operational complexity. One problem with TLS certificates is they end up living in a lot of places like reverse proxies and servers without HSM. As a result, the lifetime of TLS certificates gets shorter and shorter. I believe Letsencrypt is down to 90 days, and that could and perhaps should get shorter. That may not match the operational needs for application-level signing. / Looking at potential EU trust list requirements the private key used to sign the metadata for federation may need to be signed over by multiple trust lists (no I don’t think that is a good idea, but when has the EU been reasonable?). I can see lots of interesting operational issues when you start combining these things. Will lets encrypt allow the same private key over multiple issuances when it needs to be more or less static to match the other certs? This proposal is interesting but may have unintended and perhaps undesired interactions by mixing the layers. Perhaps there are ways to resolve these issues. I am happy to discuss further. Regards John B. > On Jul 2, 2024, at 6:40 AM, Pieter Kasselman > <pieter.kasselman=40microsoft....@dmarc.ietf.org> wrote: > > I want to thank the authors for preparing this draft. It addressees an > important set of scenarios and I am supportive of the goal of this draft to > add additional protection to JWK Key sets beyond being hosted on a web server > protected by a TLS connection. > I have some questions around the trust framework/trust model and would like > to see some clarification or clear guidance on where the X.509 certificates > would come from and how they would be used. In general I am concerned by > practices of using the same keys and certs for multiple purposes. It causes > confusion and may result in security issues. > From reading the draft and some comments referring to Web PKI, I get the > impression that one option is to use TLS certs for signing artefacts that > would be long lived, or would need to be archived/managed for a long time. > Generally, using a key/cert to authenticate a web server for an ephemeral > connection is different from generating long lived signatures that may be > archived for decades as part of security audit data. Even if a separate TLS > cert is used, it raises concerns about confusion that may result from using > TLS certs in this way (it would be indistinguishable from a regular TLS cert > for anyone verifying the key set). If the same certs/keys are used for both > the TLS connection and generating PIKA proofs, it raises questions about > application layer access to signing keys on the web server where the TLS > session gets terminated. TLS keys are by nature closer to the edge where they > are more accessible/vulnerbale, compared to keys that are used to sign > artefacts that may persist over time and should be kept further away from the > edge. > It would be good to provide clear guidance on the trust framework for PIKA > certs. where they would come from and the need of keeping them separate from > certificates and keys used for ephemeral purposes (securing TLS connections). > Perhaps this is something that can be done as part of security > considerations, or may even be subject to its own in the draft. > Cheers > Pieter > > > From: Richard Barnes <r...@ipv.sx> > Sent: Tuesday, June 25, 2024 9:56 PM > To: Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > Cc: oauth <oauth@ietf.org> > Subject: [OAUTH-WG] Re: Call for adoption - PIKA > > Hi all, > > Replying to the top of the thread again to recap the arguments so far. > (Hoping the chairs will give us a moment more to discuss before calling > cloture.) > > It seems like Sharon, Rohan, Watson, and I are all on the same page w.r.t. > the X.509-based mechanisms in the current draft. In particular, we're all > developers of relying party software, and it seems like we're all OK with > doing X.509 (contra Mike's point about application-level X.509). > > If I understand Mike and Giuseppe correctly, they want to be less > prescriptive about how the PIKA signer establishes their authority for an > "iss" value, so that an OP could use some other mechanism (e.g., OpenID > Federation). It sounds like Mike at least is OK with the draft aside from > this point. > > I would be open to adding some optionality in the authority mechanism here, > but I'm wary of losing the concrete interop that we get with the draft as it > is. So we would need at least a strong recommendation for X.509, even if > something else can be used if the parties agree to it. I would be more > comfortable doing something along the lines of what Rohan suggests, namely > defining a concrete, X.509-based thing here, and extending it to support > other mechanisms via follow-on specs as needed. If there were a single > additional mechanism that people wanted, as opposed to a generic "[insert > authority mechanism here]", that would also be more palatable to me. > > Additional feedback would be useful on a couple of points: > > 1. From RPs: Is the X.509 requirement onerous to you? Or is there enough > library support out there that it's not a big deal? > 2. From OPs: Is signing using a key bound to an X.509 certificate workable > for you? Or do you need some other authority framework? > 3. From everyone: Is the general mechanism here useful, assuming we can align > on some set of authority frameworks? > > Thanks, > --Richard > > > On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com > <mailto:rifaat.s.i...@gmail.com>> wrote: > All, > > This is an official call for adoption for the Proof of Issuer Key Authority > (PIKA) draft: > https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/ > > Please, reply on the mailing list and let us know if you are in favor or > against adopting this draft as WG document, by June 24th. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org <mailto:oauth@ietf.org> > To unsubscribe send an email to oauth-le...@ietf.org > <mailto:oauth-le...@ietf.org>_______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
