1567062 - Asseco DS / Certum: inconsistent disclosure of externally-operated intermediate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

Asseco has disclosed the following intermediate as being operated under the same CP/CPS as parent:

https://crt.sh/?sha256=ACF718DF838E640051777D1947F51620E8D804BA186553AE52FC9811B5D34B8B

However, the same subject + SPKI is found in this SSL.com root certificate, which has a different CP/CPS:

https://crt.sh/?sha256=85666A562EE0BE5CE925C1D8890A6F76A87EC16D4D7D5F29EA7419CF20123B69

Comment 1

[Wojciech Trapczyński]

Thank you for reporting this. As it was described in [1] this case is not as obvious as it might seem. We will inspect it and we will share our point of view soon.

[1] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/89iF_4Ovpwg

Comment 2

[Wojciech Trapczyński]

I apologise for the delay in response. We need some more time to prepare explanation. We will have a response by August 1.

Comment 3

[Ryan Sleevi]

I'm concerned that it would take two weeks to provide an explanation for a policy violation; my own expectations had been response times in line with the Baseline Requirements' revocation timelines, to ensure prompt incident reporting.

While I'm tentatively accepting this proposed date, I think it would be to Asseco / Certum's benefit to ensure that, in the future, any Bugzilla issues are responded to with a preliminary incident report consistent with the timeframes set in Section 4.9.5 of the Baseline Requirements, even if the matter is a Policy violation and not a BR violation.

Comment 4

[Wojciech Trapczyński]

This https://crt.sh/?sha256=ACF718DF838E640051777D1947F51620E8D804BA186553AE52FC9811B5D34B8B certificate was issued by Asseco as cross-certificate, and was signed by root certificate controlled by Asseco, and we disclosed it with audit information "Same As Parent".

We generated this certificate in September 2018 and it was not in scope of currently published audit statement which covered the period April 15, 2017 to March 26, 2018. This certificate will be show up in the new audit statement which covered the period March 27, 2018 to 4 March, 2019. The new audit statement will be delivered to Mozilla immediately after we received it [1].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1566586

Comment 5

[Ryan Sleevi]

Thanks for the update!

I'm a bit confused, as the same SPKI is being reported as two different organizations' CP/CPSes. The information in Comment #4 leaves me slightly confused as to who is in operational control of the key material, so I'm hoping you can clarify this. Does Asseco/Certum control the key, or does SSL.com?

Comment 6

[Wojciech Trapczyński]

The key of signing root certificate is controlled by Asseco, SPKI: 08:76:CD:CB:07:FF:24:F6:C5:CD:ED:BB:90:BC:E2:84:37:46:75:F7.
The key of cross-certified root certificate is controlled by SSL.com, SPKI: DD:04:09:07:A2:F5:7A:7D:52:53:12:92:95:EE:38:80:25:0D:A6:59.

Comment 7

[Andrew Ayer]

Thanks for the information. To be clear, this bug concerns the SPKI with keyid DD:04:09:07:A2:F5:7A:7D:52:53:12:92:95:EE:38:80:25:0D:A6:59. This is the SPKI of the two certificates in my original report, and is currently being reported as operating under two different organizations' CP/CPSes.

SSL.com's disclosure says that this SPKI is operating under SSL.com's CP/CPS, which appears to be correct based on Comment #6.

Asseco's "same as parent" disclosure means that Asseco is reporting that this SPKI is operating under Asseco's CP/CPS, which appears to be incorrect based on Comment #6.

When CAs disclose cross-certificates in CCADB, they are supposed to disclose the audit/CP/CPS information of the subject. Has Asseco disclosed information about the issuer instead?

Comment 8

[Wojciech Trapczyński]

Yes, we disclosed audit/CP/CPS information of the issuer. This certificate was issued by our root certificate and we assumed that by ticking "same as parent" we assert that was created and is managed in accordance with our audit/CP/CPS information.

Peter Bowen's comment to the m.d.s.p. discussion [1] pointed out the possibilities of improving the CCADB. We think that is reasonable idea.

[1] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/89iF_4Ovpwg

Comment 9

[Andrew Ayer]

I direct your attention to Wayne Thayer's followup email in which he said:

I think we want to continue to hold the issuing CA accountable for disclosing any cross-certificates it signs, but they need to indicate that the audit and applicable CP/CPS is that of the subject CA when that is the case.

He also requested that CAs fix issues reported by https://crt.sh/mozilla-disclosures "as soon as possible."

Although improvements to the CCADB might be warranted, they are not required for Asseco to fix this disclosure.

As part of the remediation for this issue, I think it would be a good idea for Asseco to review all intermediate certificates signed by an Asseco-operated CA (not just those flagged by crt.sh) for accurate disclosure, and to report any further corrections here, as has been requested of other CAs.

Comment 10

[Wojciech Trapczyński]

We fixed issues reported by https://crt.sh/mozilla-disclosures. We set subject audit/CP/CPS information instead of issuer for these certificates:

• keyid: DD:04:09:07:A2:F5:7A:7D:52:53:12:92:95:EE:38:80:25:0D:A6:59 ([1] - for this ertificate crt.sh is still showing inconsistent audit details but now is probably the result of lack of EV audit for this certificate [2] in CCADB)
• keyid: F9:60:BB:D4:E3:D5:34:F6:B8:F5:06:80:25:A7:73:DB:46:69:A8:9E ([3] - this is the second cross-certificate for SSL.com)

Additionally, we will review all intermediate certificates next week. I will keep you informed.

[1] https://crt.sh/?id=759010256
[2] https://crt.sh/?id=36499471
[3] https://crt.sh/?id=759010264

Comment 11

[Wojciech Trapczyński]

We reviewed all our non-expired and non-revoked intermediate certificates and we did not find any additional inconsistency in audit/CP/CPS information.

Comment 12

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.