--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9085ddee-5bea-4dec-9c08-08d70e3cfae9n%40mozilla.org.
Hi Kathleen,
Comments inline.
> I propose that the following revocation reason codes are NOT applicable to TLS server (end-entity) certificates, meaning that they MUST NOT be used in CRLs for TLS server certificates.
• Unspecified (0)
SC31 (Browser Alignment ballot) already introduced this prohibition for “unspecified”, so I don’t believe anything needs to be changed from a Mozilla policy standpoint for this reason code.
> the CA MUST make the information regarding its intent to revoke available to the Subscriber before revoking the certificate…
I believe that BR 4.9.5 already makes it clear that the CA SHALL notify (“work with”) the Subscriber prior to revocation, so I’m not sure what is different about this proposal and the existing requirement. Can you clarify how this proposal is different from the current BR language?
> affiliationChanged (3)
The CRLReason affiliationChanged (3) MUST be used when the certificate subscriber has requested that their certificate be revoked for this reason, otherwise this CRLReason MUST NOT be used.
> superseded (4)
The CRLReason superseded (4) MUST be used when the certificate subscriber has requested that their certificate be revoked for this reason, otherwise this CRLReason MUST NOT be used.
I agree with Ryan H. that absent any guidance from Mozilla under which circumstances these reason codes should be used, it’s impossible for Relying Parties to meaningfully interpret these values. Additionally, CAs will similarly be unable to provide documentation to Subscribers on the meaning of these reason codes so Subscribers can make an informed decision in selecting the most appropriate reason code.
Thanks,
Corey
--
Hi Kathleen,
Does it make sense to make privilegeWithdrawn a catchall for all CA revocations due to compliance issues except those related to keyCompromise? There’s some revocations not covered by the other categories, for example where there was an audit issue and the CA is revoking the certs under that SubCA.
Jeremy
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186FE1D14C3786B2868923692689%40DM6PR14MB2186.namprd14.prod.outlook.com.
affiliationChanged (3)
The CRLReason affiliationChanged (3) MUST be used when the subscriber has requested that their certificate be revoked for this reason, or the CA has verifiable evidence that the subscriber no longer owns the domain names in the certificate and there is no evidence of a private key compromise. Otherwise this CRLReason MUST NOT be used. The affiliationChanged (3) CRLReason is intended to be used to indicate that the subscriber will no longer be using the certificate, or the subscriber has terminated their relationship with the organization indicated in the Distinguished Name attribute of the certificate and the organization's security policy requires that a new certificate be issued.
superseded (4)The CRLReason superseded (4) MUST be used when the certificate subscriber has requested that their certificate be revoked for this reason or the CA has replaced the certificate due to compliance issues other than those related to keyCompromise (1) and privilegeWithdrawn (9). Otherwise this CRLReason MUST NOT be used. The superseded (4) CRLReason is intended to be used to indicate when either the subscriber or the CA has needed to replace the certificate for reasons other than certificate expiration, keyCompromise (1), privilegeWithdrawn (9), and affiliationChanged (3).
The CA MUST make the information regarding its intent to revoke an end-entity SSL certificate available to the certificate subscriber before revoking the certificate. When the revocation is the result of a Certificate Problem Report as defined in the CA/Browser Forum Baseline Requirements, the CA must communicate with the subscriber as described in section 4.9.5 of the CA/Browser Forum Baseline Requirements.
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20211209054239.GG930%40hezmatt.org.
The CRLReason cessationOfOperation (5) MUST be used when the subscriber has requested that their certificate be revoked for this reason, or the CA has received verifiable evidence that the subscriber no longer owns the domain names in the certificate and there is no evidence of a private key compromise. Otherwise this CRLReason MUST NOT be used. The CRLReason cessationOfOperation (5) is intended to be used to indicate that the subscriber no longer owns the domain names in the certificate or will no longer be using the certificate. For example, this revocation reason should be used if the website with the certificate is shut down prior to the expiration of the certificate."
1) The first sentence of the second paragraph has been changed to make my intent more clear, and I added a comment that we will need to determine an effective-date because this means code changes (e.g. ACME)."When a certificate revocation is not initiated by the certificate subscriber, the CA MUST notify the certificate subscriber about its intent to revoke the end-entity SSL certificate at least 24 hours before revoking the certificate."I am open for feedback on wording and the time frame (e.g. 24 hours), and I will also appreciate thoughts about the effective-date for this new policy. I intend to require that CAs notify certificate subscribers before revoking their certificates, because when certificate revocation is enforced by the browser the CA can essentially cause DOS for websites.
As a subscriber, I would prefer not to be required to provide an email to get a certificate. As such, would it be acceptable to allow polling an endpoint to get the revocation status? I already monitor OCSP for my domains, so I am already notified of revocations without the need for an inbox.
I fully concur with Aaron. This requirement, as is, conflicts with Section 4.9.1.1 of the BRs.
AdrianoI can understand why the keyCompromise and cACompromise reason codes are of interest, but I'm struggling to see why Mozilla might be interested in differentiating between privilegeWithdrawn, cessationOfOperation, and superseded. Why are any of these 3 reason codes more useful than having no reason code at all? What use cases would be enabled if CAs were to use these 3 reason codes as you propose?
FWIW, at the moment my counter-proposal would be roughly along these lines (for leaf certificate revocations):- CAs MUST use keyCompromise for (and only for) proven or suspected key compromise.- CAs MUST revoke immediately in the case of proven key compromise.- CAs SHOULD NOT use other reason codes.- Beyond that, follow the BRs.
> "When a certificate revocation is not due to key compromise and is not initiated by the certificate subscriber, the CA MUST make the information regarding its intent to revoke an end-entity SSL certificate available to the certificate subscriber at least 24 hours before revoking the certificate."
What if the certificate revocation is due to the CA becoming aware that validation (particularly DCV) was not performed correctly? In such cases, it's possible (perhaps even likely) that the private key is controlled only by an attacker; and since that private key hasn't been obtained by parties that the subscriber (i.e., the attacker) has not authorized, the key is not compromised.
As with key compromise, waiting 24 hours in this scenario only helps the attacker.
In that case, couldn’t you just include that you revoked the certificate before notice as part of the incident report you are already required to file for failing to properly do validation? In this scenario, you’re already filing an incident report so combining the two misses on a report doesn’t seem burdensome. Plus, if you’re filing incident reports promptly, then the browsers can provide guidance on their expectations to revoke before the 24-hour notice or not. Then, the decision on when to revoke is partly a community-driven decision rather than something the CA is unilaterally deciding.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB47295DE63653156956A1018EAA459%40MW4PR17MB4729.namprd17.prod.outlook.com.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729B3D46782AD07856E77F2AA469%40MW4PR17MB4729.namprd17.prod.outlook.com.
I definitely agree with Rob that it’s worth exploring the reasons/goals for this change. I’m skeptical that the proposed notice requirement will do anything to help other browsers get to a hard-fail situation,
it may be worth stepping back, both to examine if that is a worthwhile goal in itself, and look at possible ways to achieve that.One serious shortcoming of the revocation methods, in general, is that they are CA mediated. Both new and long-standing participants on this list are undoubtedly familiar with just how many CA incidents we regularly see, and in violations of things that are surprising, if not outright unconscionable, in the CAs’ explanations for them. That’s not to say any disagreement or misunderstanding of requirements is an indelible black mark on CAs, or even that they’re all unreasonable, but there certainly have been some events, even in the past year, that are egregious in their misunderstanding that borderline on “willful noncompliance”.CA revocation simply exacerbates this asymmetry, in which the goals of the user agent are misinterpreted, or misimplemented, by CAs that (understandably and reasonably) have their own motivations and priorities. We see some CAs callously and knowingly violating the BRs, because they want to advantage their customers (site operators) at the risk of users, and revocation is a natural extension of that misalignment. That is, some CAs want to avoid revocation for mistakes they make, because it annoys their customers and (rightfully) harms their reputation, but want to promote revocation for areas where it advantages them (e.g. revoking certs for a customer if that customer gets any cert from another CA, or if the customer fails to pay additional balloon fees based on volume, or monthly “rentals”, etc).If the goal of revocation is to protect users, particularly in scenarios where the site operator is actively interested and supportive of that, such as key compromise, while discouraging abuse by others, such as CAs, doesn’t it make sense to have the user agent be the means of accomplishing that? Equally, when considering government compulsion for revocation, which may not respect the rule of law or the rights of site operators, doesn’t it make sense for the user agent to be able to both advocate for and defend the rights of server operators, such as ensuring such demands are legitimate and respect the rights of users and site operators? Similarly too, what about the risk of (other) root stores using contractual obligations to compel revocation by CAs in their program, which has a knock-on effect of effectively propagating that policy to all (other) root stores?Concretely, one way to accomplish this would be that, rather than defining the set of reasons that a CA may use, and trying to filter or special case that, what if the user agent provided a means (e.g. through some integration with, or system maintained similarly to, CCADB), which would allow for site operators to request revocation be propagated through to browsers, with the logic being that the browser first checks if the CA has done the revocation. Effectively, a two-phase commit system to allow both the CA, and the UA, to validate the legitimacy of the revocation request.There are undoubtably shortcomings here as well - for example, if a third-party demonstrated key compromise to the CA, the site operator may not be interested in having revocation propagated, so it’s by no means a fully fleshed out proposal, although one can easily imagine possible solutions, like the CA delivering that proof to this hypothetical system. But for the scenarios of CA-forced revocation, or things like “someone sent a government-like looking letter for which the CA has no time, skill, or interest in actually validating”, this would allow the user agent to act on their behalf.Conceptually, just as CT functions as a form of counter-signing, in which CAs aren’t trusted to issue certificates unless they have been witnessed by public logs, thus legitimizing the issuance, this functions as a form of counter-signing for revocation. Unlike past (somewhat misguided) proposals for “revocation transparency”, which largely seek to simply make a commitment to revocation without being able to distinguish, or validate, the decision making, this tries to add a counter-party (or counter-parties) to make sure the revocation itself is legitimate and aligned with the needs and goals for the UA.This is, however, further separate from the question of soft-fail vs hard-fail for revocation. I realize during the earlier discussion of revocation, as it applies to Mozilla, the technical role of revocation as it works for Web technologies was explicitly excluded, and I do want to respect that. However, I do believe that a meaningful discussion of soft-fail vs hard-fail, for any reason (including key compromise), would necessarily have to include that, since it may be another area of philosophical differences that are key to understanding the present situation.
Hi Kathleen,
I have a question regarding the following language:
“When a CRL entry is for an end-entity SSL certificate and the CRLReason code is one of the following as described below, then the reasonCode extension MUST be provided. When the CRLReason code is not one of the following, then the reasonCode extension MUST NOT be provided.”
Is the intention that historic revocations (i.e., revocation entries that first appeared on a CRL prior to the policy effective date) must be reviewed and updated, or is this requirement applicable only to those revocations performed after the new policy becomes effective? It would be good to have clarity here, as there was confusion when Microsoft announced their requirement for CA revocations to have a reason code in ARLs and it was unclear whether it was applicable to historic revocations or only to new revocations moving forward.
Thanks,
Corey
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Kathleen Wilson
Sent: Tuesday, January 4, 2022 6:13 PM
To: dev-secur...@mozilla.org
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates
All,
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c822471d-016f-45ef-9602-0e09a141244cn%40mozilla.org.
Is the intention that historic revocations (i.e., revocation entries that first appeared on a CRL prior to the policy effective date) must be reviewed and updated, or is this requirement applicable only to those revocations performed after the new policy becomes effective?
4) Added text to a bullet point in the keyCompromise section in order to ensure that the certificate subscriber can only declare keyCompromise for certificates for which they control the private key.- the certificate subscriber provides proof of control over the private key and requests that the CA revoke the certificate for this reason code;
Kathleen –
I’m sorry if I missed an earlier explanation about why this is important, but could you explain why the emphasis on different reason codes for revocation and the requirement to not include a reason code if the revocation doesn’t fall into one of the stated reasons.
Are you trying to get CAs to eventually use CRLs segmented by the different reason codes? Do you expect RP applications to treat certificate validation differently based on the reason code? Do you expect RP applications to potentially make the reason code available to end user so they can choose to continue trusting a revoked certificate if they don’t care about the reason? Is it just for trust store programs to gather statistics about why certificates get revoked?
I would expect the RP application to treat all revoked certificates the same regardless of the reason for the revocation, so I don’t fully understand why this new policy is being developed.
Thanks,
wendy
Kathleen –
I’m sorry if I missed an earlier explanation about why this is important, but could you explain why the emphasis on different reason codes for revocation and the requirement to not include a reason code if the revocation doesn’t fall into one of the stated reasons.
Are you trying to get CAs to eventually use CRLs segmented by the different reason codes?
Do you expect RP applications to treat certificate validation differently based on the reason code?
Do you expect RP applications to potentially make the reason code available to end user so they can choose to continue trusting a revoked certificate if they don’t care about the reason?
Is it just for trust store programs to gather statistics about why certificates get revoked?
I would expect the RP application to treat all revoked certificates the same regardless of the reason for the revocation, so I don’t fully understand why this new policy is being developed.
not sure it's safe to let one revoke with reason key compromise
without control of key: IIRC wasn't it ruled that CA doesn't need
to verify subscriber controls private key it requests for TLS
cert?
(https://groups.google.com/g/mozilla.dev.security.policy/c/x_DeTDKBwWI/m/ogSKLpx8CgAJ)
--
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/RVFnJJRuUag/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ed11d7d4-7368-468d-93b3-f0733cea8711n%40mozilla.org.
If the goal is to ensure that key compromise is only used if:A) The Subscriber wants it (i.e. not by the CA as part of a contract dispute or part of some other policy or business practice detrimental to end users)B) The key was compromised (even if the Subscriber doesn't want it revoked)then it seems like changing bullet #5 to simply being that the Subscriber requests the revocation with keyCompromise should be sufficient?
keyCompromise (1)
The CRLReason keyCompromise (1) MUST be used when one or more of the following occurs:
the CA obtains verifiable evidence that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise;
the CA is made aware of a demonstrated or proven method that exposes the certificate subscriber’s private key to compromise;
there is clear evidence that the specific method used to generate the private key was flawed;
the CA is made aware of a demonstrated or proven method that can easily compute the certificate subscriber’s private key based on the public key in the certificate (such as a Debian weak key, see https://wiki.debian.org/TLSkeys); or
the certificate subscriber, who has provided proof of possession of the private key**, requests that the CA revoke the certificate for this reason.
** If the certificate subscriber has not previously provided and can no longer provide proof of possession of the private key, they may still request revocation due to keyCompromise, and that revocation SHOULD be limited in scope to only the certificate issued to that certificate subscriber, even if the key in the CSR is used by other certificates.
The CRLReason keyCompromise (1) MAY be used when the CA obtains verifiable evidence that the certificate was issued to a subscriber who does not own or control all of the domain names listed in the certificate. For example;
the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; or
the CA obtains reasonable 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.
Otherwise this CRLReason MUST NOT be used.
2) Per the feedback from Wendy (here) I replaced "affiliationChanged (3)" with "cessationOfOperation (5)" in the proposed text, because despite the previously referenced document about revocation reasons, I agree with Wendy that cessationOfOperation makes more sense in regards to a TLS certificate no longer being needed because the website it was used in has been taken down or the certificate subscriber no longer owns the domain name(s) in the certificate. Whereas affiliationChanged seems to be about how a person is associated with an organization.
So, if a company is changing name and there are OV/EV Certificates with the official legal name included, these certificates need to be changed and include the new legal name. In that case, affiliationChanged makes sense to me.
If the current proposal is adopted, because of "If the certificate is revoked for a reason not listed below, then the reasonCode extension MUST NOT be provided in the CRL.", many CAs using the affiliationChanged reason in their practices will be out of compliance.
Dimitris.
affiliationChanged (3)
The CRLReason affiliationChanged (3) MUST be used when the certificate subscriber has requested that their certificate be revoked for this reason, or the CA has replaced the certificate due to changes in the certificate’s public-key and the CA has not replaced the certificate for the other reasons: keyCompromise (1), superseded (4), cessationOfOperation (5), and privilegeWithdrawn (9). Otherwise this CRLReason MUST NOT be used. The CRLReason affiliationChanged (3) is intended to be used to indicate that the subject's name or other information in the public-key certificate has been modified but there is no cause to suspect that the private key has been compromised.
==
Thanks,
Kathleen
The CRLReason keyCompromise (1) MUST be used when one or more of the following occurs:
the CA obtains verifiable evidence that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise;
the CA is made aware of a demonstrated or proven method that exposes the certificate subscriber’s private key to compromise;
there is clear evidence that the specific method used to generate the private key was flawed;
the CA is made aware of a demonstrated or proven method that can easily compute the certificate subscriber’s private key based on the public key in the certificate (such as a Debian weak key, see https://wiki.debian.org/TLSkeys); or
the certificate subscriber, who has provided proof of possession of the private key**, requests that the CA revoke the certificate for this reason.
the certificate subscriber, who has provided proof of possession of the private key**, requests that the CA revoke the certificate for this reason.
Maybe I'm misreading this, but adding the requirement to prove possession of the private key seems to me to make the last line entirely redundant: providing proof of possession of a certificate's private key, combined with a request for revocation for key compromise, would seem to me to qualify as "verifiable evidence that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise."
Hi Ryan and Kathleen
I read Ryan’s email (below) and also the Mozilla draft policy located here
and I think there is an inconsistency being introduced in this latest Mozilla policy draft statement:
** If the certificate subscriber has not previously provided and can no longer provide proof of possession of the private key, they may still request revocation due to keyCompromise, and that revocation SHOULD be limited in scope to only the certificate issued to that certificate subscriber, even if the key in the CSR is used by other certificates.
The Mozilla policy permits revocation for key compromise even if the applicant has not and cannot demonstrate proof of possession, but Ryan’s comments requires proof of possession (when requesting or when revoking).
Do we need to tighten up the Mozilla policy to align with the requirement to demonstrate proof of possession?
Doug
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ryan Sleevi
Sent: Friday, January 21, 2022 3:02 PM
To: Ryan Sleevi <ry...@sleevi.com>
Cc: Kathleen Wilson <kwi...@mozilla.com>; dev-secur...@mozilla.org; watso...@gmail.com <watso...@gmail.com>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG4Rd3LPSVc5RQ%2BZJUtOfhJCDW%2B7tjTxy0YcHpOgeDb4w%40mail.gmail.com.
Hi Ryan,
Is that true for revocation reason code of Key Compromise also? The snip from the Mozilla policy below is within the context of revocation for key compromise unless I’m misreading the “**” link.
Hi Kathleen,
I still have a hard time with 2 types of key compromise processing. It seems like if the key is compromised it should always be processed the same way. Would you consider moving this bullet to a different reason code?
- Otherwise, the CA SHOULD limit revocation to only the instance of that key that the certificate subscriber had submitted the Certificate Signing Request (CSR) for
Basically this last bullet
could read:
Doug
From: Kathleen Wilson <kwi...@mozilla.com>
Sent: Tuesday, February 1, 2022 1:04 PM
To: dev-secur...@mozilla.org
Cc: Ryan Sleevi <ry...@sleevi.com>; Doug Beattie <doug.b...@globalsign.com>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates
I have re-written the bright green text in the draft policy to separate out the scope of revocation from the requirement to use the keyCompromise reason.
Hi Kathleen,
I still have a hard time with 2 types of key compromise processing. It seems like if the key is compromised it should always be processed the same way. Would you consider moving this bullet to a different reason code?
- Otherwise, the CA SHOULD limit revocation to only the instance of that key that the certificate subscriber had submitted the Certificate Signing Request (CSR) for
Basically this last bullet
- the certificate subscriber requests that the CA revoke the certificate for this reason.
could read:
- the certificate subscriber requests that the CA revoke the certificate for this reason with proof of possession demonstrated at cert issuance time or at the time of the revocation request..
Hi Ryan and Kathleen
What’s being proposed are 2 different sets of CA actions upon receipt of a relocation request for key compromise:
In both cases, section 6.1.1.3 of the BRs applies, and specifically item 4:
The CA SHALL reject a certificate request if one or more of the following conditions are met:
4. The CA has previously been made aware that the Applicant’s Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1;
Will the CA block further issuance when the request for revocation does not include PoP which could DoS them for renewal using the same key pair? To me, if the subscriber can’t provide PoP of the private key the unspecified reason code would be more accurate. What’s the value to the subscriber, CA and ecosystem to treat that case as key compromise vs. unspecified?
I’m probably just not understanding the background and value for the second rule around processing requests for revocation with key compromise without PoP.
Doug
From: Kathleen Wilson <kwi...@mozilla.com>
Sent: Tuesday, February 1, 2022 6:05 PM
To: dev-secur...@mozilla.org
Cc: Ryan Sleevi <ry...@sleevi.com>; Doug Beattie <doug.b...@globalsign.com>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates
OK, how about the following text?
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/24a3a885-dfd3-45f1-a5aa-9928c89fe6c1n%40mozilla.org.
Hi Jesper,
Here’s my opinion on your 3 questions below, marked with “Doug:”
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Jesper Kristensen
Sent: Wednesday, February 2, 2022 11:41 AM
To: dev-secur...@mozilla.org
Cc: Kathleen Wilson <kwi...@mozilla.com>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates
You don't often get email from jespe...@gmail.com. Learn why this is important |
It seems that some of the criteria in the draft policy are subjective to some degree. At the same time the policy leaves zero margin for error (If X then you MUST use this code, otherwise you MUST NOT). The combination of these two seems to ensure that mistakes will happen, and we will see a continuous stream of incident reports where a CA and a community member disagrees about a subjective aspect of these criteria. Could the policy be updated to give the CA freedom to choose in gray areas?
Doug: I don’t have an opinion on that one because I don’t tally understand which subjective statement you’re referring to.
There have already been several posts in this thread discussing if a CSR can be considered proof of possession of a private key. I don't think a CSR is secret and therefore cannot automatically be considered proof of possession, and I think the policy should state that explicitly.
Doug: If the CSR contains all SAN values in the issued certificate (and the certificate has the same public key as that CSR), then that binds the key to the domains and I believe this is sufficient POP. If this is not the case when the CSR is provided prior to issuance, a CA could ask the subscriber for a new CSR with all of the SANs (and same public key) as PoP during a request for revocation. I’d be interested to know if others agree with this.
The policy says revocations before the effective date does not need to be changed. What about revocations after the effective date? What if a certificate was revoked as superseded and later the CA receives evidence of key compromise? Must the reason code then be changed?
Doug: It’s my understanding that once a certificate is revoked and put on a CRL, you can never change the reason code..
Den tir. 1. feb. 2022 kl. 19.04 skrev Kathleen Wilson <kwi...@mozilla.com>:
I have re-written the bright green text in the draft policy to separate out the scope of revocation from the requirement to use the keyCompromise reason.
So the proposed text is as follows:
==
The CRLReason keyCompromise (1) MUST be used when one or more of the following occurs:
- the CA obtains verifiable evidence that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise;
- the CA is made aware of a demonstrated or proven method that exposes the certificate subscriber’s private key to compromise;
- there is clear evidence that the specific method used to generate the private key was flawed;
- the CA is made aware of a demonstrated or proven method that can easily compute the certificate subscriber’s private key based on the public key in - the certificate (such as a Debian weak key, see https://wiki.debian.org/TLSkeys); or
- the certificate subscriber requests that the CA revoke the certificate for this reason.
The scope of revocation depends on whether the certificate subscriber has proven possession of the private key of the certificate.
- If the certificate subscriber has previously demonstrated or can currently demonstrate possession of the private key of the certificate, then the CA MUST revoke all instances of that key across all subscribers.
- Otherwise, the CA SHOULD limit revocation to only the instance of that key that the certificate subscriber had submitted the Certificate Signing Request (CSR) for.==
I will continue to appreciate your feedback on this, and especially your input on how to make this more accurate.
Thanks,
Kathleen
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/24a3a885-dfd3-45f1-a5aa-9928c89fe6c1n%40mozilla.org.
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACAF_WgAmV1uopbEKAEmW0n6kwyTSKaT-HegsYjbJsbJET_gXg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB61291B7C47429DB6E6726857F0279%40PUZPR03MB6129.apcprd03.prod.outlook.com.
I appreciate the effort to balance the concerns of1) How do we let a subscriber revoke for keyCompromise even if their key has been stolen and deleted?; and2) How do we prevent a third party who has never held the key from revoking for keyCompromise?I think that the currently-proposed text does a reasonably good job of striking that balance, but I fear that it is too complex. In particular, I think that the different "cascading revocation" scenarios, particularly combined with the no-future-issuance requirement raised by Doug, are complex enough that they would be likely to be implemented incorrectly.I would propose the following slightly different attempt to strike the balance:```keyCompromise (1)
The CRLReason keyCompromise (1) MUST be used when one or more of the following occurs:
- the CA obtains verifiable evidence that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise;
- the CA is made aware of a demonstrated or proven method that exposes the certificate subscriber’s private key to compromise;
- there is clear evidence that the specific method used to generate the private key was flawed;
- the CA is made aware of a demonstrated or proven method that can easily compute the certificate subscriber’s private key based on the public key in the certificate (such as a Debian weak key, see https://wiki.debian.org/TLSkeys); or
- the certificate subscriber has proved possession of their private key and requests that the CA revoke the certificate for this reason.<the bit about "MAY be used" goes here>Otherwise this CRLReason MUST NOT be used.
```This proof of possession could happen at issuance time, at revocation time, or at any other time prior to revocation. Subscribers who want to be able to revoke for reason keyCompromise even if their key is stolen and deleted can prove possession at issuance time. CAs that want all of their subscribers to be able to do so can require proof of possession for issuance.I believe this is essentially the same thing that Doug Beattie is proposing. I recognize that it is different from what Ryan Sleevi is proposing. Yes, this prevents someone who has never proved possession of their own key from requesting a keyCompromise revocation if they have lost their key. But it also provides an avenue for that proof of possession to have happened ahead of time, and prevents someone who has never held the key from DOSing legitimate subscribers.
Will the CA block further issuance when the request for revocation does not include PoP which could DoS them for renewal using the same key pair? To me, if the subscriber can’t provide PoP of the private key the unspecified reason code would be more accurate. What’s the value to the subscriber, CA and ecosystem to treat that case as key compromise vs. unspecified?
I’m probably just not understanding the background and value for the second rule around processing requests for revocation with key compromise without PoP.
I'm not really sure about weaking the meaning of keycompromise. Currently if I saw a cert revoked it by keycompomised then one can throw its public key into 'leaked keys' bin and propargate key-purging between CA by pointing other CAs revoke this certifiate with same key as compromised- like multiple smime certificates from different CAs as there is no CT and first one who revoked key may not know that second cert with same key exsit.
although right thing to do such case would be notify the original holder in first revocation and let subscriber call the key with other CA they signed or have some kind of central leaked-publickey-here repository.
sent again, to the list this time
--
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/RVFnJJRuUag/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEaptK1R7PMBFNYvp6_hHcMD4FRL7C3b4OP1yK2YaJFzQ%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/fc5dcfda-d14f-a868-364a-d96341df7563%40gmail.com.
Ryan,
The intent of my recommendation was not to increase the burden or limit the ability of subscribers to revoke keys, it’s setting the proper/consistent revocation reason codes. In Kathleen’s proposal, if you want to revoke for key compromise but can’t demonstrate pop, then you can do that, but it results in just that one cert being revoked (same as unspecified). If the CA and CRL show revoked for key compromise (when POP is confirmed), then there are other actions to be performed (revoke other certs with the key across all subscribers, block further issuance across all subscribers). If we’re not doing that all the time then how is the relying party to know if this was really a key compromise or not? If we set the reason to unspecified (no reason code in CRLs) when POP is not verified everyone will have the same understanding of what key compromise means – it was confirmed to be compromised and there should not be any active certificates issued from that CA with that key (something 3rd parties will surely want to watch for)
You mentioned this below:
However, an additional consideration is that keyCompromise revocations are likely more valuable than other forms of revocations, both in terms of efficient and timely delivery and in user risk. A policy that restricts when and how Subscribers can request this revocation is thus one that limits the value of that, by making it harder, which harms end users more. The more barriers placed for Subscribers, the harder it is to get this information in a timely fashion.
Maybe this is where I’m missing an important point. Why is the key compromise reason more valuable and why will it happen more efficiently and timely than other reasons in the case where the CA cannot validate POP? Both can happen “immediately” and the end result is that (just) the requested certificate is revoked, so does the reason code matter?
If we don’t tighten up the processing of key compromise revocations, then we have 2 different paths to go down when a subscriber requests revocation for key compromise, and we provide a false sense of “security” to those that are looking at the CRL (this key is marked as key compromised, but it’s OK for it to be in other past and future certificates). If it’s compromised, it should be confirmed to be compromised and if we can’t confirm that, then it should be revoked with another reason.
Doug
From: Ryan Sleevi <ry...@sleevi.com>
Sent: Wednesday, February 2, 2022 5:35 PM
To: Doug Beattie <doug.b...@globalsign.com>
Cc: Kathleen Wilson <kwi...@mozilla.com>; dev-secur...@mozilla.org; Ryan Sleevi <ry...@sleevi.com>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates
> Maybe this is where I’m missing an important point. Why is the key compromise reason more valuable and why will it happen more efficiently and timely than other reasons in the case where the CA cannot validate POP? Both can happen “immediately” and the end result is that (just) the requested certificate is revoked, so does the reason code matter?
I’m also very interested in learning the rationale for why keyCompromise revocations are seemingly treated as higher priority, especially if Subscribers can self-attest to such compromise without any verification by the CA. Any RP software that selectively ignores certain revocations based on Subscriber-attested reasonCode has a security flaw in that an attacker who can fraudulently issue a certificate can similarly request revocation for that certificate specifying a reasonCode that RP software doesn’t prioritize. The net result in that scenario is that the certificate lifecycle is completed, but the risk to users of such RP software is still very much present as the certificate may be treated as valid.
Thanks,
Corey
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB612905E9689C6038478D1CEFF0289%40PUZPR03MB6129.apcprd03.prod.outlook.com.
> Maybe this is where I’m missing an important point. Why is the key compromise reason more valuable and why will it happen more efficiently and timely than other reasons in the case where the CA cannot validate POP? Both can happen “immediately” and the end result is that (just) the requested certificate is revoked, so does the reason code matter?
I’m also very interested in learning the rationale for why keyCompromise revocations are seemingly treated as higher priority, especially if Subscribers can self-attest to such compromise without any verification by the CA. Any RP software that selectively ignores certain revocations based on Subscriber-attested reasonCode has a security flaw in that an attacker who can fraudulently issue a certificate can similarly request revocation for that certificate specifying a reasonCode that RP software doesn’t prioritize. The net result in that scenario is that the certificate lifecycle is completed, but the risk to users of such RP software is still very much present as the certificate may be treated as valid.
Ryan,
The intent of my recommendation was not to increase the burden or limit the ability of subscribers to revoke keys, it’s setting the proper/consistent revocation reason codes. In Kathleen’s proposal, if you want to revoke for key compromise but can’t demonstrate pop, then you can do that, but it results in just that one cert being revoked (same as unspecified). If the CA and CRL show revoked for key compromise (when POP is confirmed), then there are other actions to be performed (revoke other certs with the key across all subscribers, block further issuance across all subscribers).
If we’re not doing that all the time then how is the relying party to know if this was really a key compromise or not? If we set the reason to unspecified (no reason code in CRLs) when POP is not verified everyone will have the same understanding of what key compromise means – it was confirmed to be compromised and there should not be any active certificates issued from that CA with that key (something 3rd parties will surely want to watch for)
You mentioned this below:
However, an additional consideration is that keyCompromise revocations are likely more valuable than other forms of revocations, both in terms of efficient and timely delivery and in user risk. A policy that restricts when and how Subscribers can request this revocation is thus one that limits the value of that, by making it harder, which harms end users more. The more barriers placed for Subscribers, the harder it is to get this information in a timely fashion.
Maybe this is where I’m missing an important point. Why is the key compromise reason more valuable and why will it happen more efficiently and timely than other reasons in the case where the CA cannot validate POP? Both can happen “immediately” and the end result is that (just) the requested certificate is revoked, so does the reason code matter?
If we don’t tighten up the processing of key compromise revocations, then we have 2 different paths to go down when a subscriber requests revocation for key compromise, and we provide a false sense of “security” to those that are looking at the CRL (this key is marked as key compromised, but it’s OK for it to be in other past and future certificates). If it’s compromised, it should be confirmed to be compromised and if we can’t confirm that, then it should be revoked with another reason.
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHGxZM9cULfqw0HYOvK57JR7YnJPQ0-ruLPqb%3DF2Y%2B_DLw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfVAO-H1LdpJ50ZgrxEPnXGXUiBt5QKY-N1XiPBCcbuJw%40mail.gmail.com.
These concrete suggestions of alternative text are very helpful.I have updated the bright green text in the draft policy document per your recommendations:===The scope of revocation depends on whether the certificate subscriber has proven possession of the private key of the certificate.
- If anyone requesting revocation has previously demonstrated or can currently demonstrate possession of the private key of the certificate, then the CA MUST revoke all instances of that key across all subscribers.
- If the certificate subscriber requests that the CA revoke the certificate for keyCompromise, and has not previously demonstrated and cannot currently demonstrate possession of the associated private key of that certificate, the CA SHOULD revoke all certificates associated with that subscriber that contain that public key. The CA SHOULD NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers or blocking issuance of future certificates with that key.===
One minor question, but generally I agree with this approach also!
Should this be changed to MUST NOT?
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ryan Sleevi
Sent: Thursday, February 3, 2022 3:08 PM
To: Kathleen Wilson <kwi...@mozilla.com>
Cc: dev-secur...@mozilla.org; Ben Wilson <bwi...@mozilla.com>; Ryan Sleevi <ry...@sleevi.com>; Doug Beattie <doug.b...@globalsign.com>; aa...@letsencrypt.org <aa...@letsencrypt.org>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHFL98PAXj2dR6ETDeMpfKOjTX%2B_KZ-O8uHfhrRq7gD6-Q%40mail.gmail.com.
Hi Jesper,
Here’s my opinion on your 3 questions below, marked with “Doug:”
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
On Behalf Of Jesper Kristensen
Sent: Wednesday, February 2, 2022 11:41 AM
To: dev-secur...@mozilla.org
Cc: Kathleen Wilson <kwi...@mozilla.com>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates
It seems that some of the criteria in the draft policy are subjective to some degree. At the same time the policy leaves zero margin for error (If X then you MUST use this code, otherwise you MUST NOT). The combination of these two seems to ensure that mistakes will happen, and we will see a continuous stream of incident reports where a CA and a community member disagrees about a subjective aspect of these criteria. Could the policy be updated to give the CA freedom to choose in gray areas?
Doug: I don’t have an opinion on that one because I don’t tally understand which subjective statement you’re referring to.
There have already been several posts in this thread discussing if a CSR can be considered proof of possession of a private key. I don't think a CSR is secret and therefore cannot automatically be considered proof of possession, and I think the policy should state that explicitly.
Doug: If the CSR contains all SAN values in the issued certificate (and the certificate has the same public key as that CSR), then that binds the key to the domains and I believe this is sufficient POP. If this is not the case when the CSR is provided prior to issuance, a CA could ask the subscriber for a new CSR with all of the SANs (and same public key) as PoP during a request for revocation. I’d be interested to know if others agree with this.
The policy says revocations before the effective date does not need to be changed. What about revocations after the effective date? What if a certificate was revoked as superseded and later the CA receives evidence of key compromise? Must the reason code then be changed?
Doug: It’s my understanding that once a certificate is revoked and put on a CRL, you can never change the reason code..
Den tir. 1. feb. 2022 kl. 19.04 skrev Kathleen Wilson <kwi...@mozilla.com>:
I have re-written the bright green text in the draft policy to separate out the scope of revocation from the requirement to use the keyCompromise reason.
So the proposed text is as follows:
==
The CRLReason keyCompromise (1) MUST be used when one or more of the following occurs:
- the CA obtains verifiable evidence that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise;
- the CA is made aware of a demonstrated or proven method that exposes the certificate subscriber’s private key to compromise;
- there is clear evidence that the specific method used to generate the private key was flawed;
- the CA is made aware of a demonstrated or proven method that can easily compute the certificate subscriber’s private key based on the public key in - the certificate (such as a Debian weak key, see https://wiki.debian.org/TLSkeys); or
- the certificate subscriber requests that the CA revoke the certificate for this reason.
The scope of revocation depends on whether the certificate subscriber has proven possession of the private key of the certificate.
- If the certificate subscriber has previously demonstrated or can currently demonstrate possession of the private key of the certificate, then the CA MUST revoke all instances of that key across all subscribers.
- Otherwise, the CA SHOULD limit revocation to only the instance of that key that the certificate subscriber had submitted the Certificate Signing Request (CSR) for.
==
I will continue to appreciate your feedback on this, and especially your input on how to make this more accurate.
Thanks,
Kathleen
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/24a3a885-dfd3-45f1-a5aa-9928c89fe6c1n%40mozilla.org.
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACAF_WgAmV1uopbEKAEmW0n6kwyTSKaT-HegsYjbJsbJET_gXg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729D4D09BE56D01C28C249FAA289%40MW4PR17MB4729.namprd17.prod.outlook.com.
Hi Ryan,
> I think that part of this may be resting on a certain statement "that the certificate lifecycle is completed", and I'm hoping you can expand more. The certificate lifecycle for a certificate does not necessarily end at revocation, at least in X.509, and to Doug's earlier question, you can indeed change reasons (or revocation dates) post-revocation. In the S/MIME case, for example, you can revoke a certificate with revocation date of Y, and then, upon later information, change Y to X (an earlier period), indicating that it had actually been compromised longer.
Fully agreed that X.509/PKIX provides the tools to update revocation information after the initial revocation is published via CRL or OCSP. However, from a TLS BR and Mozilla Policy standpoint, there is no requirement for CAs to update reasonCodes, invalidityDates, etc. after initial publication of the revocation. While some CAs may do this, it is not reasonable to assume that all CAs currently do so today. So, in terms of the current written requirements today, the ecosystem baseline is that revocation completes the certificate lifecycle.
Relevant to this discussion are some recent changes to the Code Signing Baseline Requirements [1], which do clarify expectations for CAs regarding setting revocationDates and invalidityDates, as well as clarifying that updating the revocationDate for a CRL entry and OCSP response is encouraged, taking in consideration any new information that the CA may become aware of post initial revocation of the Code Signing certificate. If Root Programs are expecting that CAs update revocation information after the initial publication, then that expectation should be made more explicit with a treatment similar to the Code Signing BRs.
> If I understand your attack, although I'm hoping you can more precisely explain it, it sounds like the assumption is that if the attacker self-immolates their cert, then it's impossible to change to keyCompromise later (e.g. as a result of the victim demonstration). Is that the implicit assumption?
I think you understood the attack: the attacker gets a certificate issued, then summarily revokes it with reasonCode that is ignored by a user agent. Since revocation is complete, the CA is relieved of any obligation to update this information after the initial publication. And users of that user agent are still exposed to the risk.
Thanks,
Corey
[1] https://lists.cabforum.org/pipermail/cscwg-public/2021-October/000616.html
From: Ryan Sleevi <ry...@sleevi.com>
Sent: Thursday, February 3, 2022 9:43 AM
To: Corey Bonnell <Corey....@digicert.com>
Cc: Doug Beattie <doug.b...@globalsign.com>; dev-secur...@mozilla.org; Kathleen Wilson <kwi...@mozilla.com>
Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates
On Thu, Feb 3, 2022 at 8:50 AM 'Corey Bonnell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:
Hi Ryan,
I agree with Rob that a CSR contains all the SANs of a certificate request is not necessarily sufficient PoP. A bit of PKI fan fiction to illustrate:
Assume that a Subscriber, a company named Foobarbaz, Ltd., has a TLS certificate for foobarbaz.com. A marketing director for Foobarbaz catches wind of a hot deal on gTLD domain registrations and instructs IT to purchase registrations for 100 or so domains and setup mirrors of their corporate website on each of those domains. In preparation, IT creates 100 CSRs with the same key pair as the original corporate website’s certificate (because a single 100 SAN cert is “too big”); each CSR has a single SAN dNSName corresponding to the new domain name to be purchased. Right before IT goes to purchase the domains, the marketing director also learns that the hot deal isn’t so great as the renewal fee for those domains “will bankrupt the @!$%^ company!” (their words, not mine). So, IT never follows through on purchasing the domains.
Fast forward a few months later, the IT person gets a bit overzealous with “git add” and uploads the 100 CSRs to GitHub. A disgruntled customer of Foobarbaz, still steaming at the company for their bad customer service after Foobarbaz shipped them a broken widget toy for their kid’s birthday, comes across these publicly available CSRs and downloads them. The hot deal on gTLD domains is still ongoing, so they pay the $0.88 and register one of the domains Foobarbaz was going to register but never carried through. They create an account at the same CA that issued the original foobarbaz.com and submit the CSR for their newly registered domain and complete DCV. The certificate gets issued, and they immediately request revocation. Since the CA believes that submission of a CSR with all the SANs constitutes PoP, they also revoke the certificate for foobarbaz.com since the two certificates share a public key. Foobarbaz.com is now unreachable, and our villain goes to bed with a grin on their face.
There are mitigations that the CA can put in place to lower the chances of that from happening (such as binding a submitted public key to a specific Subscriber account), but even that may be flawed since it’s essentially TOFU (the first Applicant to submit the CSR “wins”). Given these concerns, I don’t think it necessarily follows that a CSR that contains all SANs of a given certificate request constitutes PoP in all cases.
Thanks,
Corey
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHH4C7ahu4yqK59rmtRP8cPLFZCwfVsSwtmtsk%2BUtHHVLA%40mail.gmail.com.
Fully agreed that X.509/PKIX provides the tools to update revocation information after the initial revocation is published via CRL or OCSP. However, from a TLS BR and Mozilla Policy standpoint, there is no requirement for CAs to update reasonCodes, invalidityDates, etc. after initial publication of the revocation. While some CAs may do this, it is not reasonable to assume that all CAs currently do so today. So, in terms of the current written requirements today, the ecosystem baseline is that revocation completes the certificate lifecycle.
> If I understand your attack, although I'm hoping you can more precisely explain it, it sounds like the assumption is that if the attacker self-immolates their cert, then it's impossible to change to keyCompromise later (e.g. as a result of the victim demonstration). Is that the implicit assumption?
I think you understood the attack: the attacker gets a certificate issued, then summarily revokes it with reasonCode that is ignored by a user agent. Since revocation is complete, the CA is relieved of any obligation to update this information after the initial publication. And users of that user agent are still exposed to the risk.
Hi Ryan,
I agree with Rob that a CSR contains all the SANs of a certificate request is not necessarily sufficient PoP. A bit of PKI fan fiction to illustrate:
There are mitigations that the CA can put in place to lower the chances of that from happening (such as binding a submitted public key to a specific Subscriber account), but even that may be flawed since it’s essentially TOFU (the first Applicant to submit the CSR “wins”). Given these concerns, I don’t think it necessarily follows that a CSR that contains all SANs of a given certificate request constitutes PoP in all cases.
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEOSJD9aLfh78iDAN0027guJ2jfEPN%3D00q7x4JrHzQpbw%40mail.gmail.com.
Attack 2 (where the CA treats only the Subscriber's proof-of-possession of the CSR as equivalent to proof-of-possession of the private key):Eve correctly guesses that Alice obtained her cert via a particular certificate reseller.
Eve requests a certificate by providing Alice's CSR to the same certificate reseller, who forwards it to the CA.The CA notices that it already has suitable validation records for this Subscriber (the reseller) that are < 398 days old.The CA issues the certificate (without requiring the reseller to again prove control of Alice's domain name).
The CA sends the certificate to the reseller.The reseller forwards the certificate to Eve.Eve can't use the certificate, but that was never her intent anyway.Eve asks the reseller to revoke her cert, selecting Key Compromise as the reason, and presenting Alice's CSR as "proof".The reseller forwards this revocation request to the CA.
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACAF_WiQmexceytd6zGNDDV_E24XfOQX-_QuTE-3yBZzrJc0SA%40mail.gmail.com.