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 framework in use).
I want to work with you to define, within PIKA, the best approach to enable additional mechanisms to extend the current pika trust evaluation to more detailed checks and inspections and in a total modular way, where openid federation can be one of these extensions. I support the trust evaluation mechanism starting from what already proposed in the PIKA draft. I want to avoid that X.509 certificate may add custom extensions to satisfy the used trust frameworks, and therefore get bloated with informations that go out from the original scopes of the X.509 certificates. I say this according to the experience I had in a national SAML2 federation where X.509 certificates was inflated in this way (sorry for giving documents in italian, these was never been traslated): https://www.agid.gov.it/sites/default/files/repository_files/spid-avviso-n29v3-specifiche_sp_pubblici_e_privati.pdf The bulge of X.509 certificates represent only one of the reasons why in Italy we have implemented openid federation. I'm concretely interested in following the evolution of PIKA and give any contribution you may allow me to share and do. Il giorno gio 13 giu 2024 alle ore 09:36 Rohan Mahy <rohan.m...@gmail.com> ha scritto: > 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
