Closed Bug 1311200 Opened 8 years ago Closed 8 years ago

add revoked UniCredit intermediates to OneCRL

Categories

(NSS :: CA Certificates Code, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: keeler, Assigned: mgoodwin)

References

Details

(In reply to Steven Medin from bug 1261919 comment #28) > As disclosed @27, today we revoked subordinate CAs issued to UniCredit under > the GeoTrust Global CA. The revoked CAs are posted to our public CRL at > http://g.symcb.com/crls/gtglobal.crl. Four entries were added to the CRL for > this event. > > These revocations have been marked on the subject certiifcates at Mozilla > Salesforce. > > Here are references to the subordinate CAs: > https://crt.sh/ > ?sha256=8c31013d19f8eea618c95fda6d21f5777c6e930c7413031559ee863d78dfe809 > https://crt.sh/ > ?sha256=fdadfc959cbeeecbdb60711a7143bf9922f3e7c232ff59cb59d076fef6637610 > https://crt.sh/ > ?sha256=adb034413ad16b538c57f5a0bd103b3504736f99b0c762a53e72fa7a2b5eca46 > https://crt.sh/ > ?sha256=77057825b10ea26292e56cde58ee92a1a27baf536b7ad383971b2ae5912227bb (I don't know if we have the salesforce -> OneCRL integration set up yet, but I wanted to make sure this didn't get dropped.)
One complication: Actalis has now issued a name-constrained version of this intermediate. Revoking via Key in OneCRL will affect this cross-sign, which may now be in compliance. It should show up in https://crt.sh/?q=71a04968c76a78efb5cc26714cef96795335a0f8 within the next 24 hours.
My understanding is we're going to revoke by issuer/serial number, so chains using the cross-sign should validate successfully.
Assignee: nobody → mgoodwin
David, Kathleen: Right, rejecting by issuer/serial will resolve this, but there is the question about Mozilla's policy implications. The BRs require that even name-constrained sub-CAs be operated according to the BRs, just under the CA's audit. We know that this particular sub-CA has not been adhering to the BRs, so there's a question about whether or not revocation of an intermediate (for non-BR compliance) can be certified by another CA under name constraints. Mozilla Policy allows technically constrained sub-CAs to be exempt from the audit requirements, but it's unclear Mozilla's position on: 1) The interpretation of the BRs as it relates to this point, as it would seem to not be allowed under the BRs 2) The expectations of Mozilla with respect to revoking sub-CAs for non-compliance, and whether to allow them to be certified by other CAs under name-constraints. It's totally reasonable to continue this discussion after adding the issuer/serial to OneCRL, but I did want to make sure the complication was noted and considered :)
Flags: needinfo?(kwilson)
Flags: needinfo?(dkeeler)
(In reply to Ryan Sleevi from comment #3) > Mozilla Policy allows technically constrained sub-CAs to be exempt from the > audit requirements, According to Mozilla's policy, intermediate certs that are appropriately technically constrained via EKU and Name Constraints do not need to be disclosed, and Mozilla will not require the subCA to provide public-facing audits and CP/CPS documentation. Therefore, it is not within my realm to review such technically-constrained intermediate certs. > but it's unclear Mozilla's position on: > 1) The interpretation of the BRs as it relates to this point, as it would > seem to not be allowed under the BRs It is not my job to enforce the BRs on a subCA that is technically-constrained via EKU and Name Constraints to only be able to issue certificates for domains that the subCA owns/controls. > 2) The expectations of Mozilla with respect to revoking sub-CAs for > non-compliance, and whether to allow them to be certified by other CAs under > name-constraints. When a subCA is technically-constrained via EKU and Name Constraints to only be able to issue certificates for domains that the subCA owns/controls, I do not need to know about it, and I do not need to state an opinion about it (as per Mozilla's CA Certificate Policy). > > It's totally reasonable to continue this discussion after adding the > issuer/serial to OneCRL, but I did want to make sure the complication was > noted and considered :) If further discussion is needed about this, let's have the discussion in the mozilla.dev.security.policy forum. Thanks.
Flags: needinfo?(kwilson)
Thanks, posted the further description of the nuance/disagreement to https://groups.google.com/d/msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ for further discussion
Flags: needinfo?(dkeeler)
Blocks: onecrl-meta
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
The non-expired revoked intermediate certs listed in this bug have been added to OneCRL. All future revocations of intermediate certs should be reported as described here: https://wiki.mozilla.org/CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce
You need to log in before you can comment on or make changes to this bug.