[meta] Delayed Revocation
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: bwilson, Assigned: bwilson)
References
(Depends on 21 open bugs)
Details
(Whiteboard: [ca-compliance] [meta] [leaf-revocation-delay])
Incidents for delayed revocation that must be resolved before this bug can be resolved.
|
||
Comment 1•2 months ago
|
||
What will it mean for this bug to be resolved? Just that there are that moment no open delrev incidents?
|
||
Comment 2•2 months ago
|
||
As you know, GTLSCA team was failure to follow through on its responsibilities as a public CA as detailed in the BR.
To make sure GTLSCA will not be delaying revocation in the future, Root CA team has communicated and reached consensus with the CA owner, which is the responsible government agency of Taiwan. GTLSCA will notify subscribers via email and website announcement to replace their certificates in case of mis-issuance or incidents, and the revocation will also be done in accordance with the TLS BR timeline. No excuses, no individual communication with subscribers.
The Root CA team will jointly manage and assist GTLSCA in fulfilling its responsibilities of a public CA. GTLSCA may at its own discretion revoke TLS certificates if it obtains evidence or being notified that the certificate is used in any critical infrastructure or under the circumstances/revoke reason in BR 4.9.1.
Description
•