... this may be of interest to CAOPS as it provides some information
around the deployment of RFC6962 and aims to address privacy concerns.
Also note there's a 6962-bis.
https://arxiv.org/abs/1703.02209
Mind you if there were privacy concerns I'd just build my own CT service
and keep it hidden and use the signed metadata in TLS connections (the
SCT). However, that sort of loses the "transparency" part as
transparency is only available privately.
One fine day when I have a spare moment I shall work again on my
implementation - you may recall that I implemented the Merkle tree half
- the one that provides the irreversible(ish) logs - but not the other bits.
Regards
--jens
Thought you would be interested in the following link. I am not involved with this effort, but thought this would be of interest to the CAOPS group and IGTF community.
Topic:
Future of WebPKI at F2F
"At the upcoming F2F we have several agenda slots to discuss the Future of WebPKI. I've agreed to shepherd these slots.
We are going to use an unconference format for these slots. We will collect a list of potential discussion topics and spend a little time on Wednesday sorting them and getting indications of interest in each topic. We will then take the ones with the highest interest and run three sets of breakout sessions to discuss them. For each breakout session slot there will be multiple simultaneous topics. At the end of each breakout, we will convene back as a large group and hear a brief (10 minute) summary from each breakout.
Potential topics can come from anyone. I would invite people to post ideas to the public list or questions list or to email me directly. At the F2F, there will be a drop box for additional ideas that will be open through lunch on Wednesday.
If you are not attending the F2F, or are not a Forum member, please still contribute topics you think we should consider discussing.
Here are some ideas of either topics to discuss or goals for the WebPKI that can inspire a discussion topic:
* How do we get to 95%+ of websites available over HTTPS with strong ciphersuites?
* Making HTTPS the default mode of browsers and making HTTP connections specifically marked as untrusted
* Full publication for all issued publicly-trusted certificates, whether that%u2019s via CT, a related mechanism, or something else entirely
* Certificate lifetime reduction to 13 months within 3 years, and 3-6 months in 5 years
* Much greater use of automation for certificate replacement, using standard protocols
* CAA fully deployed and implemented
* Multiple hash functions widely supported
* Better elliptic curves widely supported
* Initial support for post-quantum crypto algorithms
* What should the role of RAs be in the WebPKI?
* Should we have a base set of expectations for publicly trusted CAs regardless of type of certificate?
* How should CT information be delivered? Should all CAs include SCTs in OCSP responses?
* What requirements should there be on the use of virtualization technology when used in CA systems?
* Should name constrained CAs exist in the WebPKI? If so, what value do they provide?
* How do we enable more algorithms in the WebPKI (for example, EC signature standards from around the world)?
* Enhancing DANE with EV -- giving website owners the best of both worlds
* Using signature malleability to expedite certificate issuance
* High assurance favicons using polyglot certificates
To be clear, not all of these will be discussed or are even good ideas. We will decide what to discuss at the F2F."
Link:
https://cabforum.org/pipermail/public/2017-March/010023.html
Alan
