The day started with discussion of the agenda.
KC points out that plan to allow users/communities to better able to manage the TAs and their issued certificates, is to set the CAs up for failure. SR responds that within CAB Forum there are representatives who have some control of user interfaces and clients, which could take action on behalf of the user. MS reminds us that some users will want control of TAs, etc.
Research proposals cover replacement and / or improvement of existing systems.
Proposals include
Convergence builds on Perspectives.
Regarding DANE, KC noted that some DNSSEC implementations use CAs as the basis for their trust.
There are few DNSSEC roots of trust, creating a single point of failure for the entire system. Clients don’t have DNSSEC validation implemented.
Client can’t pin to a cross-certifying root. E.g. DigiCert is cross certified with Federal Bridge. The whole chain is pinned, but different clients could have different trust paths (not pinned).
Key does not have to be verified by CA. Can be revoked by holder.
Compromised ICAs were issuing certs for sites they shouldn’t have. With Sovereign Keys, sites could have taken action.
KC points out that users would be required to update browsers and OSs. However, browser updates may actually be easier than OS updates.
Max Pala mentioned at last IETF that browsers could have put tools in hands of users.
CAs log issuance to log. KC notes that citibank (SLCS) may make log very big.
MS asks, are commercial CAs worried about revealing too much information to competitors? SR acknowledges this, but note that EFF SSL Observatory, similar Google repository, etc. will reveal public information. RKM and MS note there may be certificates of private interest.
Methodology defining categories of comparison, rating scale.
RKM and others mentioned that it would be nice to include OCSP, CRLs, etc.
MS is surprised that nobody raised the issue of managing trust anchors with TAMP. SR would like to add TAMP to the list.
MS says that some people might view the metrics from a different angle and you weigh them the same. SR notes that in the paper they will justify the score. DS also points out that some of the technical solutions may be more difficult than finding an alternative approach to managing the risk: how can the risk management be done more cost-effectively.
SR notes three things: 1) include TAMP, 2) not just on technical solutions, 3) weighting for categories,
KC adds that this should serve as a basis for focussing work (i.e. in CABForum or IETF).
KC notes that it might be possible to find the “best of breed” for different categories. SR agrees and paper has some discussion of forms of trust, etc. (TTPs, DNSSEC, Host-based (pinning / sovereign), log/audit).
JW says that the report is missing, generally, what kind of risk is being mitigated.
13 / 96 IGTF CAs offer CRLs over IPv6.
CAs will be required to make CRLs available over IPv6 by October 2012.
There is not widespread support of OCSP in IGTF.
MS mentions using lightweight OCSP, over GET, that can be cached. Find out if libraries can support stapled OCSP. Does code have to be changed, or is it a configuration issue? Server would have to do something. Worth finding out where we are.
CP/CPS should allow for OCSP signing cert, but this implies that the chain (including the delegated responder) has to be included, which works against lightweight OCSP.
CT says if CA’s don’t fall in SHA-2 trap they will fall in OCSP trap. There are parts of middleware that may not use OpenSSL but look at CRL directly.
Request to have OCSP in 6 months, with AIA in credentials after that. Easy way is to do OpenCA OCSPD and feed it CRL. Many CAs could use some guidance.
DOC asks what lifetimes, etc. are acceptable? SR says it is acceptable to pre-compute OCSP responses with future dates (e.g. for one month in advance) but need to control release.
DG requests that people with OCSP documentation should post it to the mailing list. Try to enforce this by January 2013.
RKM points out that it should work on IPv6.
DG requests volunteers to contribute text. JW will get feedback from PRACE community. SR is willing to massage text.
DS notes that great value of the document is to explain why changes are necessary. ACTION for all is to look at our own infrastructure for capability and report.
KC says that SHA-2 has possibly seen less validation than IPv6.
IGTF CAs should be able to report by 1st October that they can do it.
KC suggests shortening lifetime of SHA-1. Or set limit (400 days after 1st Jan 2013).
(side-request from DS to draw a diagram)