[OAUTH-WG] Re: Call for adoption - PIKA

[Tom Jones <[e-mail]>]

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 <[e-mail]> 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=
> [e-mail]> 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 <[e-mail]>
> *Sent:* Tuesday, June 25, 2024 9:56 PM
> *To:* Rifaat Shekh-Yusef <[e-mail]>
> *Cc:* oauth <[e-mail]>
> *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 <
> [e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>