[Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 - Revocation Timeline Extension
Ryan Sleevi
sleevi at google.com
Thu Aug 23 08:44:02 MST 2018
Doug,
I'm not sure I understand - how do you see them fitting under the 5 day
rule?
On Thu, Aug 23, 2018 at 11:40 AM Doug Beattie via Servercert-wg <
servercert-wg at cabforum.org> wrote:
> Wayne,
>
>
>
> I wanted to see if we we could trim down the definition of Key Compromise
> a bit more to just this:
>
>
>
> **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.
>
>
>
> I think we can remove this from your current definition because these
> situations will fall under the 5 day rule, not the 24 hour rule:
>
> “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) or if there is clear
> evidence that the specific method used to generate the Private Key was
> flawed.”
>
>
>
>
>
> *From:* Wayne Thayer <wthayer at mozilla.com>
> *Sent:* Tuesday, August 21, 2018 4:58 PM
> *To:* Ryan Sleevi <sleevi at google.com>
> *Cc:* Bruce Morton <Bruce.Morton at entrustdatacard.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Mike
> Reilly (WDG) <Mike.Reilly at microsoft.com>; Doug Beattie <
> doug.beattie at globalsign.com>; Tim Hollebeek <tim.hollebeek at digicert.com>;
> CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 -
> Revocation Timeline Extension
>
>
>
> Thanks for the comments Mike. Based on the discussion, I would propose two
> changes:
>
>
>
> 1. Regarding your second point about "The technical content or format of
> the Certificate presents an unacceptable risk", my interpretation of the
> language in the context of the section is that the "given period of time"
> must be no more than 5 days, which doesn't make a lot of sense. Bruce's
> interpretation seems more reasonable but not what the current wording
> really means. If this language only comes into effect after a deadline is
> set, as implied by the example, then any requirement to revoke can be
> stipulated by whomever set the deadline (root program or CAB Forum ballot).
> It follows that this reason for revocation (in both the Subscriber and
> Subordinate CA sections) is unnecessary and can be removed.
>
>
>
> 2. Regarding the third point, add the Subscriber in addition to the
> "entity reporting the Certificate Problem Report" as someone to consult
> when deciding when to revoke the certificate. I think the other
> clarifications you suggested are already covered.
>
>
>
> Here are the changes I've captured from the discussion to-date:
>
>
>
>
> https://github.com/wthayer/documents/commit/2d427a74f604d635609602bed2808e5d96ee03ad
>
>
>
> I'll publish a 'version 2' of the ballot when it appears that there are no
> further concerns.
>
>
>
> - Wayne
>
>
>
>
>
> On Tue, Aug 21, 2018 at 10:08 AM Ryan Sleevi <sleevi at google.com> wrote:
>
>
>
> On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> Per Mike’s items:
>
>
>
> 1. 7 days would be preferable as this would provide a “business
> week” for the CA to investigate the issue. It will also provide 2 extra
> days to have reach and discuss the issue with the Reporter and the
> Subscriber.
>
> As Mike summarized correctly, Google felt and feels that 7 days is too
> long. We repeatedly asked for specific examples and details of where the
> additional time would be valuable, and to date, no CA has provided them. We
> had previously proposed that anything longer should require a mandatory
> public, unredacted incident report from the CA, and the concession to avoid
> such a requirement was to find a balance, while also ensuring that CAs were
> gathering and collecting concrete reports to provide that.
>
>
>
> 2. Given the examples for unacceptable risk, I would assume that
> this item would have a deadline set in the BRs. We have done this before
> with non-registered domain name certificates. So if the certificate has not
> been revoked by the deadline, then it must be revoked immediately. As such,
> perhaps this requirement should be better defined and also moved to the 24
> hour section.
>
> 3. I do agree that the CA should work with both the Reporter and the
> Subscriber; however, please note that the investigation may mean that the
> certificate will not be revoked. Also, having a preliminary report within
> 24 hours may not be feasible to have a report with substantial substance as
> there may not be time to discuss with the Subscriber. I do suggest that
> within 24 hours the CA should advise the Reporter and the Subscriber that
> an investigation has started which may result in the certificate being
> revoked.
>
> I don't think this is something we'd agree on. As noted above, our goal is
> to improve the transparency. There are some who've said that the best
> solution to these issues is to know what it's like by going to work for a
> CA. Absent changing employers, the next best thing is going to be to
> improve the transparency of the ecosystem, which will improve the trust
> overall. CAs are already required to conduct their activities within 24
> hours - this doesn't relax that particular item, but allows them to make it
> available as a report, while offering greater flexibility. That seems a
> meaningful compromise to balance the need for transparency while providing
> CAs and Subscribers some degree of flexibility.
>
>
>
>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Servercert-wg [mailto:servercert-wg-bounces at cabforum.org] *On
> Behalf Of *Mike Reilly (GRC) via Servercert-wg
> *Sent:* August 21, 2018 12:17 PM
> *To:* Doug Beattie <doug.beattie at globalsign.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Tim
> Hollebeek <tim.hollebeek at digicert.com>; Wayne Thayer <wthayer at mozilla.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* [EXTERNAL]Re: [Servercert-wg] [cabfpub] Ballot SC6 -
> Revocation Timeline Extension
>
>
>
> 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 <servercert-wg-bounces at cabforum.org> *On Behalf Of *Doug
> Beattie via Servercert-wg
> *Sent:* Monday, August 20, 2018 1:43 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Wayne
> Thayer <wthayer at mozilla.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *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 <servercert-wg-bounces at cabforum.org> *On Behalf Of *Tim
> Hollebeek via Servercert-wg
> *Sent:* Monday, August 20, 2018 3:57 PM
> *To:* Wayne Thayer <wthayer at mozilla.com>; 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] [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 <servercert-wg-bounces at cabforum.org> *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 <
> servercert-wg at cabforum.org>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *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 <sleevi at google.com> wrote:
>
>
>
> On Mon, Aug 20, 2018 at 9:17 AM Doug Beattie via Servercert-wg <
> servercert-wg at cabforum.org> 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 <public-bounces at cabforum.org> *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 <
> servercert-wg at cabforum.org>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *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
> Servercert-wg at cabforum.org
> 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>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180823/6d99be0c/attachment-0001.html>
More information about the Servercert-wg
mailing list