I have opposed channel-binding or token-binding from the beginning as they serve very different puppies and typically fall under different management within large enterprises. I have tried to push for a simple way to test the validity of a signature for decades into the future as that is typical for a wet signature. If digital signatures are ever acceptable as a replacement for wet signatures then longer checking capabilities are required.
thx ..Tom (mobile) On Wed, Jul 3, 2024, 8:41 AM John Bradley <ve7...@ve7jtb.com> wrote: > 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> 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 > 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 > > > _______________________________________________ > 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
