Re: Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)
I've reached to the auditor (in this case, TUVIT) to understand why they
failed to detect this major non-conformity.
Now that I'm back in the states, following the CA/Browser Forum F2F, I've
had a chance to look more closely at the set of CAs that have issued. This
is not a full lint check - I've only included certificates I can minimally
parse as correct in these extensions.
In addition to T-Systems, it appears Certinomis, ComSign, and MULTICERT
have similarly taken to misencoding.
In the case of Certinomis, an example certificate is
https://crt.sh/?q=38d025ffe77ac1cd2142764fce4fb5fc619e5da536b3adac6904036f40addf80
Although it includes a qcStatements, it includes an OID of 0.4.0.1.6, which
is not valid for purpose, with the id-etsi-qct-web extension. It appears
that the "1" is most likely a typo for the full id-etsi-qcs, which is that
of 0.4.0.1862.1.6 - that is, they omitted the 1862 arc. They properly
encode the id-etsi-qcs-QcPDS with its QcLocations. However, they do not
assert compliance with the ETSI EN 319 412-5 profile (that is, OID
"0.4.0.1862.1.1" is not asserted), so this is a semantic misencoding but
not clearly a violation of the asserted profile.
In the case of ComSign, an example certificate is
https://crt.sh/?q=2d5a2596f315ba823758b2a0380de1e0e9cc22d6e045abe45e1cd7fb2c5fe01e
This one is a hot mess of improper encoding, probably best captured by
pointing out the misencoding of RFC 3739's SemanticsInformation from
qcStatement-1 (OID "1.3.6.1.5.5.7.11.1") and the inclusion of an unassigned
ETSI OID ("0.4.0.1862.11.1") that appears to be combining these two.
However, Mozilla has already made a decision about ComSign going forward.
In the case of MULTICERT, they're trusted transitively by AC Camerfirma in
https://crt.sh/?id=573264407 , which is valid for SSL in Mozilla, and an
example cert is
https://crt.sh/?q=5bada9c841242c13c035496d5668d4a59cb91bb839e9e625a9c63c0e687269ab
In this certificate, they completely botched the syntax, treating
"0.4.0.1862.1.6.3" as permitting an optional UTF8String message, which
states "Certificate for website authentication as defined in Regulation
(EU) No 910/2014"
MULTICERT is the most interesting of these. AC Camerfirma has claimed in
Salesforce that the audits are the same as the parent - however, this does
not seem to be met by
https://bug1478933.bmoattachments.org/attachment.cgi?id=8995930 , which is
the disclosed audit for the AC Camerfirma roots (by Auren). Auren's audit
is dated July 14, 2018 and covers the period up to April 13, 2018. The
cross-certificates were issued on Jun 29, 2018 (
https://crt.sh/?id=568548659 ) and Jul 3, 2018 (
https://crt.sh/?id=573264407 ), the former being revoked, the latter, not.
I find this questionable and suspicious, because MULTICERT also operates
its own root (within the Microsoft program), yet no audit information has
been provided (by Microsoft or MULTICERT). The closest I've found is
https://bugzilla.mozilla.org/show_bug.cgi?id=1433320 , which was provided
by DigiCert because of https://crt.sh/?caid=1013 . Based on this, I believe
that the most likely result is that AC Camerfirma has potentially mislead
the community about the state of the audits - or that the misissuing
MULTICERT Sub-CA has been audited multiple times (by both Auren and by
APCER, which seems unlikely).
As a result, it appears we have one clear misissuance by a CA in Mozilla's
program - MULTICERT - and a potential issue with the auditor (APCER –
Associação Portuguesa de Certificação) - and two potential issues - AC
Camerfirma for the potential audit disclosure issue, and Certinomis for the
possible misassertion issue (unless it can demonstrate that ETSI authorized
that OID, it would be violating 7.1.2.4 of the BRs)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
On Thu, Oct 25, 2018 at 10:11 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 26/10/2018 01:13, Ryan Sleevi wrote: > > On Thu, Oct 25, 2018 at 5:47 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On 25/10/2018 23:10, Wayne Thayer wrote: > >>> On Thu, Oct 25, 2018 at 11:17 AM Joanna Fox via dev-security-policy < > >>> dev-security-policy@lists.mozilla.org> wrote: > >>> > Questions about blank sections, thinking of a potential future > requirement. Sections such as 1.INTRODUCTION would remain blank as > they > >> are > more titles than components, correct? > If no sections are allowed to be blank does this include both levels > of > components such as 1.4 and 1.4.1? > > I would argue that higher level sections (e.g. 1.4) aren't blank if > >> they > >>> include subsections (e.g. 1.4.1). If there are no subsections under a > >>> section (e.g. 1.1 or 2), then the section should not be blank. > >>> > >>> Also, what is the opinion on adding sections to the CP/CPS that are not > included in the RFC? > > Good question. My opinion is that it's okay to add sections as long as > >>> they come after RFC 3647 defined sections and thus don't change the RFC > >>> numbering. I've noted this in the policy issue - > >>> https://github.com/mozilla/pkipolicy/issues/158 > >>> > >> > >> Would it be OK (I think it should) to place new sublevel sections under > >> appropriate higher level sections, after the RFC section numbers run out > >> at that level? > > > > > > Can you explain why that is valuable? > > > > What purpose do you believe the CP/CPS structure serves? One of the goals > > of developing the structure in the RFC was to identify the common > sections > > applicable to all CAs, with a consistent structure, to allow easy > > comparison between policies. Indeed, early audit processes proposed > making > > these policies machine readable and templated, to expedite comparisons. > > > > I is quite obvious that the 15 year old RFC3647 doesn't cover all the > issues that need to be covered in a modern CP/CPS, the BRs already add > many subsections not in the RFC. I was giving concrete examples about > what kinds of sections to add. > > However my question wasn't if additional sections could be added, this > was already asked by someone obviously intending to do so. > > I was asking if such new sections could be placed where they would make > the most logical sense rather than being confined to a section 10 > appendix. I then gave examples of how some commonly occurring issues > (such as a single CP/CPS covering both WebPKI and non-WebPKI roots) > would fit more neatly earlier in a policy document. > > My response stating that I think this is okay was intended to include adding new subsections to the end of any of the existing sections. I do share some concern with this because it has and will continue to result in information being placed into new sections rather than appropriate existing sections. However, I also think there are legitimate reasons for adding sections, and it makes more sense to logically group them with similar content than at the end of the doc. > > > 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 > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
