[cabfpub] Public Minutes of CA/B Forum Teleconference May 14, 2015

[Dean Coclin]

Minutes May 14, 2015


Attendees: Dean Coclin, Ben Wilson, Doug Beattie, Gerv Markham, Atsushi
Inaba, Kirk Hall, Atilla Biler, Bruce Morton, Burak Kalkan, Cecilia Kam,
Davut Tokgoz,  Volkan Nergiz, Rick Andrews, Moudrick Dadshov, Eddy Nigg, Mat
Caughron, Tim Hollebeek, Patrick Tonnier, Billy VanCannon, Jeremy Rowley,
Robin Alden, Ryan Sleevi

 

1.       Minutes of 30 April meeting were approved. These will be posted to
the public list. 

2.       Ballot 149 (Bylaw updates from Kirk): Kirk wants to hold the ballot
until the WebTrust audit team determines what the new name of the audit will
be. 

Domain Validation Ballot: There are a few open issues on this ballot: 

1. Working on revising #10 from the list. Some folks were concerned with the
"test cert" provision. Tim H said the test cert should be allowed and that
#10 needs to be tightened up. A longer discussion in the working group is
warranted. Kirk also said it needs more details to make it more like methods
6-9 (which are explicit). Ryan also agreed. Jeremy said he put Doug's
proposed method in the proposal for now.

2. The "random value" was 128 bits but Kirk wanted it back to 112 bits. Kirk
said that 128 bits was overkill. The random value is provided by the CA to
applicants so it's not practically predictable by hackers. Kirk felt the
lower value is adequate (and is commonly used for some other purpose). Ryan
disagreed and said there were threats like reversible random number
generators and things like passive observation which may allow for
reconstruction of the RNG. He would like to see the standard to be 128 bits.
Tim said he also had these concerns but after looking into Java Secure
random generator (which apparently doesn't do 128 bits) he felt it was
cryptographically secure and is no longer concerned. Gerv said the
cryptographic strength of the generator is more important than the bit size
but feared that specifying a smaller key size would lead people to use a
less secure RNG. Kirk challenged the security issue. Ryan further explained
(and said we should err on the side of caution) that a network based
adversary could observe traffic sent to a CA's customer and (theoretically)
predict a random number challenge sent to a future customer and cause a
miss-issuance which is not the CA's fault. Gerv suggested a compromise of
specifying a cryptographically strong random number generator (with a lower
key size) instead of specifying a higher key size (which would include the
Java generator but not the Windows GUID generator).  Doug said an adversary
could submit an order and get a random string back w/o monitoring the
network (Ryan's example threat). Ryan said it depends on the type of cert
(OV/EV vs DV). Rick said how would an auditor determine if a RNG is
cryptographically secure. Ryan said in theory they should but in reality,
recent reports and events prove they probably don't. But he said it could be
an auditable requirement. Tim H. said that in the financial industry, this
type of thing gets audited all the time. Kirk said this is not the place we
should be focusing this type of effort. Ryan asked what harm a requirement
for 128 bits would cause. Kirk said what CAs are using today may not meet
that requirement and it would be a wasted effort to get people to switch for
no real benefit.  Ryan said there are already requirements for
cryptographically strong random number generators but Kirk said for this
issue, it wasn't that important. Discussion was terminated due to time
constraints. 

3. #6 Anoosh commented (in a thread) that he doesn't like the well-defined
path item. 

3.       Membership Application, China Financial Certification Authority: We
have received an application CFCA. IPR was signed and they appear to meet
all the CA membership criteria. Dean to double check with the applicant to
make sure the signed is authorized to sign on behalf of the company.
Otherwise, the application was conditionally approved.  Mat asked if there
was a relationship between this entity and the Chinese Government and
wondered if there were other Government owned CAs in the Forum. Atilla said
that the Government CA of Turkey under Tubitak, is a Government owned CA.
Mat thought it might be helpful to put those CAs in another category. Dean
said Izenpe is also owned by the Spanish Government. Gerv asked if CFCA were
a Government CA, would we treat their application differently?  The answer
from the floor was no. There is nothing in the bylaws that state that. Mat
said it would be helpful to understand which companies are public and which
are owned by Governments. Especially when security incidents occur, private
companies may be motivated to act differently. Dean suggested we discuss
this further on another call or F2F meeting and we approve this request as
is. Kirk suggested we ask in our application whether or not it is a
Government applicant. Gerv said it isn't relevant to their application and
we should not ask it there. A discussion ensued on who audits Government CAs
because sometimes it's not a 3rd party auditor but ended w/o conclusion. Mat
said the cross signing habits of Government CAs and Company CAs are
different and this should be noted for the browsers when managing the risk.

4.       Optional OIDs for IV and EV: Dean said we don't have optional OIDs
for IV and EV (but we do for Domain validated and "Identity" validated) in
the BRs and suggested we add these OIDs in section 9.3.1. Moudrick supported
this approach. Dean said Jeremy would have to request these OIDs as he is
the CA/B Forum "OID custodian". Kirk said it was probably a good idea and
said that the current OID for OV doesn't say OV but rather "Identity
Verified". Jeremy said it was because it encompassed both IV and OV. But now
it can be separated. Eddy also endorsed. Dean suggested that he and Jeremy
work on a ballot. 

5.       Qualified Auditors: Jeremy would like to see auditors be
"certified" and he will circulate some language around this. Apparently this
came from Jody so Jeremy will work with him on a discussion email. 

6.       EV Wildcards: This came up at the last face to face meeting. There
were arguments for and against adding wildcards for EV at that time. Ben
said that EV was originally based on anti-phishing and wanted certs to not
have misleading info in the server name. Ryan said that a hosting site (i.e.
appspot, azure, aws) could have *.appspot.com issued to Google Inc while
hosting subdomains representing different logical organizations. Gerv said
this might "mislead" people into who they were dealing with. Ryan said that
he doesn't agree with the cons on this.  Gerv suggested we try to reach
consensus on what is the goal of the information in the certificate. What
does it represent? Ryan agreed and said that this is a separate discussion.
Dean said wildcards are currently forced on the least authenticated customer
(DV). Ryan disagreed.  Eddy supported wildcards in EV but not DV.  Ryan said
Google would not support Wildcards in OV (as a minimum). Dean suggested we
add this to the F2F agenda. Jeremy would also like to see adding to the
agenda a topic on 27 vs 39 month validities.

7.       Validation Working Group: No further updates other than domain
validation. Jeremy also circulated a draft for legal existence on attorney
opinion letters which will become a ballot. Ryan said he had some concerns
which he will write up. 

8.       CSWG: Dean said the group is waiting on one final section change
(Appendix A) before releasing the document to the forum for ballot

9.       Policy Review Working Group: Ben sent out an email with the status
of the group

10.   Info Sharing Working Group: Call tomorrow 1600 UTC, talking about
TAXII gateways to share information

11.   Other Business: CA Day in Berlin June 9th, Ben and Moudrick will
attend.

12.   Next meeting: May 28th. Adjourned.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20150529/20fe6462/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6130 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20150529/20fe6462/attachment-0001.bin