[cabfpub] Updated Draft Agenda for F2F Meeting 31
Ben Wilson
ben at digicert.com
Fri Feb 14 03:00:28 UTC 2014
Gerv,
I've revised the agenda with a little more explanation. You shouldn’t read
too much into my examples below for the kinds of things we’ll talk about.
Often they’re given just to help explain the general topic. As I mentioned
on the call today, this agenda is open to revision.
Ben
WORKING GROUPS
1:30 9:10 10:40 1 RFC 3647 Conversion Group
1:30 10:40 12:10 2 SSL Performance Working
Group: Certificate Profile Best Practices for Speed (without compromising
on security)
2:20 12:30 14:50 3 Code Signing Working Group
2:10 15:00 17:10 4 Extended Validation Revisions
Working Group
DAY 1 - (Wed) 19 February 2014
0:30 9:10 9:40 5 Browser News
0:50 9:40 10:30 6 SHA1 Sunsetting /
Grandfathering Strategy: Microsoft has indicated that it will stop
accepting SHA-1 certificates on January 1, 2017, which means that CAs must
deal now with customers who are used to buying 3-year SHA1 certificates.
Support for Windows XP ends April 8th, which is one of the reasons why SHA1
certificates have still been needed. Are there other reasons why customers
will still need SHA1 certificates? Appendix A of the Baseline Requirements
currently states, "*SHA-1 MAY be used with RSA keys until SHA-256 is
supported widely by browsers used by a substantial portion of
relying-parties worldwide." What does that mean? Do the Baseline
Requirements need to be amended? If so, what is the CABF's strategy for
sunsetting SHA1 gracefully? Should the CABF adopt a rule similar to
Microsoft's SHA1 deprecation policy? What systems are out there that will
choke without SHA1 and should they be grandfathered with language such as we
have in sections 9.4.1 and 12 of the Baseline Requirements?
0:30 10:45 11:15 7 SSL Performance WG report
0:30 11:15 11:45 8 RFC 3647 Working Group report
0:20 11:45 12:05 9 Code Signing Working Group
report
0:20 13:00 13:20 10 EV Guideline Working Group
report
0:30 13:20 13:50 11 Review and discuss technical
constraints for Delegated Third Parties: A "Delegated Third Party" is "not
the CA but is authorized by the CA to assist in the Certificate Management
Process by performing or fulfilling one or more of the CA requirements found
herein." One type of Delegated Third Party is the "Enterprise RA", which
is "technically constrained" due to the fact that its Subject FQDN must be
within its registered domain namespace. Other types of delegations may
exist, and the degree to which these operations fit within the CA's audit
framework may vary, depending on the degree to which such external
operations are technically constrained or effectively controlled by
technical measures implemented by the CA. Technical constraints have been
used in the past to argue for exemptions from cost-prohibitive on-site
auditing of delegated third parties. Risk can also be mitigated by
certificate processing measures implemented by browsers--such as critical
name constraints, restricting trust anchors by purpose (SSL, etc.) or
geography, enforcing/requiring EKUs in intermediate CAs, processing policy
OIDs, etc. This agenda item is to discuss current technical methods to
prevent risk caused by third party security breach or potential certificate
mis-issuance due to the mistakes of delegated third parties.
0:40 13:50 14:30 12 Review Network and Certificate
System Security: The CABF's Network and Certificate System Security
Requirements were adopted in 2012. WebTrust has expressed concern that some
CAs in browser root programs may not be able to meet WebTrust's
interpretation / implementation of the Network Security Requirements. Are
any provisions too specific? Currently the Network Security requirements
are not integrated into the WebTrust audit criteria. ETSI indicates that
they have already been incorporated into TS 102 042. What further work
should we do, if any, to translate them into acceptable audit criteria?
Beyond review of the current Network and Certificate System Security
Requirements, are we ready to look at issues that we put on the back burner
when we adopted version 1.0? What about the concepts set forth in NISTIR
7924, which will be released again this year for another comment period?
0:40 14:40 15:20 13 Webtrust for CAs: Don Sheehy
and Jeffrey Ward will review current status of Web Trust audit criteria for
CAs.
0:30 15:20 15:50 14 EV Verification Tasks:
Richard Wang of Wosign asked a question about EV requirements and tasks
performed by attorneys, accountants, local registration authorities, site
visit companies, etc.. We'll discuss this topic to understand his question
better and provide clarification, if possible.
0:30 15:50 16:20 15 Current status of WPKOPS,
client and server capabilities: We'll discuss preliminary information from
the WPKOPS survey from Mozilla and CloudFlare's nginx/openssl responses,
information about servers from
https://wiki.mozilla.org/Security/Server_Side_TLS, client capabilities
information gathered during previous meetings, etc., about server and client
support of different algorithms, ciphersuites, chain processing, revocation
checking mechanisms, etc.
0:40 16:20 17:00 16 Coordinating Certificate
standards with other organizations: Various trading communities and
educational, research, and governmental organizations desire
interoperability of their systems with the WebPKI (i.e. publicly trusted
SSL). Examples include the International Grid Trust Federation, the US
Federal PKI, and others. These organizations often have their own
certificate requirements, and certificate policy OIDs. Section 8.4 of the
BRs is the only place where the "Trust Model" is addressed. It states, a
"CA SHALL disclose all Cross Certificates that identify the CA as the
Subject, provided that the CA arranged for or accepted the establishment of
the trust relationship (i.e. the Cross Certificate at issue)." CAs that
want to provide "dual trust" for servers that operate in two communities
sometimes encounter technical questions that require flexibility or
clarification of rules/technical standards.
As one example of this dichotomy, how should RFC 5280 or the CABF BRs be
applied to an end entity certificate or intermediate CA when the trust
anchor in one environment is different than, due to cross certification, the
trust anchor or bridge in the other congruent environment? If Policy OIDs
vary up and down the chain (they should only be removed as you go down, not
added), and browser software does not process policy OIDs in accordance with
RFC 5280, how does the CABF address this situation in a way that is flexible
but follows good security / technical practice? Is coordination or some
form of agreement or guidance from the Forum desirable in these situations?
Is better coordination with these types of outside policy groups needed?"
DAY 2 - (Thur) 20 February 2014
1:20 9:00 10:20 17 CT and Google Requirements
Discussion: Google to discuss current plans for implementation of
Certificate Transparency and root program participation.
0:40 10:30 11:10 18 ETSI Presentation: Iñigo
Barreira and Arno Fiedler will review status of ETSI's trust service
provider assessment criteria and proposed European regulation.
0:40 11:10 11:50 19 Compliance assessment
coordination with auditors and browsers: Representatives of CAs, Browsers,
and Audit Frameworks will review implementation of CABF guidelines in audit
criteria and incorporation into Browser Root Program requirements.
1:20 12:30 13:50 20 Bylaws Revisions: At the
last face-to-face meeting, we resolved to add the following membership
categories in the CABF bylaws: Associate Members (formerly known as
Observers) and specify that they are invited parties who sign the IPR and
have access to wiki and management lists and can attend meetings but cannot
vote; Invited Guests, who per the chair's discretion may attend F2F meetings
that are local, either as guest speakers or attendees without signing the
IPR policy and have no mailing list or wiki access; and Interested Parties,
who want to participate in working groups only but must sign the IPR
agreement and are added to each working group mailing list with posting
privileges.
0:40 14:00 14:40 21 What is an SSL Certificate?:
"Should the Baseline Requirements be written to prohibit the use of the
""anyEKU"" EKU and require use of the TLS Server EKU?
The Baseline Requirements seek to prohibit “Internal Server Names,” which
are defined as “[names] not resolvable using the public DNS.” It has been
argued that the Baseline Requirements address anything under a public root,
but there are certificates under public roots that will not work as SSL
certificates, so are there situations when the Baseline Requirements don’t
apply to certificates not intended for public use? Can certain certificate
profiles (such as those with an EKU other than TLS server/client) be
considered exempt because they are not or cannot be used by people with
browsers to connect to a web site? See CABF Minutes of 5 September 2013
and https://cabforum.org/pipermail/public/2013-August/002126.html ;
https://cabforum.org/pipermail/public/2013-August/002127.html; and that same
discussion thread, which started here:
https://cabforum.org/pipermail/public/2013-July/001947.html.
We might use this time to also work on the Baseline Requirements definition
of “Internal Server Name” for Ballot 112."
0:40 14:40 15:20 22 Review implementation status of
OSCP stapling and multi-stapling (RFC 6961): Discuss OCSP stapling support
and efforts toward supporting RFC 6961 multi-stapling (nginx, Apache,
Microsoft, Mozilla, etc.). What percent of current servers, sites, clients,
etc., could immediately benefit from stapling? Eventually from
multi-stapling? What is the current deployment for OCSP stapling? Where can
we obtain the greatest return on efforts?
0:40 15:20 16:00 23 New gTLDs Processing and Public
Suffix List: Section 11.1.4 of the Baseline Requirements requires CAs to
review their issued certificates within 30 days of new gTLD approval and not
issue a Certificate with that Domain Name until it confirms control of that
name by its customer, and within 120 days CAs are required to revoke such
certificates unless the Subscriber controls the Domain Name. Are there
ways to automate this? Are there ways to simplify the process or revoke /
replace certificates sooner? (i.e. are any amendments to section 11.1.4
needed?) For instance, if the Public Suffix List (PSL) is updated on gTLD
approval, could the PSL mechanism be used to determine what is and isn't
allowed? If the PSL is a complete map of the public namespace, could it be
used by CAs in some automated fashion?
0:30 16:00 16:30 24 Discuss F2F Meeting 33 in
Beijing: Richard Wang of Wosign
0:30 16:30 17:00 25 Review accomplishments / list
of tasks
-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Gervase Markham
Sent: Tuesday, February 11, 2014 4:43 AM
To: ben at digicert.com; public at cabforum.org
Subject: Re: [cabfpub] Updated Draft Agenda for F2F Meeting 31
Hi Ben,
Can you clue me in about some of these items?
On 10/02/14 21:59, Ben Wilson wrote:
> 0:30 13:20 13:50 11 Review and discuss
> technical constraints for Delegated Third Parties
What is the topic here exactly?
> 0:40 13:50 14:30 12 Review Network and
> Certificate System Security
Is this a general review of the entire "Network and Certificate System
Security Requirements" doc, or targetted. If targetted, what particular
changes are proposed?
> 0:40 11:10 11:50 19 Compliance assessment
> coordination with auditors and browsers
What is the topic here exactly?
Thanks :-)
Gerv
_______________________________________________
Public mailing list
<mailto:Public at cabforum.org> Public at cabforum.org
<https://cabforum.org/mailman/listinfo/public>
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140213/5667b75a/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140213/5667b75a/attachment-0001.p7s>
More information about the Public
mailing list