[Servercert-wg] Ballot SC6 v3 - Revocation Timeline Extension (Erhan TURAN)
Erhan TURAN (TÜBİTAK-BİLGEM-KAMUSM))
erhan.turan at kamusm.gov.tr
Thu Sep 13 06:37:32 MST 2018
Kamu SM votes Yes to ballot SC6 v3.
Erhan TURAN
12.9.2018 23:48 tarihinde Mike Reilly (GRC) via Servercert-wg yazdı:
>
> Microsoft votes Yes to ballot SC6 v3. Thanks, Mike
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
> Of *Wayne Thayer via Servercert-wg
> *Sent:* Monday, September 10, 2018 11:54 AM
> *To:* CA/B Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [Servercert-wg] Ballot SC6 v3 - Revocation Timeline
> Extension
>
> This ballot entered the voting period late on Friday. Voting ends this
> Friday 2018-09-14 at 20:00 UTC.
>
> On Fri, Aug 31, 2018 at 12:51 PM Wayne Thayer <wthayer at mozilla.com
> <mailto:wthayer at mozilla.com>> wrote:
>
> Here is version 3 of this ballot, incorporating changes to v2
> suggested by Bruce and Ryan (thanks!).
>
> I noticed that our current bylaws have reverted back to a
> fixed-length discussion period, so I have changed this version to
> comply.
>
>
> ==========================================
>
> Ballot SC6 version 3: 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 and Subscriber 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 the definition of Key Compromise as follows: **
>
> Key Compromise: A Private Key is said to be compromised if its
> value has been disclosed to an unauthorized person or an
> unauthorized person has had access to it.
>
> ** Modify Section 4.9.1 to read as follows: **
>
> 4.9.1.1 Reasons for Revoking a Subscriber Certificate
>
> The CA SHALL revoke a Certificate within 24 hours if one or more
> of the following occurs:
>
> 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 or is made aware 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; or
> 11. The CA is made aware of a demonstrated or proven method that
> exposes the Subscriber's Private Key to compromise, 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%7C3bb3887714ee40ee7ab408d6174ee09c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636722024955078164&sdata=HdBsH3KUPOrkQFEb8tROLB7GPhTKTl1e5f5xnTZWfgQ%3D&reserved=0>),
> or if there is clear evidence that the specific method used to
> generate the Private Key was flawed.
>
> 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
>
> The Issuing CA SHALL revoke a Subordinate CA Certificate within
> seven (7) days if one or more of the following occurs:
>
> 1. The Subordinate CA requests revocation in writing;
> 2. The Subordinate CA notifies the Issuing CA that the original
> certificate request was not authorized and does not retroactively
> grant authorization;
> 3. The Issuing CA obtains evidence that the Subordinate CA's
> Private Key corresponding to the Public Key in the Certificate
> suffered a Key Compromise or no longer complies with the
> requirements of Sections 6.1.5 and 6.1.6;
> 4. The Issuing CA obtains evidence that the Certificate was misused;
> 5. The Issuing CA is made aware that the Certificate was not
> issued in accordance with or that Subordinate CA has not complied
> with this document or the applicable Certificate Policy or
> Certification Practice Statement;
> 6. The Issuing CA determines that any of the information appearing
> in the Certificate is inaccurate or misleading;
> 7. The Issuing CA or Subordinate CA ceases operations for any
> reason and has not made arrangements for another CA to provide
> revocation support for the Certificate;
> 8. The Issuing CA's or Subordinate CA's right to issue
> Certificates under these Requirements expires or is revoked or
> terminated, unless the Issuing CA has made arrangements to
> continue maintaining the CRL/OCSP Repository; or
> 9. Revocation is required by the Issuing CA's Certificate Policy
> and/or Certification Practice Statement.
>
> ** 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 the Subscriber and any entity reporting the Certificate
> Problem Report or other revocation-related notice to establish
> whether or not the certificate will be revoked, and if so, a date
> which the CA will revoke the certificate. The period from receipt
> of the Certificate Problem Report or revocation-related notice to
> published revocation 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 ---
>
> This ballot proposes a Final Maintenance Guideline.
>
>
A comparison of the changes can be found at:
> https://github.com/cabforum/documents/compare/master...wthayer:patch-1
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2Fmaster...wthayer%3Apatch-1&data=02%7C01%7CMike.reilly%40microsoft.com%7C3bb3887714ee40ee7ab408d6174ee09c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636722024955088176&sdata=z8XJxv%2F5iGQ2CvgUR0JGc1c0%2FD7Y19oVOxCqxtuJT7k%3D&reserved=0>
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7 days)
> Start Time: 2018-08-31 20:00 UTC
> End Time: 2018-09-07 20:00 UTC
> Vote for approval (7 days)
> Start Time: 2018-09-07 20:00 UTC
> End Time: 2018-09-14 20:00 UTC
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
--
--
*Erhan TURAN*
e-İmza Teknolojileri Birimi Takım Lideri
BİLGEM/KamuSM
TÜBİTAK BİLGEM
06200 Yenimahalle, ANKARA
T +90 262 648 1818 - 8542
F +90 262 648 1800
www.bilgem.tubitak.gov.tr
erhan.turan at tubitak.gov.tr
................................................................
<http://bilgem.tubitak.gov.tr>
Sorumluluk Reddi <http://www.tubitak.gov.tr/sorumlulukreddi>
Sorumluluk Reddi
Bu e-posta mesaji ve onunla iletilen tum ekler gonderildigi kisi ya da kuruma ozel olup, gizli imtiyazli, ozel bilgiler icerebilecegi gibi gizlilik yukumlulugu de tasiyor olabilir. Bu mesajda ve ekindeki dosyalarda bulunan tum fikir ve gorusler sadece adres yazarina ait olup, TUBITAK / Kamu SM?nin resmi gorusunu yansitmaz. TUBITAK / Kamu SM bu e-posta icerigindeki bilgilerin kullanilmasi nedeniyle hic kimseye karsi sorumlu tutulamaz. Mesajin yetkili alicisi veya alicisina iletmekten sorumlu kisi degilseniz, mesaj icerigini ya da eklerini kullanmayiniz, kopyalamayiniz, yaymayiniz, baska kisilere yonlendirmeyiniz ve mesaji gonderen kisiyi derhal e-posta yoluyla haberdar ederek bu mesaji ve eklerini herhangi bir kopyasini muhafaza etmeksizin siliniz. Kurumumuz size, mesajin ve bilgilerinin degisiklige ugramamasi, butunlugunun ve gizliligin korunmasi konusunda garanti vermemekte olup, e-posta icerigine yetkisiz olarak yapilan mudahale, virus icermesi ve/veya bilgisayar sisteminize verebilecegi herhangi bir zarardan da sorumlu degildir.
******************************************
Disclaimer
This e-mail message, including any attachments, is intended only for the use of the individual or entity to whom it is addressed and may contain confidential, privileged, private information as well as the exemption from disclosure. The information and views set out in this email are those of the author and do not necessarily reflect the official position of TUBITAK / Kamu SM. TUBITAK / Kamu SM shall have no liability to any person with regard to the use of the information contained in this message. If you are not the intended addressee(s) or responsible person to inform the addressee(s), you are hereby notified that; any use, dissemination, distribution, or copying of this message and attached files is strictly prohibited. Please notify the sender immediately by e-mail and delete this message and any attachments without retaining a copy. TUBITAK / Kamu SM do not warrant for the accuracy, completeness of the contents of this email and/or the preservation of confidentiality, and shall not be liable for the unauthorized changes made to this message, viruses and/or any damages caused in any way to your computer system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180913/6a0bac63/attachment-0001.html>
More information about the Servercert-wg
mailing list