Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic
On 3/18/20 5:16 PM, Ryan Sleevi wrote:
Suggestions:
1) Rename "Audit Delay" to [audit-delay] and rename "Audit Delay COVID-19"
to [audit-delay] [covid-19] or [audit-delay-covid-19], depending
Rationale: In general, our filters work on word searches, so the brackets
brackets help distinguish the two. To search for "Audit Delay" without
considering COVID-19, the filter would have to be ("Audit" AND "Delay") AND
NOT "COVID-19". The renames help us search for "[audit-delay]" (which would
exclude Covid-19) or "[audit-delay]" AND NOT "[covid-19]", which is...
slightly easier :) This is mostly minor, but also tracks how we handled
[ca-compliance], [auditor-compliance], [delayed-revocation-leaf] and
[delayed-revocation-ca] :)
Done
2) Rename "Potential remediations" to "Minimum expectations"
Rationale: I worry that "potential remediations" may be seen as an
indefinite escape clause. As noted in the discussion of force majeure that
you've linked, in general, these clauses generally temporarily suspend
certain obligations, but may not indefinitely apply. While this situation
continues to evolve, and we will hopefully see a timely global recovery,
there exists the non-negligible possibility that it may become necessary at
some point in the future to limit or restrict trust in CAs in order to
minimize risk to users. These are absolutely case-by-case scenarios, and so
this isn't meant to scare CAs or Auditors into engaging in unsafe or risky
procedures, but more to highlight that as part of recovery from such
scenarios, it may be necessary to figure out how to transition from
uncertainy to certainty, such as rolling keys over to new
roots/intermediates. Keeping people physically safe is certainly the
pressing priority here, and we should be sensitive to that, but I worry
that "potential remediations" suggests that such measures might be
indefinitely accepted.
Done
3) Clarify ETSI documentation and disclosure requirements
Rationale: My concern with the ETSI approach is that Mozilla may not
receive the same information the auditor/CAB provides to the CA/TSP. For
example, as currently worded, it'd be impossible to discover the
limitations that the auditor might have encountered (such as a
documentation-only assessment), because that'd be normally addressed in the
engagement letter between the CAB/TSP, and beyond them, typically only the
Supervisory Body would be party to such details. While your requirements
for disclosure are unambiguous, my worry is how many TSPs/CABs using an
ETSI scheme have failed to uphold Mozilla's expectations / CCADB
expectations, and thus it wouldn't be clear when a TSP was violating policy
(e.g. by not having disclosed the situation).
Potentially: "Audit letters MUST disclose each location that was included
in the scope of the audit, as well as whether the inspection was physically
carried out in person"
There's probably a MUCH better way to word this, but the concept I'm trying
to capture is some positive affirmation by the auditor about what they did.
If a Letter doesn't include that, it's a red flag (to reject the audit). If
it does, that at least provides clarity and fits back in to the incident
report discussion.
Added the following to the top of the "Minimum Expectations" list:
* Both ETSI and WebTrust Audits must:
** Disclose each location that was included in the scope of the audit,
as well as whether the inspection was physically carried out in person.
This way we can easily add more sub-bullet points as needed.
I also added a summary to the top of the page
https://wiki.mozilla.org/CA/Audit_Statements
CA Audits are one of the primary mechanisms relied upon by Mozilla to
ensure that a CA is operating securely and in compliance with our
policies. CA audits and audit statements must comply with the following
requirements.
* Section 3.1 of Mozilla's Root Store Policy.
** An Audit Delay is when one or more of the following requirements in
section 3.1.3 cannot be met:
***"Full-surveillance period-of-time audits MUST be conducted and
updated audit information provided no less frequently than annually."
***"... MUST be provided to Mozilla via the CCADB within three months of
the point-in-time date or the end date of the period."
* Section 5.1 of the Common CCADB Policy.
* Section 8 of the CA/Browser Forum Baseline Requirements, if the root
certificate has the Websites (TLS/SSL) trust bit enabled.
Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: DFN-Verein: CPS/CP link in CCADB not in English
On Thu, Mar 19, 2020 at 7:06 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Mar 19, 2020 at 12:33:29PM -0400, Ryan Sleevi wrote: > > I'm not sure an incident report is necessary. The CCADB policy allows > both > > to be provided, and the mechanisms that CCADB uses (both for CAs and for > > Root Stores) permit a host of expressiveness (and further changes are > being > > made). > > I guess we're working on different meanings for "provide", in this > sentence of the CCADB policy: > > > CAs must provide English versions of any Certificate Policy, > Certification > > Practice Statement and Audit documents which are not originally in > English > > The way I was looking at it was that a CPS is "provided" to the CCADB by > linking to it. If a translated CPS exists, but it isn't linked to from the > CCADB (or, as far as I can tell, anywhere sensible on the CA's site), can > it > really be said to have been "provided"? Especially when (as is the case > for > DFN-Verein) the cert itself doesn't include cPSuri, indicating where the > CPS > repository even is? No, we’re using the same meaning. There’s just many more fields and ways for a CA to provide a CP/CPS, and even these methods are undergoing some changes (e.g. to account for CAs that may have dozens of CP/CPSes associated with a root). Perhaps the CCADB needs to be augmented, to specifically include an "English > language version" of CP/CPS/Audit statements? That’s a perfectly reasonable suggestion, but also note that, as with above, there’s active development going on in terms of how CP/CPSes are represented and linked to CAs. > > > This is something that the proposed Browser Alignment ballots in the CA/B > > Forum, > > > https://github.com/cabforum/documents/compare/master...sleevi:2019-10-Browser_Alignment > > , > > would address. It incorporates the Mozilla Policy, Microsoft Policy, and > > CCADB policy within the BRs itself. > > > > In that branch, see the revised Section 8.6 > > As far as I can see, s8.6 only discussed audit reports, not CP/CPS. Which > is fine and necessary, but when I'm trying to figure out where to send > "y'all have a pile of certs that need revoking because your customers leave > their keys on pastebin" e-mails, a CPS that I can read is what I need. D’oh! You’re entirely right! That should have been added to Section 2.2, and is an oversight in my part. I’ll make sure to fix that. Thanks for bringing up this issue :) > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DFN-Verein: CPS/CP link in CCADB not in English
On Thu, Mar 19, 2020 at 12:33:29PM -0400, Ryan Sleevi wrote: > I'm not sure an incident report is necessary. The CCADB policy allows both > to be provided, and the mechanisms that CCADB uses (both for CAs and for > Root Stores) permit a host of expressiveness (and further changes are being > made). I guess we're working on different meanings for "provide", in this sentence of the CCADB policy: > CAs must provide English versions of any Certificate Policy, Certification > Practice Statement and Audit documents which are not originally in English The way I was looking at it was that a CPS is "provided" to the CCADB by linking to it. If a translated CPS exists, but it isn't linked to from the CCADB (or, as far as I can tell, anywhere sensible on the CA's site), can it really be said to have been "provided"? Especially when (as is the case for DFN-Verein) the cert itself doesn't include cPSuri, indicating where the CPS repository even is? Perhaps the CCADB needs to be augmented, to specifically include an "English language version" of CP/CPS/Audit statements? > This is something that the proposed Browser Alignment ballots in the CA/B > Forum, > https://github.com/cabforum/documents/compare/master...sleevi:2019-10-Browser_Alignment > , > would address. It incorporates the Mozilla Policy, Microsoft Policy, and > CCADB policy within the BRs itself. > > In that branch, see the revised Section 8.6 As far as I can see, s8.6 only discussed audit reports, not CP/CPS. Which is fine and necessary, but when I'm trying to figure out where to send "y'all have a pile of certs that need revoking because your customers leave their keys on pastebin" e-mails, a CPS that I can read is what I need. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DFN-Verein: CPS/CP link in CCADB not in English
Matt, I'm not sure an incident report is necessary. The CCADB policy allows both to be provided, and the mechanisms that CCADB uses (both for CAs and for Root Stores) permit a host of expressiveness (and further changes are being made). While there is certainly benefit in highlighting the English language versions, the CCADB policy does not preclude other languages. This is something that the proposed Browser Alignment ballots in the CA/B Forum, https://github.com/cabforum/documents/compare/master...sleevi:2019-10-Browser_Alignment , would address. It incorporates the Mozilla Policy, Microsoft Policy, and CCADB policy within the BRs itself. In that branch, see the revised Section 8.6 On Thu, Mar 19, 2020 at 7:58 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Mar 19, 2020 at 11:10:05AM +, arnold.ess...@t-systems.com > wrote: > > Thanks for pointing it out. We changed the links so that they now refer > > to the English version of the CP and CPS. > > Thanks for the quick update. Do you have an ETA for the preliminary > incident report? > > - Matt > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thu, Mar 19, 2020 at 9:58 AM Wojtek Porczyk wrote: > On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi via > dev-security-policy wrote: > > [...] but given that some negligent and > > irresponsible CAs kept agitating to reduce revocation requirements than > > protect users, the ballot was kept simple. > > > [...] I worry the same set of negligent and irresponsible > > CAs will try to advocate for more CA discretion when revocation, such as > > allowing the CA to avoid revoking when they’ve mislead the community as > to > > what they do (CP/CPS violations) or demonstrated gross incompetence (such > > as easily detected spelling issues in jurisdiction information). > > > > I would hope no CA would be so irresponsible as to try to bring that up > > during such a discussion. > > If I'm reading this correctly, you're labeling some CAs as negligent, > irresponsible and incompetent basing on the discussion and/or voting in > CA/B > Forum. > No, you're not reading correctly. The adjectives are based on quantifiable, systemic, repeat actions and incidents; they're pre-existing adjectives, independent of the discussion topics they take up. It just happens that those who bear the adjective happen to be the most likely to start those discussions, and were the ones most vocal in the past. Presumably, this is because they're the most likely to benefit, financially and reputationally, from shifting their liability and responsibility onto end users, or because they think in localized instances (such as "their" customer and "their" CA), without appreciating the systemic risk it can be introduced when it's "any" customer and "any" CA. The exception to this would be irresponsibility, which it would be irresponsible to try to attach "poison pill" riders that have been repeatedly discussed and rejected, when there exists real opportunity to keep things simple and improve them. Discussions of revocation requirements always seem to bring out folk who want to relitigate everything, rather than making the necessary progress in meaningful ways. That's the irresponsibility. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
> > - Microsec will check all the issued IVCP certificates looking for similar > issues - deadline 2020-03-20 > Microsec has finished the detailed investigation on the issued TLS IVCP certificates looking for similar issues. The findings are the following: Microsec issued altogether 9 test certificates on 2019-10-01 and 2019-10-02 with 30 days validity. The purpose of the test was to issue DV and IV certificates from each subordinate CA which is used to issue these types of certificates. The test covered both the RSA-based hierarchy and the ECC-based new CA hierarchy. The test certificates were issued directly from the CA software by using the operator interface. The CA software forces the use of dual control. The RSA-based system is configured to use Certificate Transparency to fully comply with the present requirements. 4 of the 9 test certificates were issued in the RSA-based system. The ECC-based system was configured to issue the test certificates without Certificate Transparency, because this root is not trusted yet and none of the log servers issues SCT for this root. 5 of the 9 test certificates were issued in the ECC-based system. The Subject DN fields were configured according to the DV profile requirements, this way the issuance of the DV certificates was successful. The 2 successfully issued RSA-based DV certificates can be found in the crt.sh as https://crt.sh/?q=1947651733 https://crt.sh/?q=1944631156 The issuance of the test IV certificates was done using the same Subject DN fields by mistake. None of the operators identified the missing fields in case of IV certificates. The following RSA-based IV certificates were issued with missing fields in the Subject name: https://crt.sh/?q=1947655126 https://crt.sh/?q=1947655112 They are already included in the incident report and there are no other IV certificates issued under the RSA root with this problem. A similar set of 3 DV and 2 IV test certificates were issued under the ECC root, but without SCT, as explained above. Because of this, they can’t be found in the crt.sh. The 3 DV test certificates were correct. The 2 IV test certificates have the same problem: missing givenName, surName, localityName fields in the Subject DN. These certificates are already expired, so revocation is not possible. Microsec has only issued test TLS certificates under the ECC root so far. The cause of the problem was the same as for the RSA-based test certificates, so the remediation and preventive measures are the same too. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi via dev-security-policy wrote: > [...] but given that some negligent and > irresponsible CAs kept agitating to reduce revocation requirements than > protect users, the ballot was kept simple. > [...] I worry the same set of negligent and irresponsible > CAs will try to advocate for more CA discretion when revocation, such as > allowing the CA to avoid revoking when they’ve mislead the community as to > what they do (CP/CPS violations) or demonstrated gross incompetence (such > as easily detected spelling issues in jurisdiction information). > > I would hope no CA would be so irresponsible as to try to bring that up > during such a discussion. If I'm reading this correctly, you're labeling some CAs as negligent, irresponsible and incompetent basing on the discussion and/or voting in CA/B Forum. But those are adjectives that are inverse of what is required of CAs to have roots included in root store [0]. Additionally, I've seen multiple statements, some of them under official hats, that Mozilla treats CA conduct holisticaly when assessing trust (I don't have reference handy). Do you think that Mozilla may in the future consider voting or discussing "wrong" (for any definition of "wrong") as having impact on general trust that Mozilla has placed in a particular CA? (Maybe I'm exaggerating, but just think of it: " Issues. Issue X: failure to vote YES on ballot "). [0] "Including any CA carries a level of risk that is measured, in part, by the past record of the CA (or lack thereof), their responsiveness (or lack thereof), and the level of competence and precision demonstrated by the CA during the inclusion process."; "Having a root certificate you control included in Mozilla's root store is a major ongoing responsibility" (both from https://wiki.mozilla.org/CA/Application_Process) -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. (under personal hat) |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> signature.asc Description: PGP signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Is issuing a certificate for a previously-reported compromised private key misissuance?
Has anyone worked with a site/service like this that could help convey compromised keys between CAs? https://pwnedkeys.com/submit.html -Original Message- From: dev-security-policy On Behalf Of Matt Palmer via dev-security-policy Sent: Thursday, March 19, 2020 7:05 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Is issuing a certificate for a previously-reported compromised private key misissuance? On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi wrote: > On Thu, Mar 19, 2020 at 1:02 AM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > 2. If there are not explicit prohibitions already in place, *should* there > >be? If so, should it be a BR thing, or a Policy thing? > > https://github.com/cabforum/documents/issues/171 is filed to > explicitly track this. That said, I worry the same set of negligent > and irresponsible CAs will try to advocate for more CA discretion when > revocation, such as allowing the CA to avoid revoking when they’ve > mislead the community as to what they do (CP/CPS violations) or > demonstrated gross incompetence (such as easily detected spelling issues in > jurisdiction information). > > I would hope no CA would be so irresponsible as to try to bring that > up during such a discussion. I shall fire up the popcorn maker in preparation. > > 3. Can a CA be deemed to have "obtained evidence" of key compromise prior > >to the issuance of a certificate, via a previously-submitted key > >compromise problem report for the same private key? If so, it would > >seem that, even if the issuance of the certificate is OK, it is a > >failure-to-revoke incident if the cert doesn't get revoked within 24 > >hours... > > Correct, that was indeed the previous conclusion around this. The CA > can issue, but then are obligated to revoke within 24 hours. Excellent, thanks for that confirmation. Incident report inbound. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DFN-Verein: CPS/CP link in CCADB not in English
On Thu, Mar 19, 2020 at 11:10:05AM +, arnold.ess...@t-systems.com wrote: > Thanks for pointing it out. We changed the links so that they now refer > to the English version of the CP and CPS. Thanks for the quick update. Do you have an ETA for the preliminary incident report? - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
AW: DFN-Verein: CPS/CP link in CCADB not in English
Thanks for pointing it out. We changed the links so that they now refer to the English version of the CP and CPS. -Ursprüngliche Nachricht- Von: dev-security-policy Im Auftrag von Matt Palmer via dev-security-policy Gesendet: Donnerstag, 19. März 2020 10:56 An: mozilla-dev-security-pol...@lists.mozilla.org Betreff: DFN-Verein: CPS/CP link in CCADB not in English As I understand the CCADB Policy (which is included by reference in the Mozilla Root Store Policy), CAs are required to provide an English translation of their CP/CPS documents, and link to them in the CCADB. At the time of writing, the "AllCertificateRecordsReport" CSV shows the link for the "DFN-Verein Certification Authority 2" CP as being https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP.pdf, which at present loads a non-English PDF. Similarly, the link for that same CA's CPS is https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CPS.pdf, which is also a non-English document. What is the procedure for poking DFN-Verein (or their parent CA, T-TeleSec) to get them to provide links to suitably translated documents? - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi wrote: > On Thu, Mar 19, 2020 at 1:02 AM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > 2. If there are not explicit prohibitions already in place, *should* there > >be? If so, should it be a BR thing, or a Policy thing? > > https://github.com/cabforum/documents/issues/171 is filed to explicitly > track this. That said, I worry the same set of negligent and irresponsible > CAs will try to advocate for more CA discretion when revocation, such as > allowing the CA to avoid revoking when they’ve mislead the community as to > what they do (CP/CPS violations) or demonstrated gross incompetence (such > as easily detected spelling issues in jurisdiction information). > > I would hope no CA would be so irresponsible as to try to bring that up > during such a discussion. I shall fire up the popcorn maker in preparation. > > 3. Can a CA be deemed to have "obtained evidence" of key compromise prior > >to the issuance of a certificate, via a previously-submitted key > >compromise problem report for the same private key? If so, it would > >seem that, even if the issuance of the certificate is OK, it is a > >failure-to-revoke incident if the cert doesn't get revoked within 24 > >hours... > > Correct, that was indeed the previous conclusion around this. The CA can > issue, but then are obligated to revoke within 24 hours. Excellent, thanks for that confirmation. Incident report inbound. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On Thu, Mar 19, 2020 at 1:02 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Since I started requesting revocation for certificates with > known-compromised private keys, I've noticed a rather disturbing pattern > emerging in a few cases: > > 1. I find a private key on the Internet. > > 2. I request revocation from the CA on the basis that the private key is >compromised, and provide suitable evidence thereof. > > 3. The certificate is revoked. > > 4. Some time later, I discover that a new certificate, using the same >private key, has been issued by the same CA. (Mad props to CT!) > > 5. "Da wah?!?" I say, and scurry off to the BRs and Mozilla Root Store >Policy, only to find that there doesn't appear to be anything explicitly >covering this rather disconcerting situation. > > So, I'm asking the combined wisdom of this esteemed community the following > questions: > > 1. *Are* there explicit prohibitions on issuing a certificate for a private >key which has been previously submitted *to that CA* as compromised >(assuming, of course, that the prior submission was valid), and I'm just >not good at finding said prohibitions? No. We bandied about changes during the revisions to 4.9.1.1, using the exact scenario you described, but given that some negligent and irresponsible CAs kept agitating to reduce revocation requirements than protect users, the ballot was kept simple. 2. If there are not explicit prohibitions already in place, *should* there >be? If so, should it be a BR thing, or a Policy thing? > https://github.com/cabforum/documents/issues/171 is filed to explicitly track this. That said, I worry the same set of negligent and irresponsible CAs will try to advocate for more CA discretion when revocation, such as allowing the CA to avoid revoking when they’ve mislead the community as to what they do (CP/CPS violations) or demonstrated gross incompetence (such as easily detected spelling issues in jurisdiction information). I would hope no CA would be so irresponsible as to try to bring that up during such a discussion. > 3. Can a CA be deemed to have "obtained evidence" of key compromise prior > to >the issuance of a certificate, via a previously-submitted key compromise >problem report for the same private key? If so, it would seem that, > even >if the issuance of the certificate is OK, it is a failure-to-revoke >incident if the cert doesn't get revoked within 24 hours... Correct, that was indeed the previous conclusion around this. The CA can issue, but then are obligated to revoke within 24 hours. There’s not a statute of limitation on “obtains evidence” here, precisely because it could allow a host of shenanigans, such as CAs arguing the require per-cert evidence rather than systemic demonstrations. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
DFN-Verein: CPS/CP link in CCADB not in English
As I understand the CCADB Policy (which is included by reference in the Mozilla Root Store Policy), CAs are required to provide an English translation of their CP/CPS documents, and link to them in the CCADB. At the time of writing, the "AllCertificateRecordsReport" CSV shows the link for the "DFN-Verein Certification Authority 2" CP as being https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP.pdf, which at present loads a non-English PDF. Similarly, the link for that same CA's CPS is https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CPS.pdf, which is also a non-English document. What is the procedure for poking DFN-Verein (or their parent CA, T-TeleSec) to get them to provide links to suitably translated documents? - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Is issuing a certificate for a previously-reported compromised private key misissuance?
On 2020-03-19 07:02, Matt Palmer wrote: 2. If there are not explicit prohibitions already in place, *should* there be? If so, should it be a BR thing, or a Policy thing? I think there should be. I expect them to publish a CRL that says the reason for revocation is a key compromise. I expect them to check for other keys with the same public key at that time, and also revoke them. Before signing a new key, I expect them to have checked it against there list of previously reported key compromises. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Is issuing a certificate for a previously-reported compromised private key misissuance?
Since I started requesting revocation for certificates with known-compromised private keys, I've noticed a rather disturbing pattern emerging in a few cases: 1. I find a private key on the Internet. 2. I request revocation from the CA on the basis that the private key is compromised, and provide suitable evidence thereof. 3. The certificate is revoked. 4. Some time later, I discover that a new certificate, using the same private key, has been issued by the same CA. (Mad props to CT!) 5. "Da wah?!?" I say, and scurry off to the BRs and Mozilla Root Store Policy, only to find that there doesn't appear to be anything explicitly covering this rather disconcerting situation. So, I'm asking the combined wisdom of this esteemed community the following questions: 1. *Are* there explicit prohibitions on issuing a certificate for a private key which has been previously submitted *to that CA* as compromised (assuming, of course, that the prior submission was valid), and I'm just not good at finding said prohibitions? 2. If there are not explicit prohibitions already in place, *should* there be? If so, should it be a BR thing, or a Policy thing? 3. Can a CA be deemed to have "obtained evidence" of key compromise prior to the issuance of a certificate, via a previously-submitted key compromise problem report for the same private key? If so, it would seem that, even if the issuance of the certificate is OK, it is a failure-to-revoke incident if the cert doesn't get revoked within 24 hours... I greatly appreciate answers and general commentary from the learned members of this community. Thanks, - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
