[cabfpub] Notes of meeting, CAB Forum, 10 January 2013

[Moudrick M. Dadashov]

Hi Ben,

do you count those on skype? If the voice quality remains as stable as 
it's been on the last 2 calls, I'll be happy to join again.

Thanks,
M.D.

On 1/31/2013 8:00 PM, Ben Wilson wrote:
>
> Notes of meeting
>
> CAB Forum
>
> 10 January 2013
>
> 1.   Present:  Maarten Van Horenbeeck, Stephen McHenry, Atsushi Inaba, 
> Ryan Koski, Gerv Markham, Brad Hill, Dean Coclin, Rick Andrews, Robin 
> Alden, Mert Ozarar, Atilla Biler, Cagdas Funda, Jeremy Rowley, Eddy 
> Nigg, Sissel Hoel, Ryan Sleevi, Steve Roylance, and Kirk Hall.
>
> 2.   Agenda Review: the agenda was reviewed and Ben mentioned that 
> Phill Hallam-Baker had contacted him previously to make sure that CAA 
> was discussed, and he thought it could occur later after the 
> discussion of Turktrust.  Phill was not on the call, but joined near 
> the end of the call, and we discussed CAA under Item 9. Other Business.
>
> 3.   Approve Minutes of 6 December 2012: The minutes of 6 December 
> 2012 were approved as published.
>
> 4.  OCSP AIA requirement (Remaining BR Issue 7)
>
> Ben said that we need to wrap up the correction needed on BR Issue 7 
> (Mistake in Exhibit B -- Stapling is not an exception to having the 
> OCSP AIA in a certificate)
>
> 5. WebTrust / ETSI Audit Implementation Cycles
>
> Dean said that we need to coordinate better on implementation 
> timeframes and auditability.  A working group was formed to hammer-out 
> the details.  Members of the working group are Don Sheehy, Iñigo 
> Barreira, Dean Coclin, Kirk Hall, a representative of Google (TBD), 
> Kelvin Yiu/Tom Albertson, Gerv Markham, and Jeremy Rowley.  The 
> objective/goal of the working group will be to come back to the group 
> as a whole with a recommendation of how coordination among document 
> revision cycles for requirements, audit criteria, auditing, and 
> browser compliance should work.
>
> 6.  Discussion of TURKTRUST facts
>
> Mert and Atilla presented the facts of the Turktrust-issued 
> certificate to EGO that had CA=True.  Atilla explained that they had 
> provided an update on their web site and via email.  The event 
> occurred on August 8, 2011, prior to / during preparation for audit 
> certification.  Since November 2011 Turktrust has been compliant with 
> ETSI audit requirements.   Then in December 2012 they discovered the 
> faulty certificate, and have now improved their existing Change 
> Management procedures. The post-issuance logs examine certificate 
> contents and extensions.  These are checked by an internal audit 
> process.  He also said that they have also discussed the case with 
> their KPMG-BSI auditors who will perform an additional limited scope 
> audit for change management, incident management, and internal audit 
> processes.
>
> Ben asked about the Checkpoint Firewall issue and whether other 
> certificates besides the one issued to Google had been discovered.  
> Atilla recounted that the Google certificate was detected by Google, 
> but he has no further information about any detection or usage of any 
> other certificate out of the EGO domain.
>
> Rick Andrews asked about Turktrust's plans to implement the Baseline 
> Requirements and the Network and Certificate System Security 
> Requirements.  Atilla said that ETSI requirements for networking 
> security have all been implemented and the Baseline Requirements that 
> are referenced in the final ETSI standard are implemented and audited 
> by their auditors.   Rick noted that the current Turktrust CPS did not 
> mention the "Baseline Requirements." Atilla said they hadn't yet 
> declared conformance to the Baseline Requirements, but they will 
> declare at some point.  They have had discussions with KPMG-BSI 
> Netherlands, their ETSI auditors, and they will first comply with ETSI 
> audit requirements and then CABF Baseline Requirements.
>
> Stephen McHenry asked what procedures Turktrust had in place to detect 
> whether any subCA certificates had/have been issued.  Mert said that 
> they had checked the audit logs for any certificates with those 
> CA=true condition, and the only two certificates they found were the 
> EGO one (ego.gov.tr) and one to e-islem.kktcmerkezbankasi.org.  In 
> addition to the existing controls coming from ETSI requirements, 
> currently Turktrust has implemented an independent post-process 
> control and a runtime control that runs live.   The post-process 
> control can additionally be run as a chron job to review such fields 
> as BasicConstraints, AIAs, and the pathlengths of subCAs. Stephen 
> asked how quickly are they detected after issuance, assuming that 
> somehow the certificates make it past the current controls due to 
> software errors, runtime errors, or whatever-to detect the situation 
> after it has occurred.  Mert said that they had previously explained 
> how the misuse of the profiles had originally caused the problem and 
> that if the runtime controls do not prevent a certificate from making 
> it to the database the scan can be run on demand through the 
> certificate database as a completely independent process that checks 
> the certificates.  Stephen said that Turktrust should run the process 
> routinely because software errors do happen. Mert agreed and said they 
> would run the process as a chron job periodically, but that he 
> believed that they already run it daily already.
>
> 7.  Discussion of preventative / remedial measures
>
> Ben asked for discussion on additional preventative or remedial measures.
>
> Jeremy said that he was working on an additional set of CA controls, 
> such as developmental controls, because we already said during 
> adoption of the Baseline Requirements and Network Security 
> Requirements that we were going to come back and address some of the 
> issues raised by the Diginotar situation later.  He said he hoped to 
> have a draft out soon and that volunteers were welcome.  Robin said he 
> would help.
>
> Rick asked whether Turktrust only issued certificates to Turkey, and 
> if so, then Name Constraints might be used as a preventative measure?  
> Atilla said that they do not issue any certificates in the US so far, 
> but that doesn't tell the whole story because they issue certificates 
> to .com domains and to many sites all around the world that have 
> physical locations and data centers within the United States. Atilla 
> said that therefore a name constraint of .tr would not work, because 
> there would be too many negative effects.
>
> Maarten asked if anyone knew whether the EGO subCA certificate was 
> installed on the Checkpoint Firewall intentionally to inspect 
> traffic.  Atilla said that he does not know because it happened at a 
> customer site.  What we do know is that at one point it was installed 
> on a server and was detected by Chrome.  The assumption is that the 
> firewall was intended to inspect traffic, but he is not sure whether 
> EGO or Checkpoint Turkey will release any announcements or final 
> reports, but that hopefully they will.
>
> Eddy suggested that we scan certificate databases at EFF and elsewhere 
> for certificates on SSL servers where CA=true and other similar 
> criteria.  Ben suggested that Eddy write a note to EFF, Ivan Ristic, 
> Yngve Pettersen, and Bernhard Amann at Berkeley to see if they are 
> interested in running such scans, even if only for academic reasons or 
> out of curiosity.
>
> 8.  Logistics of next face-to-face meeting
>
> Gerv said that they are expecting at least 24 people and there will be 
> enough seats, but any one arriving beyond that number might anticipate 
> standing or sitting along the wall.
>
> 9.  Any Other Business
>
> Ben asked about involvement of invited experts like Yngve who sign the 
> IPR Agreement.  They have posting privileges on the public list, but 
> what about their ongoing allowed participation?  While it depends on 
> each proposal, for instance with the revocation group, those who have 
> signed the IPR Agreement should be able to participate. Dean said he 
> thought it was a good idea to improve the rules in this area. Kirk 
> noted that while we have observer status for entities like WebTrust, 
> ETSI, and PayPal, but that there are plenty of people in the world who 
> might qualify as experts and that allowing participation just on that 
> alone won't work and we do allow them to participate in working 
> groups---so he would oppose opening up greater participation in 
> meetings and regular phone calls to that category.  Kirk said he was 
> open to working with Dean on this issue.  Ben said that the working 
> group is one approach to segregating discussions off from the main 
> group, but the other approach is to have very stringent rules on which 
> experts will be invited or qualified to participate as invited 
> experts. With the first approach we'd have to make sure that there is 
> a working group in which someone interested could participate, with 
> the second approach we'd have to decide what the qualification steps 
> and voting percentage would be to approve someone as a permanent 
> invited expert.  There would have to be sufficient rules around the 
> latter approach so that we would not be accused of being too 
> exclusionary.  Jeremy said if all of the discussion took place on the 
> public list, the only thing that such individuals would not have would 
> be voting rights.  Ben noted that they would get to participate in 
> live discussions.  Kirk said that where we determine that an 
> individual has enough expertise we could invite them to speak as a 
> guest.  Ben agreed.
>
> Phill joined the call and those who stayed on continued with a 
> discussion of the CAA record proposal. Phill said he'd like to put 
> forward a proposal that CAA be required.  Rick said that there are 
> several solutions that have been proposed and he wondered if we 
> mandated CAA whether people would stop looking at the alternatives or 
> whether they would implement "all of the above" or what.    Phill said 
> that CAA does something that nothing else does, which is it allows 
> companies to say, "do not issue certificates for my domain unless 
> you're one of my approved CAs."  Everything else, CT and DANE, are 
> looking at either client enforcement or detecting anomalies and 
> reporting them.  Because CAA is different than CT or DANE, adopting 
> one solution does not exclude the other.  Ben noted that during our 
> December call we discussed using the word "should" rather than "shall" 
> except when necessary to mandate a global solution.  Phill said that 
> CAA only requires that you look at the CAA record, nothing other than 
> that.   Ben said he understood Phill's position on how CAA would be 
> implemented, but that as Phill is trying to draft and put forth a 
> motion that will pass, maybe he should consider using the word 
> "should" rather than "shall."  Phill said that it may not need to be a 
> "shall" depending on how CAA is adopted by the domains --- whether it 
> is by the 100s or the 1000s.  Jeremy said he was apprehensive about 
> adopting a requirement in the CA/B Forum if it were seen as an abuse 
> by the CAs in locking in existing customers making it harder to get a 
> certificate without a corresponding benefit.  Phill said that the 
> issue had been raised at the IETF and so they specified a mechanism 
> for obtaining the data and stating that how you treat that information 
> is up to you.  So, if you state, "we don't observe the records in this 
> TLD data," so long as it is in writing, you are complying with the 
> IETF. Ben said that it will be interesting to see what the registries 
> do.  Phill noted that the registrar for xxx was trying to place a 
> variety of controls on their registrants. Rick said that in discussing 
> concerns with encountering CAA records he wasn't sure how difficult it 
> would be to get the customer to just go off and update their CAA 
> record.  Ryan K. said he knew about the previously expressed CA 
> concerns, but that it also will increase the support time burden and 
> some CAs may even start to require customers to set up a CAA record 
> before they'll issue a certificate to the customer and the CA could 
> have a tool during the application process that says, "hey, you don't 
> have a CAA record," so I share these concerns.  Ben asked that anyone 
> interested in endorsing Phill's proposal coordinate with him, and Rick 
> advised Phill that it would be good to also get at least one browser 
> to endorse it as well, since he will need more than 50% of the browser 
> vote, too.
>
> 10.  Meeting adjourned until the Next Call -- Thurs. January. 24th
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130201/73eb230e/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2457 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130201/73eb230e/attachment.p7s>