Comment inline. On Wed, Jun 12, 2024 at 8:39 AM Giuseppe De Marco <demarco...@gmail.com> 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 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. > [snip] I don't see why the existence of these other requirements should prevent people who only want to do offline validation of the issuer domain should be prevented from doing so. That's what PIKA is for. Likewise PIKA does not prevent a relying party from implementing whatever other additional mechanisms of arbitrary complexity the community wants to standardize. Thanks, -rohan
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
