(In reply to Daniel Zens from comment #5)
BR. section 2.2 specifically requires a CA to host seperate web pages that have an i.) valid, ii.) revoked, and iii.) expired subscriber certificate. Ergo, the underlying requirements of the M.R.S.P. were not "always followed".
I agree with you that it could have been stated more clearly that the requirements were always followed except for the present incident
You might also have missed your open Bug 1716123 whilst considering your statement, but allright.
What steps have been taken to resolve this issue?
As indicated in the "timeline", there have been thourough adotptions of internal guidances. For instance It is explicitly warned that this special case is to be treated as a time critical revocation case, and the installation of certificates for test websites has to be accompanied by staff authorized also for certification and revocation.
To further reduce the risk of human error, today in the morning, so after the incident reports deadline, the system monitoring system was improved taking into account this case.
These thorough adaptations of internal guidelines were not thoroughly detailed in the report, making it difficult to determine if these changes were anything more than the worst case of 'we updated the version number after looking at the documents for a few hours'. The items you mentioned would have been great in the "list of steps your CA is taking" section.
The section "List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when" is used to describe in detail the changes made by the CA so that this issue should or will not happen again. As the section was devoid of content, I was expecting a more detailed description of meaningful changes made in your policies.
Could you explain why you believe it to be OK to not comply with the BR (albeit for a limited time period)?
globaltrust would like to make a clear statement that we do not believe that any deviation is "OK". However, I must admit that the word "although" may have provided you with some space for this interpretation.
Based on your incident report:
The internal procedural instructions for this case of certificate issuance, which the employees involved had also adhered to, expressly stipulated that the certificate was to be installed and only then revoked. This is because the server used does not allow the installation of a certificate that has already been revoked. For this reason, there is always a certain "latency period" during which the website displays a certificate that has not been revoked; ideally, of course, this is seconds or minutes
Assuming that this part of your policy hasn't materially changed, it seems that it is still policy that your 'revoked' web-page will host a non-revoked certificate for some time, each time you replace the certificate; which is a structural BR non-compliance (albeit time-limited, it is non-compliance).
I have additional concerns regarding the (potential lack of) prompt availability of the 'revoked' status in CRL and OCSP if the revocation is only done after installing the certificate on the BR-mandated 'revoked' web page. The 'revoked' status of a certificate is only materially 'revoked' if a relying party can verify that the certificate is revoked, i.e. through a 'revoked' OCSP response, or the certificate appearing in the CRLs.