- From: Drummond Reed <Drummond.Reed@gendigital.com>
- Date: Tue, 3 Dec 2024 23:08:08 +0000
- To: Leonard Rosenthol <lrosenth@adobe.com>, Christopher Allen <ChristopherA@lifewithalacrity.com>, Andres Olave <andres.olave@velocitycareerlabs.com>
- CC: Manu Sporny <msporny@digitalbazaar.com>, Steve Capell <steve.capell@gmail.com>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <DM6PR13MB3131063AA6E9A626C94489029D362@DM6PR13MB3131.namprd13.prod.outlook.com>
Leonard, thanks very much. For those of us who are not OSCP experts, your answer is very enlightening. But it leads to another question: if OSCP stapling solves the privacy problem, why did the CA/Browser Forum vote to force a move back to CRLs? What case do they have that CRLs are a better solution? Thanks, =Drummond From: Leonard Rosenthol <lrosenth@adobe.com> Date: Monday, December 2, 2024 at 10:52 PM To: Drummond Reed <Drummond.Reed@gendigital.com>, Christopher Allen <ChristopherA@lifewithalacrity.com>, Andres Olave <andres.olave@velocitycareerlabs.com> Cc: Manu Sporny <msporny@digitalbazaar.com>, Steve Capell <steve.capell@gmail.com>, W3C Credentials CG <public-credentials@w3.org> Subject: [EXT] Re: Goals and Requirements for DID Method Standardization? OCSPs can be used in two different ways – either pre-fetched (also called “stapled” - https://en.wikipedia.org/wiki/OCSP_stapling) or not. There is no question that the non-stapled version has a phone home problem, as noted on that Wikipedia page and was a key reason for designing stapling. It wasn’t the only reason for pre-fetching and storing OCSP responses - PDF (ISO 32000) has been doing this for almost 20 years now, not only for the privacy issue but also because it improves long term validation scenarios. Leonard From: Drummond Reed <Drummond.Reed@gendigital.com> Date: Sunday, December 1, 2024 at 8:06 PM To: Leonard Rosenthol <lrosenth@adobe.com>, Christopher Allen <ChristopherA@lifewithalacrity.com>, Andres Olave <andres.olave@velocitycareerlabs.com> Cc: Manu Sporny <msporny@digitalbazaar.com>, Steve Capell <steve.capell@gmail.com>, W3C Credentials CG <public-credentials@w3.org> Subject: Re: Goals and Requirements for DID Method Standardization? EXTERNAL: Use caution when clicking on links or opening attachments. Leonard, when I clicked through to the Let’s Encrypt link you provided<https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/>, I was fascinated to discover that one of their primary justifications for discontinuing OCSP support was…privacy issues. To quote from their post: We plan to end support for OCSP primarily because it represents a considerable risk to privacy on the Internet. When someone visits a website using a browser or other software that checks for certificate revocation via OCSP, the Certificate Authority (CA) operating the OCSP responder immediately becomes aware of which website is being visited from that visitor’s particular IP address. Even when a CA intentionally does not retain this information, as is the case with Let’s Encrypt, CAs could be legally compelled to collect it. CRLs do not have this issue. So Let’s Encrypt is claiming that OSCP has a phone home problem, yet you stated that OCSP “is a great solution for “no phone home” revocation checking”. Which is it? I ask in part because privacy-preserving revocation is a major issue with DIDs and we still don’t have a widely accepted solution yet. Thanks, =Drummond From: Leonard Rosenthol <lrosenth@adobe.com> Date: Sunday, December 1, 2024 at 7:06 PM To: Christopher Allen <ChristopherA@lifewithalacrity.com>, Andres Olave <andres.olave@velocitycareerlabs.com> Cc: Manu Sporny <msporny@digitalbazaar.com>, Steve Capell <steve.capell@gmail.com>, W3C Credentials CG <public-credentials@w3.org> Subject: Re: Goals and Requirements for DID Method Standardization? > minimum publicly provable time stamps with no phone-home > The “no phone home” problem is exacerbated by the CA/Browser Forum forcing a move back to CRLs from OCSP (https://cabforum.org/2023/07/14/ballot-sc-063-v4-make-ocsp-optional-require-crls-and-incentivize-automation/), which had led some CAs to even stop supporting them entirely (https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/) OCSPs – and specifically OCSP stapling – is a great solution for “no phone home” revocation checking. And yet….. Leonard From: Christopher Allen <ChristopherA@lifewithalacrity.com> Date: Friday, November 29, 2024 at 7:17 PM To: Andres Olave <andres.olave@velocitycareerlabs.com> Cc: Manu Sporny <msporny@digitalbazaar.com>, Steve Capell <steve.capell@gmail.com>, W3C Credentials CG <public-credentials@w3.org> Subject: Re: Goals and Requirements for DID Method Standardization? EXTERNAL: Use caution when clicking on links or opening attachments. My challenge for long-lived VCs is that likely they require more than digital signatures, such aa additional proofs. Until we have some better choices for quantum-resistant signatures (a tough nut to crack) that means at minimum publicly provable time stamps with no phone-home or correlation (I currently use https://opentimestamps.org<https://opentimestamps.org/> and am investigating very large Sphinx hash-based co-signing). My example use case is that I have over a hundred students that got their MBA in Sustainable Systems from an accredited small college, circa 2009. The school was then BGI.edu, become Pinchot.edu, merged with Presidio.edu, acquired by Dominican College. Multiple states, multiple accreditation bodies. But they should be able to have a credible MBA digital certificate for life. They can’t currently. Other long-term scenarios are IP transfers (not only copyright & trademark but trade secrets), fiduciary and healthcare directives, marriage related (a particular challenge given same-sex marriage being illegal in many countries), etc. Even many peer credentials need to survive a peers death. Biggest challenge in this category will be physical real property, or property mixed physical with digital (art in particular). Both will need to be provable 70+ years, well into a quantum-capable future. — Christopher Allen
Received on Tuesday, 3 December 2024 23:08:15 UTC