Hi all. Some areas of clarification requested from the Microsoft team:
* I don’t remember why 5 days was chosen vs. 7 or 3 days. I believe it was
we felt 7 days was too long but 5 days was reasonable. I believe we also
considered the scenario where an incident occurs on a Friday evening of a three
day weekend and the difficulty of the CA dealing with a subscriber who may be
unavailable over a weekend for a non-urgent revocation requirement. 5 days
covered that scenario without being too far past 24 hours. 3 days was felt to
be too short and 7 days seemed too long. Correct?
* Regarding point 11. Will this "given period of time" means up to 5 days
as well? Point 11 reads: “The technical content or format of the Certificate
presents an unacceptable risk to Application Software Suppliers or Relying
Parties (e.g. the CA/Browser Forum might determine that a deprecated
cryptographic/signature algorithm or key size presents an unacceptable risk and
that such Certificates should be revoked and replaced by CAs within a given
period of time)”
* There is also a bit of confusion about the following statement as it is
still governed by the 5 day requirement so we’re not sure why it’s called out
this way. “Within 24 hours of receiving a problem report, the CA is now
required to report back to both the entity reporting the problem and the
Subscriber on the CA's findings, and to work with the reporter to establish a
date by which the CA will revoke the certificate.” Should this be clarified to
include both the reporter and the Subscriber included in both steps to reduce
potential impact to relying parties. Perhaps add more clarification in this
statement:
* Report back the findings to reporter and the Subscriber within 24 hours
* Work with the reporter and the Subscriber to revoke within 5 days
Thanks, Mike
From: Servercert-wg <[email protected]> On Behalf Of Doug
Beattie via Servercert-wg
Sent: Monday, August 20, 2018 1:43 PM
To: Tim Hollebeek <[email protected]>; CA/B Forum Server Certificate
WG Public Discussion List <[email protected]>; Wayne Thayer
<[email protected]>
Cc: CA/Browser Forum Public Discussion List <[email protected]>
Subject: Re: [Servercert-wg] [cabfpub] Ballot SC6 - Revocation Timeline
Extension
Tim,
I agree that Vulnerability is different from key compromise and the actions we
take should reflect that and I think we should try to keep 12 and 13 type
events in the 5-day list.
Is our strategy to have vulnerabilities fall into the 5 day list and exploited
vulnerabilities fall into the 24 hour list?
Key Compromise: A Private Key is said to be compromised if:
1. its value has been disclosed to an unauthorized person
2. an unauthorized person has had access to the private keys
3. a vulnerability has been exploited to disclose private keys
And the remainder of the definition can be removed because those are examples
of vulnerabilities being exploited ( Debian weak and poor key generation). If
we want a list of possible vulnerabilities or bad practices, then we can put in
an appendix.
I think #13 is a special case of #12 (both vulnerabilities), so I still
recommend removing it. Is the distribution of a private key in in a software
package any different than the distribution of a private key in any other
(insecure) method?
Here’s what I’d recommend:
a) Use the new definition I listed above
b) change:
12. The CA is made aware of a vulnerability that exposes the Subscriber's
Private Key to compromise; or
to
12. The CA is made aware of a vulnerability that has been exploited to disclose
the Subscriber's Private Key; or
c) Delete #13
Doug
From: Servercert-wg
<[email protected]<mailto:[email protected]>>
On Behalf Of Tim Hollebeek via Servercert-wg
Sent: Monday, August 20, 2018 3:57 PM
To: Wayne Thayer <[email protected]<mailto:[email protected]>>; CA/B Forum
Server Certificate WG Public Discussion List
<[email protected]<mailto:[email protected]>>
Cc: CA/Browser Forum Public Discussion List
<[email protected]<mailto:[email protected]>>
Subject: Re: [Servercert-wg] [cabfpub] Ballot SC6 - Revocation Timeline
Extension
Vulnerability is different from key compromise. Replacing all the heartbleed
certificates within 24 hours would have been a huge fire drill. It’s important
to get them replaced as quickly as possible, but mandatory revocations within
24 hours is going to make things worse, not better.
There are potential mitigating factors for a vulnerability. For example, the
technical details may not be publicly known yet, or there may be no public
exploit available yet. The vulnerability might not affect all OS versions,
might be easily blocked by firewalls, and so on. The amount of effort
necessary to turn a vulnerability into a key compromise can vary from
insignificant to “lots and lots”.
A compromised key, on the other hand, is clearly compromised.
-Tim
From: Servercert-wg
<[email protected]<mailto:[email protected]>>
On Behalf Of Wayne Thayer via Servercert-wg
Sent: Monday, August 20, 2018 12:52 PM
To: CA/B Forum Server Certificate WG Public Discussion List
<[email protected]<mailto:[email protected]>>
Cc: CA/Browser Forum Public Discussion List
<[email protected]<mailto:[email protected]>>
Subject: Re: [Servercert-wg] [cabfpub] Ballot SC6 - Revocation Timeline
Extension
This has the potential to cause confusion, so I'd like to attempt to fix it.
Given that a reasonable interpretation of the existing definition of key
compromise encompasses reasons 12 and 13, but I want to leave those two reasons
in the document for the sake of clarity as Ryan suggests, maybe I should just
move those two up to the 24-hour section? I could also be persuaded that a
vulnerability is different than proof of key compromise, in which case 12 could
stay in the 5-day section and we could move "or there exists a practical
technique by which an unauthorized person may discover its value" from the
definition of key compromise to 12. What do others think?
- Wayne
On Mon, Aug 20, 2018 at 7:04 AM Ryan Sleevi
<[email protected]<mailto:[email protected]>> wrote:
On Mon, Aug 20, 2018 at 9:17 AM Doug Beattie via Servercert-wg
<[email protected]<mailto:[email protected]>> wrote:
We’re having a hard time determining the differences between the following:
The CA SHALL revoke a Certificate within 24 hours if:
3. The CA obtains evidence that the Subscriber's Private Key corresponding to
the Public Key in the Certificate suffered a Key Compromise; or
and
The CA SHOULD revoke a certificate within 24 hours and MUST revoke a
Certificate within 5 days if one or more of the following occurs:
12. The CA is made aware of a vulnerability that exposes the Subscriber's
Private Key to compromise; or
13. The CA is made aware that the Subscriber's Private Key is being publicly
distributed in a software package.
If “Subscriber's Private Key is being publicly distributed in a software
package”, isn’t that the same as #3: “obtains evidence that the Subscriber's
Private Key corresponding to the Public Key in the Certificate suffered a Key
Compromise”?
How do you see #12 in reality? What types of vulnerabilities do you envision
that could expose a subscribers Private Key that are not also consistent with
#3?
While this is the same argument that I've made in the past, I think the goal
here is to reduce ambiguity for those that might take a tortured reading of the
text.
For example, at least one vendor 'obfuscated' the private key within their
binary, requiring running the embedded private key through a transformation (I
hesitate to say decryption, since the passphrase was itself fixed within the
binary). Such a vendor might argue that the key has not been compromised until
someone reverses the binary. This resolves that ambiguity by saying that the
distribution within the binary itself constitutes a compromise, regardless of
whether a passphrase is used.
Also, the definition of Private Key Compromise is very broad, and the scenarios
in #12 and #13 would appear to fall into “Key Compromise” which further causes
confusion about them. What constitutes a “practical technique”? If we applied
this definition to #12 and #13, wouldn’t these all fall into the 24 hour rule?
Key Compromise: A Private Key is said to be compromised if its value has been
disclosed to an unauthorized person, an unauthorized person has had access to
it, or there exists a practical technique by which an unauthorized person may
discover its value. A Private Key is also considered compromised if methods
have been developed that can easily calculate it based on the Public Key (such
as a Debian weak key, see
http://wiki.debian.org/SSLkeys<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=02%7C01%7CMike.reilly%40microsoft.com%7Ccc86f18ac7f1436d776808d606dd9e4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636703946261915965&sdata=VTjxlqVQj%2F5CEUKsG10UF2UoC75AtmFi3d51%2Fj9wdZ4%3D&reserved=0>)
or if there is clear evidence that the specific method used to generate the
Private Key was flawed.
Doug
From: Public <[email protected]<mailto:[email protected]>>
On Behalf Of Wayne Thayer via Public
Sent: Monday, August 13, 2018 4:58 PM
To: CA/B Forum Server Certificate WG Public Discussion List
<[email protected]<mailto:[email protected]>>
Cc: CA/Browser Forum Public Discussion List
<[email protected]<mailto:[email protected]>>
Subject: [cabfpub] Ballot SC6 - Revocation Timeline Extension
This begins the formal discussion period for ballot SC6.
==========================================
Ballot SC6: Revocation Timeline Extension
Purpose of Ballot:
Section 4.9.1.1 of the Baseline Requirements currently requires CAs to revoke a
Subscriber certificate within 24 hours of identifying any of 15 issues
affecting the certificate. In cases where there is not an immediate threat of
misuse of the certificate, this requirement can cause undue harm to a
Subscriber that isn't capable of replacing the certificate prior to revocation.
This ballot makes a number of improvements to the revocation rules imposed by
the Baseline Requirements:
* Primarily, it creates a tiered timeline for revocations. The most critical
"reasons" still require revocation within 24 hours, but for many others 24
hours becomes a SHOULD and the CA has 5 days before they MUST revoke.
* A new "reason for revocation" was added to address the fact that there is
currently no requirement for CAs to revoke a certificate when requested by the
domain name registrant. After considering some more specific language that
required CAs to follow 3.2.2.4 to validate domain control, I settled on the
following more general "reason": "The CA obtains evidence that the validation
of domain authorization or control for any Fully-Qualified Domain Name or IP
address in the Certificate should not be relied upon."
* Reason #10 states "The CA determines that any of the information appearing in
the Certificate is inaccurate or misleading;" This ballot removes "or
misleading" because that is a subjective judgement that could effectively be
used to justify censorship, as discussed at length in relation to the "Stripe,
Inc of Kentucky" EV certificates.
* Current reasons #11 and #13 were removed from the section on subscriber
certificates because they address cases where the intermediate and/or root must
be revoked, so there isn't much sense (and some possible harm) in requiring
revocation of all the leaf certs.
* It requires CAs to disclose their problem reporting mechanisms in a standard
location: CPS section 1.5.2.
* Within 24 hours of receiving a problem report, the CA is now required to
report back to both the entity reporting the problem and the Subscriber on the
CA's findings, and to work with the reporter to establish a date by which the
CA will revoke the certificate.
The following motion has been proposed by Wayne Thayer of Mozilla and endorsed
by Tim Hollebeek of DigiCert and Dimitris Zacharopoulos of Harica.
--- MOTION BEGINS ---
This ballot modifies the “Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates” as follows, based on Version 1.6.0:
** Modify Section 4.9.1.1 to read as follows: **
The CA SHALL revoke a Certificate within 24 hours if:
1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not
authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to
the Public Key in the Certificate suffered a Key Compromise; or
4. The CA obtains evidence that the validation of domain authorization or
control for any Fully-Qualified Domain Name or IP address in the Certificate
should not be relied upon.
The CA SHOULD revoke a certificate within 24 hours and MUST revoke a
Certificate within 5 days if one or more of the following occurs:
1. The Certificate no longer complies with the requirements of Sections 6.1.5
and 6.1.6;
2. The CA obtains evidence that the Certificate was misused;
3. The CA is made aware that a Subscriber has violated one or more of its
material obligations under the Subscriber Agreement or Terms of Use;
4. The CA is made aware of any circumstance indicating that use of a
Fully-Qualified Domain Name or IP address in the Certificate is no longer
legally permitted (e.g. a court or arbitrator has revoked a Domain Name
Registrant's right to use the Domain Name, a relevant licensing or services
agreement between the Domain Name Registrant and the Applicant has terminated,
or the Domain Name Registrant has failed to renew the Domain Name);
5. The CA is made aware that a Wildcard Certificate has been used to
authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
6. The CA is made aware of a material change in the information contained in
the Certificate;
7. The CA is made aware that the Certificate was not issued in accordance with
these Requirements or the CA's Certificate Policy or Certification Practice
Statement;
8. The CA determines that any of the information appearing in the Certificate
is inaccurate;
9. The CA's right to issue Certificates under these Requirements expires or is
revoked or terminated, unless the CA has made arrangements to continue
maintaining the CRL/OCSP Repository;
10. Revocation is required by the CA's Certificate Policy and/or Certification
Practice Statement;
11. The technical content or format of the Certificate presents an unacceptable
risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser
Forum might determine that a deprecated cryptographic/signature algorithm or
key size presents an unacceptable risk and that such Certificates should be
revoked and replaced by CAs within a given period of time);
12. The CA is made aware of a vulnerability that exposes the Subscriber's
Private Key to compromise; or
13. The CA is made aware that the Subscriber's Private Key is being publicly
distributed in a software package.
** Modify section 4.9.3 as follows: **
The CA SHALL provide a process for Subscribers to request revocation of their
own Certificates. The process MUST be described in the CA's Certificate Policy
or Certification Practice Statement. The CA SHALL maintain a continuous 24x7
ability to accept and respond to revocation requests and Certificate Problem
Reports.
The CA SHALL provide Subscribers, Relying Parties, Application Software
Suppliers, and other third parties with clear instructions for reporting
suspected Private Key Compromise, Certificate misuse, or other types of fraud,
compromise, misuse, inappropriate conduct, or any other matter related to
Certificates. The CA SHALL publicly disclose the instructions through a readily
accessible online means and in section 1.5.2 of their CPS.
** Modify section 4.9.5 to read as follows: **
Within 24 hours after receiving a Certificate Problem Report, the CA SHALL
investigate the facts and circumstances related to a Certificate Problem Report
and provide a preliminary report on its findings to both the Subscriber and the
entity who filed the Certificate Problem Report.
After reviewing the facts and circumstances, the CA SHALL work with any entity
reporting the Certificate Problem Report or other revocation-related notice to
establish a date when the CA will revoke the Certificate which MUST not exceed
the time frame set forth in Section 4.9.1.1. The date selected by the CA SHOULD
consider the following criteria:
1. The nature of the alleged problem (scope, context, severity, magnitude, risk
of harm);
2. The consequences of revocation (direct and collateral impacts to Subscribers
and Relying Parties);
3. The number of Certificate Problem Reports received about a particular
Certificate or Subscriber;
4. The entity making the complaint (for example, a complaint from a law
enforcement official that a Web site is engaged in illegal activities should
carry more weight than a complaint from a consumer alleging that she didn't
receive the goods she ordered); and
5. Relevant legislation.
--- MOTION ENDS ---
A comparison of the changes can be found at:
https://github.com/cabforum/documents/compare/master...wthayer:patch-1?short_path=7f6d14a#diff-7f6d14a20e7f3beb696b45e1bf8196f2<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2Fmaster...wthayer%3Apatch-1%3Fshort_path%3D7f6d14a%23diff-7f6d14a20e7f3beb696b45e1bf8196f2&data=02%7C01%7CMike.reilly%40microsoft.com%7Ccc86f18ac7f1436d776808d606dd9e4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636703946261925974&sdata=ZF1OJR2W60OJ9%2BA1c4BlDwDEQVzFc3ze2gI87AXrXow%3D&reserved=0>
The procedure for approval of this ballot is as follows:
Discussion (7+ days)
Start Time: 2018-08-13 19:00 UTC
End Time: Not before 2018-08-20 19:00 UTC
Vote for approval (7 days)
Start Time: TBD
End Time: TBD
_______________________________________________
Servercert-wg mailing list
[email protected]<mailto:[email protected]>
http://cabforum.org/mailman/listinfo/servercert-wg<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=02%7C01%7CMike.reilly%40microsoft.com%7Ccc86f18ac7f1436d776808d606dd9e4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636703946261935982&sdata=o5VhYd5QGEiWefWo1P4jkRtFfioP%2FkeEx2nJYGXLo%2FY%3D&reserved=0>
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
