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 whether they recognize and support that framework, and determine which rules to apply.
There are projects actively working in this field to develop an interoperability profile between multiple frameworks, such as SIDI HUB. Il giorno gio 13 giu 2024 alle ore 03:13 Tom Jones < thomasclinganjo...@gmail.com> ha scritto: > 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 > consideration. > > ..tom > > thx ..Tom (mobile) > > On Wed, Jun 12, 2024, 5:39 AM Giuseppe De Marco <demarco...@gmail.com> > wrote: > >> 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 URL of the issuer, which involves an X.509 >> validation of the issuer domain name in the URL. >> >> Amen. this give us the certaininty that the subject is exactly the one >> we're supposing to interact with, untill the DNS were not compromised and >> an evil endpoint with let's encrypt would appear on the way. Therefore the >> decision about the trust anchor to trust is crucial. >> At the same time I use to trust (and love) let'sencrypt, therefore >> addings additional layers helps me in supporting all the CAs attested in >> the CAB forum and at the same time add additional security, policy and >> interoperability chjecks using another layer. >> >> > What is the problem with the relying party taking a certificate and >> validating the issue domain name directly using the same certificate? >> >> it is not a problem but a requirement. The relying party MUST do this. >> After doing this and got the assurance asbout the domain name, a more >> advanced trust establishment may occur where requirements need this. >> I have this requirements. >> >> A Friend sent to me a picture of a mushroom he has picked. An popular >> cloud provider, using AI, attested it as very good for cooking. >> He didn't trust that "trust anchor" even if so popular and fancy, >> therefore he has double checked with me. >> According to my experience that mushroom was an amanita muscaria. It's >> still a mushroom, but you cannot attest the compliance of it to your needs >> if you don't add additional checks. >> >> additional layers for additional frameoworks and compliance checks >> satisfy the requirements of having additional checks for additional >> property, not covered with the minimal set of requirement, like be a >> mushroom or a FQDN using TLS. >> >> Another example >> >> >> Il giorno mer 12 giu 2024 alle ore 14:09 Rohan Mahy <rohan.m...@gmail.com> >> ha scritto: >> >>> 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 domain >>> name in the URL. What is the problem with the relying party taking a >>> certificate and validating the issue domain name directly using the same >>> certificate? >>> >>> Thanks, >>> -rohan >>> >>> On Wed, Jun 12, 2024 at 7:59 AM Giuseppe De Marco <demarco...@gmail.com> >>> wrote: >>> >>>> 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 >>>> network/framework/shared-regulation/perimeter. >>>> >>>> Let's consider this mailing list as a trust anchor. >>>> >>>> We're having a productive conversation under a common trust anchor, >>>> where the evidence that connects us is our membership in this community, >>>> under the IETF Trust Anchor. >>>> >>>> However, this alone is not sufficient, because you must read everything >>>> I say and empirically evaluate if you can trust me qualitatively. >>>> >>>> OpenID Federation allows the exchange of metadata to securely establish >>>> interoperability and also applies policies that dynamically change this >>>> metadata, adding qualitative evidence with trust marks. >>>> >>>> This is the advancement I found that the X.509 based PKI was not >>>> designed for. I use X.509 based PKI for other purposes, since in this >>>> universe everything has its right place, and I appreciate this. >>>> >>>> I also appreciate PIKA in a way to make this grow and get integrated >>>> with other models that should not be kept out of the scope of the >>>> specification if you agree and if we may have the opportunity to work >>>> together in this field >>>> >>>> Il giorno mer 12 giu 2024 alle ore 12:47 Rohan Mahy < >>>> rohan.m...@gmail.com> ha scritto: >>>> >>>>> 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 Tue, Jun 11, 2024 at 4:44 AM Giuseppe De Marco < >>>>> demarco...@gmail.com> wrote: >>>>> >>>>>> 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 >>>>>> authors insist that openid federation is not only a pki. >>>>>> >>>>>> TLS is not removed, we use X.509 based pki on the web, therefore also >>>>>> using federation. >>>>>> >>>>>> TLS is used to establish confidentiality with an endpoint, >>>>>> establishing trust to a subject only because it controls a private >>>>>> cryptographic key is similar to the weakness about the bearer tokens. >>>>>> Therefore, for instance, in advanced ecosystems and implementation is >>>>>> required to demonstrate the proof of possession of the tokens because >>>>>> bearers alone are not secure enough. This is more complex but required in >>>>>> the real wold. >>>>>> >>>>>> The point is: what is trust, how to establish trust in the real >>>>>> world, which are the technical layers that we should (even in a modular >>>>>> way) take into account to achieve our goals. Do we have the same goals? >>>>>> Don't stop working together, let's keep the conversation to achieve >>>>>> our goals in an harmonic way. >>>>>> >>>>>> Il giorno mar 11 giu 2024 alle ore 06:11 Tom Jones < >>>>>> thomasclinganjo...@gmail.com> ha scritto: >>>>>> >>>>>>> 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 problem of there own making. So let them fix their own mistakes. >>>>>>> >>>>>>> thx ..Tom (mobile) >>>>>>> >>>>>>> On Mon, Jun 10, 2024, 8:37 PM Watson Ladd <watsonbl...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On Mon, Jun 10, 2024 at 8:33 PM Michael Jones >>>>>>>> <michael_b_jo...@hotmail.com> 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 equivalent in complexity. >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > The draft would require adding code directly understanding the >>>>>>>> structure and fields of X.509 to applications using it. Eliminate >>>>>>>> that, >>>>>>>> and I’ll support adoption. >>>>>>>> >>>>>>>> I don't understand your proposal. An X509 certificate is the only >>>>>>>> way >>>>>>>> to link a DNS name to a key at a given point in time as we can >>>>>>>> leverage the Web PKI. Absent that, what do you do? >>>>>>>> >>>>>>>> Also, I'm not sure what you mean by platform layers. Many of them >>>>>>>> expose a function to verify a signature with a key in an X509 cert >>>>>>>> or >>>>>>>> verify a cert chain, even outside the context of TLS. Are there >>>>>>>> particular ones that would have a problem you are concerned about? >>>>>>>> >>>>>>>> Sincerely, >>>>>>>> Watson Ladd >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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
