On 09/02/2016 19:08, Matt Palmer wrote:
On Tue, Feb 09, 2016 at 04:24:22AM -0800, Erwann Abalea wrote:
Bonjour,
Le mardi 9 février 2016 10:47:16 UTC+1, Jesus F a écrit :
Dear all,
As A-Trust request EV treatment, I checked the EV issued certificates from
a-sign-SSL-EV-05 subordinate in ctr.sh (https://crt.sh/?Identity=%25&iCAID=6096)
ALL of them states in businessCategory the following text "V1.0, Clause 5.(X)". This text is similar to what permitted by EV
guidelines version 1.2 and prior, although "X" should have been "b", "c", "d" or "e"
depending upon whether the Subject qualifies in the permitted categories. This text is not permitted since EV guidelines version 1.3
published in 2010.
As the EV audit conducted by E&Y states A-trust is in compliance with "WebTrust
Principles and Criteria for Certification Authorities - Extended Validation SSL - Version
1.4.5" that is based on CA/Browser Forum Guidelines for the Issuance and Management of
Extended Validation SSL Certificates - Version 1.4.5 and it's obvious that the auditor failed
to detect this very basic issue, can we, the Mozilla Community, be reasonably assured of any
of the auditor's necessary checks?
In addition there are several more issues in this certificates:
- rfc822Name in SAN (https://crt.sh/?id=8889537&opt=cablint,
https://crt.sh/?id=8889537&opt=cablint)
- FATAL: ASN.1 Error in EmailAddress (https://crt.sh/?id=12491213&opt=cablint,
https://crt.sh/?id=9410992&opt=cablint)
- This cert has the following errors: Cert without subject alternative names
extension, Cert of 1024 bits (https://crt.sh/?id=8935972&opt=cablint)
Without saying that the audit was perfect, but all the presented evidences here
have been produced after the audit was performed.
I may be misunderstanding the purpose of an audit, but doesn't the fact that
the evidence was created after the audit was performed show that the audit
was, in fact, insufficient? To my way of thinking, an audit is supposed to
verify that things can *only* be done in a conformant manner -- that is,
that there are procedures and controls in place to prevent Bad Things from
happening. In this case, it is fairly clear that Bad Things have, in fact,
happened, based on the existence of certificates issued in contravention of
the BRs. Thus, the CA's procedures are insufficient, and the audit *should*
have found that, or else the audit is useless and unnecessary, and we should
just rely on catching bad happenings after the fact via CT.
- Matt
With any kind of audit (whether of fiscal accounting or other things),
expecting the auditor to be able to foresee any potential future mishap
leads to madness and meaningless audit elements (such as the
requirement in current legislation that company auditors should assess
and publish if they believe the company will survive the coming year).
What an auditor can reasonably check (without resorting to potentially
disastrous pen-testing), is if the current official (written) internal
procedures are correct, if the CA private key is stored in a certified
secure way, if the systems that actually sign certificate requests are
in a locked room with physical mechanisms to ensure two authorized
persons have to enter together. The auditor can and should also check
that records of past (public and private) activities are being
correctly maintained, are up to date, are consistent with the
observable current state of things etc. For instance the auditor can
check if the set of software changes/patches/updates installed
corresponds to the list of software changes in the written maintenance
log.
But the auditor cannot be expected to do things such as:
- Debug or verify the code in any commercial or in-house software and
scripts used to run the CA (he may be able to check if requirements
for 3rd party validations, such as FIPS 140-2 in US gov CAs are met
by checking if the certification documentation is in place).
- Make obviously invalid certificate requests to check if this such
requests are spotted and rejected.
- Test the CA's web interface for XSS or SQL injection bugs.
- If any of the authorized people are stupid in any but the most
glaringly obvious way.
Note for clarity, that unlike the audits of published procedures (CP,
CPS etc.) done in this forum, an auditor can check if the more detailed
internal procedure documents are consistent with the published
documents and the applicable standard(s). For instance the auditor has
the right and duty to access and check documents that reveal exactly
who in the CA organization checks what aspect of a request, how they
perform any additional checks to catch fraudulent requests that somehow
manage to fake the checks that are listed in the CP/CPS documents etc.
For example a CA may have a special permission and procedure to
directly check certain government records of applicants, even though
the published procedures say the applicant must provide a certified
copy. This would catch a fraudulent application accompanied by a
perfectly forged certified copy of such records.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
