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
