he 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
; From: Richard Barnes
> Sent: Tuesday, June 25, 2024 9:56 PM
> To: Rifaat Shekh-Yusef
> Cc: oauth
> 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 gi
, 2024 9:56 PM
To: Rifaat Shekh-Yusef
Cc: oauth
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
I support adoption of the draft.
I see PIKA as a simple solution to the problem of maintaining an
historical record of OP public keys and would use it as a way of validating
signatures created using technologies like OpenPubkey (
https://github.com/openpubkey/openpubkey) after OP public key
Hey Richard,
Openid Discovery apparently doesn't get popular in the gov field, or at
least not alone and without some sort of trusted registries.
Openid Connect didn't get wide adoption in the R field that is still
using SAML2 with x.509 certificates mixed with a secured metadata exchange
hat adopting this draft would result in this attack occurring
> in practice.
>
>
>
> Thank you,
>
> -- Mike
>
>
>
> *From:* Richard Barnes
> *Sent:* Tuesday, June 25, 2024 1:56 PM
Hi Giuseppe,
Asking whether a technology addresses real-world challenges is a fair
question. The point of the current draft is that we have empirical
evidence that X.509-based authentication works well for many cases, given
the very wide usage of things like OpenID Connect Discovery. PIKA seeks
Hi Ethan,
I have experience implementing LDAP clients with SASL and SSL, SAML2 SP,
IDP, MDQ, as well as OpenID Connect RP, OP, and RS. It's clear that X.509
is foundational to our digital infrastructure, making implementation
straightforward due to the widespread availability of supporting
I strongly support this draft and would have immediate uses for PIKA
if standardized.
As someone who builds OIDC relying party software I am not worried
about the X.509 certificate requirement, nor do I consider dependence
on X.509s or the Web PKI to be an onerous requirement. I already have
to
Sorry to chime in late as well…
I support adoption of this draft. I have read the thread and to me it seems
like there is a mechanism being proposed that solved a concrete problem in
a simple manner. Some of the discussion can happen after the draft is
adopted.
Best,
Kristina
On Wed, Jun 26,
> If we have a tenant" distinguished by a path, there is already a security
issue with giving it the X509 certificate. It could then imitate any
other tenant
on that server already. That's why we use reverse proxies and put the
certificate only on the proxying machines.
In large deployments, like
Sorry to chime in late here. I'm in favor of adopting this draft. While I
realize that X.509 isn't for everyone, there is an established community of
users out there that overlaps with OAUTH users. I think there are needs to
both separate the distribution of the keys from the establishment of
On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
wrote:
>
> The other critique I voiced of the approach is that the application-level
> X.509 certificate can be used to secure the HOST part of the issuer, but not
> the entire issuer, since in general, the issuer will contain a PATH. Yes,
> the
,
-- Mike
From: Richard Barnes
Sent: Tuesday, June 25, 2024 1:56 PM
To: Rifaat Shekh-Yusef
Cc: oauth
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
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
Technology alone cannot solve this problem unless a mapping of different
trust frameworks and rules to handle all behaviors/cases is defined and
voluntarily adopted. The parties must be aware that they are dealing with
an entity operating under a different trust framework, and they must
evaluate
I support people who only want to do offline validation of the issuer
domains.
I support extensions as well, to not force people to believe that subject's
identity and cryptographic material attestation alone are sufficient (at
list in the cases where they should not according to the trust
Comment inline.
On Wed, Jun 12, 2024 at 8:39 AM Giuseppe De Marco
wrote:
[snip]
> > Today relying parties verify the issue domain indirectly by opening a
> TLS connection to the https URL of the issuer, which involves an X.509
> validation of the issuer domain name in the URL.
>
> Amen. this
But the core problem is all of the trust frameworks, like federation, roll
their own conditions and freshness/revocation mechanisms. In other words if
the same attributes from one trust framework were passed to an alternative
framework, it is likely to fail. There is no interop even under
Hi Rohan,
I'ìm very bad in giving answers, I have to live with this, please accept my
excuse (it is almost certainly an attention disorder, autism or something).
Therefore here I try the Take 2.
> Today relying parties verify the issue domain indirectly by opening a TLS
connection to the https
Hi,
This is all interesting in terms of a larger view of big picture goals of
authentication, but you didn't answer my question. Today relying parties
verify the issue domain indirectly by opening a TLS connection to the https
URL of the issuer, which involves an X.509 validation of the issuer
This depends on the evaluation criteria of the verification you conduct
with a subject.
We can agree that the initial verifiable evidence that a Trust Anchor/CA
has issued a certificate for a subject is the first indication that the
subject belongs to a
Giuseppe,
Given that verifying the issuer is already done using X.509 PKI today, why
do you object to trusting the PKI root for the same purpose (validating the
domain name of the issuer) with the same validity period (between the
notBefore and notAfter of the certificate)?
Thanks,
-rohan
On
-- Mike
>
>
>
> *From:* Richard Barnes
> *Sent:* Monday, June 10, 2024 8:18 PM
> *To:* Michael Jones
> *Cc:* Rifaat Shekh-Yusef ; oauth
> *Subject:* Re: [OAUTH-WG] Re: Call for adoption - PIKA
>
>
>
> The applications we're talking about are
I strongly support adoption. This solves important use cases, including
messaging with federation. The draft is generally well written and is a
very small additional option in-line with what is already done elsewhere.
Thanks,
-rohan
On Mon, Jun 10, 2024 at 7:48 AM Rifaat Shekh-Yusef
wrote:
>
Hi Mike,
Richard already made my comment for me that the current TLS validation
doesn't use the path. I want to focus on this comment of yours:
"it’s odd to *require* an X.509 certificate to secure them" (emphasis mine).
The point of this document is to provide a *choice*. You can continue to do
Ciao Tom,
Public Key Infrastructure satisfies the requirements to provide public
keys. Technically, using X.509 certificates represents a consolidated
approach.
Giving public keys doesn't help in establishing the trust or fully proving
the compliance to shared rules, that's why openid federation
Hey Richard,
My reply was very verbose, thank you for the time spent in reading it.
The problem I see in the communities around the openid/ietf/any-other
technical specification is the way we use the term trust and how we aim to
achieve trust from a technical perspective.
I can show that my
On Mon, Jun 10, 2024, 9:33 PM Michael Jones wrote:
>
> Watson, you wrote "An X509 certificate is the only way to link a DNS name to
> a key at a given point in time". However, that's not true. For over a dozen
> years, OpenID Connect has used a .well-known endpoint rooted at the issuer
> URL
Cc: Richard Barnes ; oauth
Subject: Re: [OAUTH-WG] Re: Call for adoption - PIKA
On Mon, Jun 10, 2024 at 8:33 PM Michael Jones
wrote:
>
> We all know that TLS certificates are handled by platform layers used by
> applications and not the applications themselves. There is no c
This whole problem did not need to happen. When the federation spec was
being created I asked them not to deviate unnecessarily from pki. But the
very guys that are on this thread told me that they were not a pki and so
there was no reason for them to follow existing rules. This is entirely a
On Mon, Jun 10, 2024 at 8:33 PM Michael Jones
wrote:
>
> We all know that TLS certificates are handled by platform layers used by
> applications and not the applications themselves. There is no code that
> understands X.509 certificates in most applications that use TLS. They are
> not
; oauth
Subject: Re: [OAUTH-WG] Re: Call for adoption - PIKA
The applications we're talking about are **already** doing X.509 when they make
HTTPS connections. It's not a new requirement. The only thing we're doing is
using the certificate for JWT instead of HTTPS.
--RLB
On Mon, Jun 10, 2024
nd I’ll support adoption of the next draft.
>
>
>
> -- Mike
>
>
>
> *From:* Richard Barnes
> *Sent:* Monday, June 10, 2024 8:11 PM
> *To:* Rifaat Shekh-Yusef
> *Cc:* oauth
> *Subject:* [OAUTH-WG] Re:
adoption of the next draft.
-- Mike
From: Richard Barnes
Sent: Monday, June 10, 2024 8:11 PM
To: Rifaat Shekh-Yusef
Cc: oauth
Subject: [OAUTH-WG] Re: Call for adoption - PIKA
In case it's not clear from other messages
In case it's not clear from other messages in this thread: I think this
draft should be adopted. It solves several pressing use cases, with the
minimal amount of complexity needed.
--Richard
On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is an official call for
Hi Giuseppe,
To be blunt, solving the use cases we're talking about with OpenID
Federation is like doing surgery with a chainsaw. You might achieve the
intended goal, but the results will be messy.
The trust model we are addressing is one that already exists: A JWT is
issued by an issuer
Hi,
I appreciate the introduction of PIKA, which demonstrates a commitment to
addressing current challenges. However, I have identified some key areas of
concern that need attention:
1. The current documentation lacks clarity regarding the number and scope
of cryptographic keys, particularly in
Hi Mike,
The intent here is to follow exactly the same security model as current
HTTPS-based OP key discovery mechanisms, e.g., OpenID Connect Discovery.
With those mechanisms:
1. The only way the issuer is authenticated is via a certificate presented
in HTTPS.
2. The only aspect of the URL that
While I'm generally supportive of the goals of this draft, I have issues with
the mechanisms proposed. Therefore, I believe that more working group
discussion is needed before adoption.
If I were to do something along these lines, I would not use "x5c". Other than
for TLS certificates, the
40 matches
Mail list logo
