1525082 - Ernst & Young Poland: KIR OCSP "unknown" status for revoked certificate

Status: RESOLVED INVALID

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

In bug 1523186, KIR stated that their auditor agreed that they could leave the OCSP response for an issued certificate in an "unknown" status even if the certificate was revoked. This appears to conflict with WebTrust for CAs control 6.8.12.

Link to the discussion: https://groups.google.com/d/msg/mozilla.dev.security.policy/6MSwBBikf10/q-vyCtr_AwAJ

Lacking an email for EY Poland, I will email my North American EY contacts asking for an explanation. Note that auditors have no obligation to respond - this bug is for tracking purposes.

Comment 1

[Piotr Grabowski]

A few words to clarify this topic. Speaking about "our auditor" we mean our eIDAS auditor from our qualified services which is T-Systems.
It is his recommendation to keep OCSP status unknown until certificate is handed over to the customer. For TLS certicates we changed our processes to be compliant with WebTrust.

Comment 2

[Ben Wilson]

Based on the clarification provided in the comment above, I am closing this bug.

Comment 3

[Ryan Sleevi]

Ben: I'm reopening this bug, as I think this misunderstands Comment #1 in two very important ways.

First, Comment #1 appears to be saying that this wasn't "EY Poland" that stated it, but "T-Systems". This seems important, especially if this bug is against the wrong audit firm!

Second, Comment #1 seems to be saying it was "fixed" by aligning with WebTrust, but that also seems to be a mistake, especially since Mozilla spent considerable time trying to make sure and clarify the expectations - that "non-delivery" of a certificate doesn't count as not having issued it (e.g. as we saw in the past regarding undisclosed sub-CAs), and that precertificates are treated "as if" it's issued.

I don't think we should rush to close this bug until we can better understand how this has been resolved by the auditor, and until we're sure which auditor it is.

Comment 4

[Piotr Grabowski]

We are issuing qualified and non-qualified certificates.
Qualified services undergo an eIDAS audit, non-qualified WebTrust audit.
In the first case our audior is T-Systems, in the second case EY Poland.
For TLS (non-qualified) certificates we are now aligned with WebTrust and we are counting "non-delivered" certificates as issued, but
opinion of our eIDAS auditor on this matter is completely different.

Comment 5

[Ryan Sleevi]

Trying to make sure I understand Comment #4 and Comment #1 correctly:

When https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c10 mentioned "we had a big discuss with our auditors about that", this was with T-Systems, correct? And at no point did you discuss this with E&Y Poland?

Comment 6

[Piotr Grabowski]

True, the big discuss was with T-Systems. We got a recommendation to make change in our OCSP service to count "non-delivered" certificates as unknown.
We didn't discuss this with E&Y, we have just aligned to WebTrust when it turned out it is not compliant.
So now, our OCSP works diffrently for qualified and non-qualified certificates.

Comment 7

[Ryan Sleevi]

Ben: I'm not sure how you'd like to handle this.

From the perspective of E&Y Poland, it sounds like this is Resolved/Invalid.
We could retitle this bug T-Systems, except that as I understand it, Mozilla does not rely on the T-Systems audit/assessments as the basis of trust (e.g. judging from https://crt.sh/?id=12979946 and CCADB), so I'm not sure what we might expect.

From the related discussion in Comment #0, there's clear consensus that it's bad advice, whomever is providing it, but I'm not sure to the extent we can correct that.

What are your thoughts?

CC'ing Wayne for feedback, since he originally opened this issue.

Comment 8

[Wayne Thayer]

I agree that this bug should be resolved as invalid.

Piotr: for the qualified certificates being audited by T-Systems, are there technical controls in place that put those certificates out of scope of Mozilla's root store policy, which covers both serverAuth and emailProtection EKUs? Can you provide an example of one of those certificates?

Comment 9

[Piotr Grabowski]

Wayne, qualified eIDAS certificates are out of scope of Mozilla's root store policy, they come from completely different, technicallly separarated subCA and ROOT which is not listed in Mozilla but in the european TSL lists. The certificates are used for digital signature/non-repudiation by the end-users mainly and they have any EKU. As they contain personal numbers I would rather not provide an example publicly.

Comment 10

[Wayne Thayer]

Thank you Piotr, than answers my question.