Attendees: Doug (GS), Rick (Symc), Ryan (Google), Atsushi (GS), Atilla + Volkan and Kubra (TurkTrust), Eddy (Startcom), Chris (Trustwave), Rich (Comodo), Davut (E-Turgra), Wayne (GoDaddy), Kirk (Trend), Mads (Buypass), Peter (Disig), Ben, Jeremy (Digicert), Kelvin (MSFT), Moudrick, Tim S. (Trustwave), Robin (Comodo), Candice (OATI), Tim H (Trustwave), Mat (Apple)
Minutes of Nov 13th were approved.
Jeremy to post final version of his proposal/ballot. Will allow CAs to issue certs to .onion domains post the 2015 deprecation date. These are used in TOR networks which doesn’t use a traditional naming system. Instead part of the hash of the key is your name. Ryan Sleevi has offered to endorse.
Kirk: Please describe the differences in the issuance process between this and normal certificates.
Jeremy: Only difference is in how the domain name is validated because there is no whois record. Instead people sign up for it by generating keys and using that key for the domain name. So you need to do a practical demonstration of controls. There are 2 ways to do this:
- Generate a CSR signed by the .onion name
- Use the well-known RFC URL which Jeremy has applied for with Mark Nottingham
IETF is managing the well-known URL so all we need is the CABF to do its part.
Ryan: Also want to add that we are trying to get IANA to make .onion a reserved name.
Kirk: Couldn’t two people generate the same public key?
Ryan: .onion is not a centrally managed registry and yes two people with the same key can generate the same name. Currently uses a SHA-1 hash. The proposal allows for a means for CAs to detect when a possible collision could happen.
Tim (Trustwave): Why not vote no on the condition that .onion be a reserved name and that they use SHA-256?
Jeremy: SHA-256 would require a change to the entire protocol (which isn’t imminent).
Gerv: We have to figure out if we vote yes, does this disincentivize the Tor folks from moving to SHA-256. Also, if we pass this now, we will have to pass it again in 9 months when internal server names are sunsetted.
Ben: We could add a sunset provision to the ballot.
Gerv: It has one automatically
Tim: I like the proposal to make it explicit
Kirk: Why doesn’t Tor run a registry to identify domain owners?
Ryan: Tor is all about anonymity. Some browser features are only exposed over https and .onion would want to use those “services”
Gerv: WebCrypto is one example of those services. If the page is not served over https (at least in Chrome), then .onion couldn’t use WebCrypto.
Ryan: WebCrypto is probably a poor example because of political discussions there. The W3C though is working to define how this behaves. Other services include Service Workers or Push Messaging both of which reference W3C. A number of sites have features that take advantage of things like Content Security Policy which basically say “I expect everything to be over https. Browsers should block things that are not over https”. Facebook is a prime example of this but there are a number of other sites that do it. Want to be able to expand this to Tor hidden service w/o introducing security holes to their sites.
Jeremy will circulate a ballot once he checks where the RFC is (for reserving the onion name)
Gerv: Cautiously optimistic on Kirk’s ballot (still evaluating). Believes all members wants to get rid of insurance. Would like to see both ballots proceed in tandem. Doesn’t want unnecessary barriers to entry. Mozilla will study Kirk’s proposal more.
Jeremy: Digicert wants to keep the insurance.
Kirk: CAs should show the public that they do add great value to Internet security and by passing this ballot, this would improve that perception.
Doesn’t think CAs should be able to disclaim all liability (as stated in the BRs). CAs should retain some liability for mis-issued certs. Agrees that both ballots can go side by side. Feels this is a good way to show the public that we stand behind our product, unlike software vendors who disclaim all liability in their EULAs.
Atilla: From an auditors perspective, how would an auditor verify the requirements in this ballot (if I don’t have insurance)? What should I give the auditor to prove I have financial responsibility? Kirk: Insurance and liability are different things. Some CAs may want to buy insurance to cover liability but this ballot would not require any CA to buy insurance. Larger CAs may wish to self-insure.
Atilla: What should I have in my hand to show an auditor?
Gerv: It’s up to you and your lawyers.
Eddy: Suggest adding an upper limit to overall liability to cap it. Then someone can get insurance for it.
Kirk: Current Section 18 is not limited. Would be possible to introduce aggregate limits. Your CPS and agreements can limit overall claims. May/may not be successful, depends on courts in your jurisdiction.
Eddy: But could be a solution for Atilla if a cap was stated.
Atilla: Maybe we should get opinion from WebTrust/ETSI auditors.
Kirk: Don would probably say that he wants to see your agreements to see what you say you are liable for. He wouldn’t ask for your financial statement.
Gerv: The new way of doing it gives relying parties the ability to make claims (rather than the current policy of insurance) and it’s up to the CA to decide what insurance they may or may not need.
Ryan: Only relying parties can recover. Companies like Google who are not a relying party but may have suffered brand reputation from a mis-issuance don’t benefit. Doesn’t think this is going to accomplish its intention vs. complexity of costs.
Gerv: If that’s the case, then the insurance to cover it won’t be expensive. So if it works, then it’s cheaper and less harmful.
Gerv: Does the clock start again on both ballots. Dean: I propose you resubmit the ballots and we restart the clock.
Gerv: No changes are being proposed. Instead of resubmitting, let’s restart in January
Dean: Let’s do Monday Jan 5th as the date of restart.
Ryan: Google cannot agree to MOU on wiki as is.
Gerv: This list was originally for CAs to share info among themselves. Seems to be scope creep.
Ben: I see 3 different lists so I’ll rework the MOU and description of the lists. A CABF list for our public website (no MOU), an emergency list (not public), limitations of use list.
Istanbul meeting: will be week of October 5th
Mat: would like to know what the CA’s proposed deprecation schedules are. Apple hasn’t publicly released anything yet. Would like to see CA’s schedules in light of Microsoft and Google’s announcements. Please send memo to list with what you are planning.
Ryan: Several large server operators have reached out to Google. Question as to whether CAs infrastructures support IPv6 specifically OCSP/ CRL. Is there any sentiment for adding IPv6 capability to BRs. What timescale? Would need to support both IPv4 and v6.
Ben: What about CT?
Ryan: CT is not covered under the BRs. If the CA is operating a log, then it has to be v4 and v6 capable.
Kirk: Can you write up a short explanation so we can take back something to engineers.
Ryan: Just wanted to introduce it today but that’s something we will do if there is demand.
Wayne: In general, IPv6 drives network infrastructure upgrades. Need to talk to IT departments since they are the ones that have to buy the gear to implement.
Gerv: Have you (Ryan) done the research to scan your certs to see if there is demand for this?
Ryan: Not yet
Ben: I believe Globalsign said they support IPv6
Robin: Comodo does as well
Rick: We’re not getting hardly any demand for this and we don’t support it yet.