Re: Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

[Wayne Thayer via dev-security-policy]

Thanks Ryan. It's not entirely obvious, but I understand your logic and it
makes sense. If anyone disagrees, please speak up. Meanwhile, I've opened a
misissuance bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1498463

- Wayne

On Thu, Oct 11, 2018 at 3:39 PM Ryan Sleevi  wrote:

>
>
> On Fri, Oct 12, 2018 at 2:32 AM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Thank you for this report Fotis.
>>
>> On Thu, Oct 11, 2018 at 6:13 AM Fotis Loukos via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > Summary
>> > ---
>> >
>> > A number of Qualified Web Authentication Certificates have been issued
>> > with incorrect qcStatements encoding. A small survey displays that all
>> > certificates issued by a specific SubCA are affected by this issue
>> > (https://crt.sh/?CN=%25=1481). The CA has been notified about
>> > this, but more than a week has passed and it has not yet provided any
>> > feedback, while it continues to issue such malformed certificates (e.g.
>> > https://crt.sh/?id=816495298).
>> >
>> > Technical details
>> > -
>> >
>> > According to ETSI EN 319 412-5 (Electronic Signature and Infrastructure
>> > (ESI); Certificate Profiles; Part 5: QCStatements) section 4.2.3
>> > (QCStatement claiming that the certificate is a EU qualified certificate
>> > of a particular type), the QCStatement QcType with OID
>> > id-etsi-qcs-QcType (0.4.0.1862.1.6) declares that a certificate has been
>> > issued for a particular purpose (e-sign, e-seal, qualified web
>> > authentication certificate). Every certificate containing this
>> > QCStatement must have a SEQUENCE OF OBJECT IDENTIFIER which declares the
>> > purpose, e.g. id-etsi-qct-web (0.4.0.1862.1.6.3).
>> > T-Systems International GmbH has failed to follow this specification,
>> > and instead issues certificates having id-etsi-qct-web as a QCStatement.
>> > Such a certificate can be found at https://crt.sh/?asn1=795148644. You
>> > can compare this with https://crt.sh/?asn1=844599393 which has the
>> > QcType QCStatement correctly encoded.
>> >
>> > Disclosure to CA timeline
>> > -
>> >
>> > - 2 October 2018: First notification to the CA, with a detailed
>> > description of the issue.
>> > - 2 October 2018: Reply by a CA representative that they will look at
>> it.
>> > - 8 October 2018: Second notification and request for feedback.
>> >
>> > No further communication has taken place.
>> >
>> > Impact to WebPKI
>> > 
>> >
>> > Two issues can be identified.
>> >
>> > The first issue is the incorrect encoding of the QCStatement. My
>> > assessment is that this problem does not affect the WebPKI, since as far
>> > as I can tell, no browsers decode or utilize the QCStatements extension.
>> >
>> > The second issue is the failure of the CA to identify the problem, reply
>> > in time, possibly revoke the problematic certificates and at least
>> > momentarily pause the issuance of new certificates until the issue is
>> > resolved. I consider this a serious issue that displays problematic
>> > practices within the CA.
>> >
>> > I share your concern for the CA's responsiveness, but I'm not seeing
>> anything that would make this a violation of the BRs or Mozilla's
>> policies.
>
>
> The BRs requires certificates to comply with RFC 5280, and that all
> extensions meet the requirements of 7.1.2.4 of the BRs. Mozilla Root CA
> Policy 5.2 prohibits both incorrect extensions and invalid DER encoding.
> These two entries are distinct in policy, as the “invalid DER” rule
> unambiguously sets restrictions on the encoding rules being adhered to,
> while the “incorrect extensions” addresses any semantic violation of the
> encoding (since both of those cases are possible to encode in DER, but
> their extension definition says you MUST NOT encode entries like that
> because they do not conform to the extension’s textual definition.
>
> The expectation is that if there is a defined ASN.1 module for the
> extension being included within a certificate, the CA will observe that
> encoding (Moz Policy 5.2 - “invalid DER”) and semantics (“incorrect
> extensions”) as defined by the entity responsible for that OID namespace
> (BRs 7.1.2.4), and as stated in the CA’s CP/CPS (BRs & Moz Policy).
>
> I don’t think 7.1.2.4, or Section 5.2 of Mozilla Policy, can be read as
> “The only things in certificates that need to be properly encoded are those
> explicitly defined or referenced in RFC 5280,” as that would prohibit the
> effective deployment of any new extensions. Given that RFC 5280 was
> explicitly meant to be extendable by a variety of other documents, and
> through its use of OIDs, without the explicit consent of or coordination
> with the IETF, taking the narrow view very rapidly leads to logical
> inconsistencies.
>
> For example, to take the narrow “only explicitly in 5280” view, then any
> DER encoding errors within the subjectPublicKeyIdentifier 

Re: Violation report - Comodo CA certificates revocation delays

[Ryan Sleevi via dev-security-policy]

I believe that may be misunderstanding the concern.

Once these certificates expire, there's not a good way to check whether or
not they were revoked, because such revocation information may be culled
after certificate expiration.

Similarly, if one is looking to verify the claims about revocation dates
and timelines, once those are culled from the CRLs, you can only
demonstrate with past CRLs or responses that may have been archived.

The concern about December 6 represents when some of the certificates begin
to expire, and thus being able to examine whether or not and when things
were done may no longer be available.

On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Oct 11, 2018 at 11:19:18PM +, please please via
> dev-security-policy wrote:
> > I was under the impression that CAs were allowed to remove CRL entries
> and OCSP support for expired certificates for some reason. Good to know!
>
> CT logs are not CRLs or OCSP responders, nor do they track revocation.
>
> - Matt
>
> ___
> 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

Re: Violation report - Comodo CA certificates revocation delays

[Matt Palmer via dev-security-policy]

On Thu, Oct 11, 2018 at 11:19:18PM +, please please via dev-security-policy 
wrote:
> I was under the impression that CAs were allowed to remove CRL entries and 
> OCSP support for expired certificates for some reason. Good to know!

CT logs are not CRLs or OCSP responders, nor do they track revocation.

- Matt

___
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?

[Kathleen Wilson via dev-security-policy]

Based on the input into this discussion so far, I propose to add the 
following section to the Required part of this wiki page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices

We can consider adding text about this directly to Mozilla's Root Store 
Policy later. (I'll file the request/issue in github.)


-- Proposed Text --
Section Heading: CP/CPS Structured According to RFC 3647

CP/CPS documents must be structured according to RFC 3647. This 
requirement is stated in section 2.2 of the CA/Browser Forum Baseline 
Requirements, with the effective of 31 May 2018. Further, CP/CPS 
documents should include every component and subcomponent, and the 
placement of information should be aligned with the BRs; e.g. domain 
validation practices should be documented in section 3.2.2.4 of the CA’s 
CP/CPS.


The words "No Stipulation" mean that the particular document imposes no 
requirements related to that section.


Any CPS that falls within the scope of Mozilla’s program must not use 
the words “No stipulation” unless the corresponding section in the 
CA/Browser Forum Baseline Requirements state “No stipulation”, “Not 
applicable”, or is blank. The words “Not applicable” are acceptable to 
indicate that the CA’s policies forbid the practice that is the title of 
the section. Language similar to “We do not perform section>” is preferred. If a full description of a section is repeated 
elsewhere in the document, language similar to “Refer to Section 1.2.3” 
is preferred.


Examples:
- If your CA does not allow a particular domain validation method to be 
used, then the CP or CPS should say that, e.g. "This method of domain 
validation is not used".
- The BRs do not allow certificate suspension, so the CA’s CPS must 
state that certificate suspension is not allowed, and then the other 
sections related to suspension should say “Not applicable”.
- If your CA does not issue SSL certs containing IP addresses, then 
section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS 
should say that such certificate issuance is not allowed; e.g. “No IP 
address certificates are issued under this CPS.”



I will appreciate your constructive feedback on this.

Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[please please via dev-security-policy]

I was under the impression that CAs were allowed to remove CRL entries and OCSP 
support for expired certificates for some reason. Good to know!

On a slightly-unrelated note, you might also want to poke Comodo CA about 
https://bugzilla.mozilla.org/show_bug.cgi?id=1461391

Thanks again!

Guillaume Fortin-Debigaré

From: Wayne Thayer 
Sent: October 11, 2018 13:53
To: pleaseiwantt...@hotmail.com
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays

I just poked Comodo in the bug - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1492006

CT Logs are designed such that certificates cannot be removed from them. The 
evidence will not disappear once the certificates expire.

On Wed, Oct 10, 2018 at 5:26 PM please please 
mailto:pleaseiwantt...@hotmail.com>> wrote:
Any update behind the scenes about this issue? I've noticed that the soft limit 
to fill an Incident Report expired more than a week ago, and I'm starting to be 
a bit worried that some of the evidence in the CT logs might disappear if the 
investigation is not completed before December 6th, the earliest expiration 
date among the affected certificates.

Guillaume Fortin-Debigaré

From: please please 
mailto:pleaseiwantt...@hotmail.com>>
Sent: September 17, 2018 23:39
To: Wayne Thayer
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays

Good to know, and thank you very much for following up on this!

Small update by the way: I finally received a reply from Comodo CA confirming 
their 2nd wave of revocations a few hours ago, on September 17 at 16:55 UTC to 
be exact. Strangely, it was in response to an email where I informed them that 
I had already noticed they fully completed my revocation request. I don't think 
it's a relevant detail but I wanted to mention it to avoid any potential 
confusion.

Guillaume Fortin-Debigaré


From: Wayne Thayer mailto:wtha...@mozilla.com>>
Sent: September 17, 2018 20:09
To: pleaseiwantt...@hotmail.com
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays

I have created a bug and requested a response from Comodo: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1492006

As noted, there are no specific requirements regarding how CAs validate 
revocation requests in the BRs. Every CA may do this however they choose, so I 
don't believe there is any action required in regard to DigiCert's response to 
their problem report.

- Wayne

On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Hello, I am the domain owner of debigare.com. I would like 
to make you aware that Comodo CA took more than 5 days to revoke certificates 
they had signed for my domain and subdomains after requesting them to do 
through their sslabuse email address, past the 24 hours maximum mentioned in 
the Baseline Requirements as stipulated in section 4.9.1.1.

For context, I was previously using Cloudflare's Universal SSL feature, but 
disabling it did not revoke the old certificates that had not yet expired, but 
simply removed them from its system, and some of the certificates were still 
valid for more than 6 months.

I first attempted to contact Cloudflare's support to ask them to revoke the 
certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant 
responses and confused customer support agents that had no idea what I was 
talking about, and this appeared to go nowhere. I eventually got a response 
from them on September 11 at 5:53 UTC that they would request CAs to perform 
the revocation, but that was after I did so myself, and I never got a status 
report back afterwards.

There were two CAs affected by this issue. The vast majority of certificates 
were signed by Comodo CA, and the rest by DigiCert. I did not run into any 
issues with DigiCert (they in fact proactively checked with Cloudflare my claim 
and revoked the certificates before I even had the chance to attempt their 
domain ownership challenge), but Comodo CA was another story entirely.

My first request to Comodo CA to revoke the certificates for 
debigare.com and all of its subdomains was on September 8 
at 4:37 UTC. I did not get a reply until September 9 at 15:53 UTC stating that 
the certificates have been revoked. Not only was this past the 24 hours 
requirement, but it was also false, as only the most recent certificates had 
been revoked, not all of them. I mentioned to them their mistake on September 
10 at 5:55 UTC with a full list of affected certificates just in case my 
initial request was unclear to them, and never got a reply back. I did, 
however, notice that the certificates eventually got revoked on September 13 at 
16:04 UTC according to their Certificate Transparency logs, a fact that I only 
discovered on September 

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

[Samuel Pinder via dev-security-policy]

Visiting the www.emsign.com homepage brings up a list of proposed products.
Currently, in the "Types of Certificate" table halfway down the page is the
following:
 Wildcard SSL - OV
 Wildcard SSL - EV
 UCC Wildcard SSL - DV
 UCC Wildcard SSL - OV
 UCC Wildcard SSL - EV

That's not a good sign at all, since two of those imply EV and wildcard as
a single product. EV certificates cannot contain wildcards! This has always
been the case so why is this company, claiming 10 years experience, making
a mistake like this to propose such a product?
Sam
P.S. Sorry I don't contribute as much as I could, I do monitor this list
and read through regularly however.
Source: http://web.archive.org/web/20181011224402/http://emsign.com/ (Saved
to Web Archive in case the page is changed after this is pointed out).

On Thu, Oct 11, 2018 at 11:33 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Oct 11, 2018 at 02:36:18PM -0700, Wayne Thayer via
> dev-security-policy wrote:
> > Nick - I expect an emSign representative to respond to all of your
> > questions, but their information request indicates that they have been
> > operating the Indian Government Root for more than 10 years and have
> issued
> > over 35 million certificates:
> > https://bug1442337.bmoattachments.org/attachment.cgi?id=8955223
>
> The phrasing in the paragraph (I think) you're referencing is ambiguous:
>
> > eMudhra has been a licensed CA under Controller of Certifying Authorities
> > which operates the Indian Government Root for more than 10 years
>
> I'm not sure whether it's eMudhra or the "Controller of Certifying
> Authorities" which has been operating the Indian Government Root for more
> than 10 years.  At any rate, I can't seem to find any information about
> this
> "Indian Government Root", how it works, what it's used for, and what its
> criteria are, and so it's a bit hard to tell whether it's anything to be
> particularly proud of.
>
> If eMudhra *have* been in the CA business for 10 years, but they still
> managed to produce a CPS with the extensive list of "Bad"-grade practices
> you enumerated in your opening e-mail, that's... not encouraging.
>
> - Matt
>
> ___
> 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

Re: Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

[Ryan Sleevi via dev-security-policy]

On Fri, Oct 12, 2018 at 2:32 AM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thank you for this report Fotis.
>
> On Thu, Oct 11, 2018 at 6:13 AM Fotis Loukos via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Summary
> > ---
> >
> > A number of Qualified Web Authentication Certificates have been issued
> > with incorrect qcStatements encoding. A small survey displays that all
> > certificates issued by a specific SubCA are affected by this issue
> > (https://crt.sh/?CN=%25=1481). The CA has been notified about
> > this, but more than a week has passed and it has not yet provided any
> > feedback, while it continues to issue such malformed certificates (e.g.
> > https://crt.sh/?id=816495298).
> >
> > Technical details
> > -
> >
> > According to ETSI EN 319 412-5 (Electronic Signature and Infrastructure
> > (ESI); Certificate Profiles; Part 5: QCStatements) section 4.2.3
> > (QCStatement claiming that the certificate is a EU qualified certificate
> > of a particular type), the QCStatement QcType with OID
> > id-etsi-qcs-QcType (0.4.0.1862.1.6) declares that a certificate has been
> > issued for a particular purpose (e-sign, e-seal, qualified web
> > authentication certificate). Every certificate containing this
> > QCStatement must have a SEQUENCE OF OBJECT IDENTIFIER which declares the
> > purpose, e.g. id-etsi-qct-web (0.4.0.1862.1.6.3).
> > T-Systems International GmbH has failed to follow this specification,
> > and instead issues certificates having id-etsi-qct-web as a QCStatement.
> > Such a certificate can be found at https://crt.sh/?asn1=795148644. You
> > can compare this with https://crt.sh/?asn1=844599393 which has the
> > QcType QCStatement correctly encoded.
> >
> > Disclosure to CA timeline
> > -
> >
> > - 2 October 2018: First notification to the CA, with a detailed
> > description of the issue.
> > - 2 October 2018: Reply by a CA representative that they will look at it.
> > - 8 October 2018: Second notification and request for feedback.
> >
> > No further communication has taken place.
> >
> > Impact to WebPKI
> > 
> >
> > Two issues can be identified.
> >
> > The first issue is the incorrect encoding of the QCStatement. My
> > assessment is that this problem does not affect the WebPKI, since as far
> > as I can tell, no browsers decode or utilize the QCStatements extension.
> >
> > The second issue is the failure of the CA to identify the problem, reply
> > in time, possibly revoke the problematic certificates and at least
> > momentarily pause the issuance of new certificates until the issue is
> > resolved. I consider this a serious issue that displays problematic
> > practices within the CA.
> >
> > I share your concern for the CA's responsiveness, but I'm not seeing
> anything that would make this a violation of the BRs or Mozilla's policies.


The BRs requires certificates to comply with RFC 5280, and that all
extensions meet the requirements of 7.1.2.4 of the BRs. Mozilla Root CA
Policy 5.2 prohibits both incorrect extensions and invalid DER encoding.
These two entries are distinct in policy, as the “invalid DER” rule
unambiguously sets restrictions on the encoding rules being adhered to,
while the “incorrect extensions” addresses any semantic violation of the
encoding (since both of those cases are possible to encode in DER, but
their extension definition says you MUST NOT encode entries like that
because they do not conform to the extension’s textual definition.

The expectation is that if there is a defined ASN.1 module for the
extension being included within a certificate, the CA will observe that
encoding (Moz Policy 5.2 - “invalid DER”) and semantics (“incorrect
extensions”) as defined by the entity responsible for that OID namespace
(BRs 7.1.2.4), and as stated in the CA’s CP/CPS (BRs & Moz Policy).

I don’t think 7.1.2.4, or Section 5.2 of Mozilla Policy, can be read as
“The only things in certificates that need to be properly encoded are those
explicitly defined or referenced in RFC 5280,” as that would prohibit the
effective deployment of any new extensions. Given that RFC 5280 was
explicitly meant to be extendable by a variety of other documents, and
through its use of OIDs, without the explicit consent of or coordination
with the IETF, taking the narrow view very rapidly leads to logical
inconsistencies.

For example, to take the narrow “only explicitly in 5280” view, then any
DER encoding errors within the subjectPublicKeyIdentifier are totally
permissible - because the relevant algorithms aren’t described by,
normatively referenced by, not explicitly update 5280. Instead, RFCs like
RFC 3447 stand alone, but are used by these other RFCs. With this narrow
view, it would be saying that there is carte blanche to ignore normative
requirements in any extensible field. That is, any field with an OID can
have whatever value or semantics that the 

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

[Matt Palmer via dev-security-policy]

On Thu, Oct 11, 2018 at 02:36:18PM -0700, Wayne Thayer via dev-security-policy 
wrote:
> Nick - I expect an emSign representative to respond to all of your
> questions, but their information request indicates that they have been
> operating the Indian Government Root for more than 10 years and have issued
> over 35 million certificates:
> https://bug1442337.bmoattachments.org/attachment.cgi?id=8955223

The phrasing in the paragraph (I think) you're referencing is ambiguous:

> eMudhra has been a licensed CA under Controller of Certifying Authorities
> which operates the Indian Government Root for more than 10 years

I'm not sure whether it's eMudhra or the "Controller of Certifying
Authorities" which has been operating the Indian Government Root for more
than 10 years.  At any rate, I can't seem to find any information about this
"Indian Government Root", how it works, what it's used for, and what its
criteria are, and so it's a bit hard to tell whether it's anything to be
particularly proud of.

If eMudhra *have* been in the CA business for 10 years, but they still
managed to produce a CPS with the extensive list of "Bad"-grade practices
you enumerated in your opening e-mail, that's... not encouraging.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

[Matt Palmer via dev-security-policy]

On Thu, Oct 11, 2018 at 01:06:46PM -0700, Wayne Thayer via dev-security-policy 
wrote:
> * The CPS allows “external issuing CAs” but does not clearly state that the
> requirements of BR section 1.3.2 will be met. emSign made the following
> comment in response to this concern: “In the CP/CPS, there is reasonable
> definition for both External Issuing CAs and External RAs. Section 1.1 of
> CP/CPS also promises that BR supersedes this document.”

To put it mildly, I'm not a fan of "our CPS says X but we promise to follow
the BRs instead".  The list of "Bad" items you enumerated, which were all in
the CPS and were fixed up (presumably) as a result of someone external
(possibly you?) going through the CPS and saying "that's not compliant, and
that's not compliant" shows the benefit of explicitly describing practices
in the CPS, rather than just pointing at the BRs and saying "we do that".

Given that we've just recently had an incident caused by a CA's
misunderstanding of the BRs, anything which increases the chances of
identifying a CA's misunderstanding early (by, for example, explicitly
describing their practices in their CPS) would seem like a good thing.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

[Wayne Thayer via dev-security-policy]

Nick - I expect an emSign representative to respond to all of your
questions, but their information request indicates that they have been
operating the Indian Government Root for more than 10 years and have issued
over 35 million certificates:
https://bug1442337.bmoattachments.org/attachment.cgi?id=8955223

- Wayne

On Thu, Oct 11, 2018 at 2:07 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, 11 Oct 2018 13:06:46 -0700
> Wayne Thayer via dev-security-policy
>  wrote:
>
> > This request is for inclusion of these four emSign roots operated by
> > eMudhra in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1442337
>
> I would like to read more about eMudhra / emSign.
>
> I have never heard of this entity before, perhaps because they're
> Indian (if I understand correctly) but perhaps because they're just
> entirely new to this business.
>
> Of course just being new isn't inherently disqualifying, but it'd be
> good to understand things like:
>
> - Who (human individuals) is behind this outfit, are there people we've
> dealt with before in any key roles? (For example I hope we can agree
> that individuals from previously distrusted CAs as leadership would
> be a potential red flag) Are there people involved who've done this or
> something similar before?
>
> - Does this entity or a legally related entity already operate a
>   business in this space that has a record we can look at such as:
>   Indian RA for another Certificate Authority, CA in another PKI, or
>   more distantly somewhat similar businesses such as making identity
>   documents, or payment card systems.
>
> - How did they come to decide to set up a new root CA for the Web PKI?
>
> Running a trustworthy CA is pretty hard, so I am at least a little bit
> sceptical of the idea that people I've never hard of can wake up one
> morning and decide "Hey let's run a CA" and do a good job, whether in
> India, Indianapolis or Israel.
> ___
> 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

Re: Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

[Nick Lamb via dev-security-policy]

On Thu, 11 Oct 2018 13:06:46 -0700
Wayne Thayer via dev-security-policy
 wrote:

> This request is for inclusion of these four emSign roots operated by
> eMudhra in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1442337

I would like to read more about eMudhra / emSign.

I have never heard of this entity before, perhaps because they're
Indian (if I understand correctly) but perhaps because they're just
entirely new to this business.

Of course just being new isn't inherently disqualifying, but it'd be
good to understand things like:

- Who (human individuals) is behind this outfit, are there people we've
dealt with before in any key roles? (For example I hope we can agree
that individuals from previously distrusted CAs as leadership would
be a potential red flag) Are there people involved who've done this or
something similar before?

- Does this entity or a legally related entity already operate a
  business in this space that has a record we can look at such as:
  Indian RA for another Certificate Authority, CA in another PKI, or
  more distantly somewhat similar businesses such as making identity
  documents, or payment card systems.

- How did they come to decide to set up a new root CA for the Web PKI?

Running a trustworthy CA is pretty hard, so I am at least a little bit
sceptical of the idea that people I've never hard of can wake up one
morning and decide "Hey let's run a CA" and do a good job, whether in
India, Indianapolis or Israel.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Request to Include emSign Root CA - G1, emSign Root CA - G3, emSign Root CA - C1, and emSign Root CA - C3

[Wayne Thayer via dev-security-policy]

This request is for inclusion of these four emSign roots operated by
eMudhra in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1442337

* BR Self Assessment is here:
https://bug1442337.bmoattachments.org/attachment.cgi?id=8955225

* Summary of Information Gathered and Verified:
https://bug1442337.bmoattachments.org/attachment.cgi?id=9006698

* Root Certificate Download URL: https://repository.emsign.com/

* CP/CPS: https://repository.emsign.com/cps/CP-CPS-v1.04.pdf

* This request is to include the roots with the email and websites trust
bits enabled and with EV treatment.

* EV Policy OID: 2.23.140.1.1

* Test Websites
https://testevg1.emSign.com
https://testevg1e.emsign.com
https://testevg1r.emsign.com
https://testevg3.emSign.com
https://testevg3e.emsign.com
https://testevg3r.emsign.com
https://testevc1.emSign.com
https://testevc1e.emsign.com
https://testevc1r.emsign.com
https://testevc3.emSign.com
https://testevc3e.emsign.com
https://testevc3r.emsign.com

* CRL URLs:
http://crl.emsign.com?RootCAG1.crl
http://crl.emsign.com?RootCAG3.crl
http://crl.emsign.com?RootCAC1.crl
http://crl.emsign.com?RootCAC3.crl

* OCSP URL: http://ocsp.emsign.com

* Audit: Point-in-time audits were performed by BDO Malaysia according to
the WebTrust for CA, BR, and EV audit criteria.
WebTrust:
https://repository.emsign.com/downloads/auditreports/1-A-CA_opt.pdf
BR: https://repository.emsign.com/downloads/auditreports/2-A-SSL_opt.pdf
EV: https://repository.emsign.com/downloads/auditreports/3-A-EVSSL_opt.pdf

emSign expects to receive period-of-time audit reports covering February to
September 2018 in the next week. I request that an emSign representative
post links to those reports to this thread when they are available.

I’ve reviewed the CPS, BR Self Assessment, and related information for
inclusion of the four emSign roots that is being tracked in this bug and
have the following comments:

==Good==
* Roots were signed earlier this year and a RKGC report was provided [1].
* CPS section 1.4.2 forbids the use of emSign certificates for MITM.

==Meh==
* The CPS allows “external issuing CAs” but does not clearly state that the
requirements of BR section 1.3.2 will be met. emSign made the following
comment in response to this concern: “In the CP/CPS, there is reasonable
definition for both External Issuing CAs and External RAs. Section 1.1 of
CP/CPS also promises that BR supersedes this document.”
* It is not clear from emSign’s response in their application if they have
implemented pre-issuance linting: “Certificate issuance of emSign goes
through stringent checks, and application has validated controls to meet
the BR and RFC requirements for standards. emSign continues to implement
additional tools (as recommended) in order to enhance the pre-issuance
checks.”
* CPS section 3.2.7 clearly defines data reuse requirements for certificate
renewal. CPS section 3.2.8 implied by omission that re-keying could be done
without revalidation of information even if it was more than 825 days old.
This has been addressed in the current version of the CPS.

==Bad==
* Version 1.03 of the CPS allowed emSign to violate the BR requirements for
CAA validation. Section 4.2.4 stated: “If a CAA record exists and does not
list emSign PKI based Issuing CAs as an authorized CA, Issuing CA shall
verify that the applicant has authorized issuing CA to issue, despite
existence of CAA record.” This sentence has been removed from the current
CPS.
* One of the domain validation methods in CPS section 10.1 was not
specified in enough detail to allow a reader to determine if it meets BR
requirements: “Relying on publicly available records from the Domain Name
Registrar, such as WHOIS or other DNS record information.” This has been
improved in the current version of the CPS, however I would prefer to see a
more detailed description of each domain validation methods with references
to the BR method numbers.
* CPS section 10.6 described “Device Certificates” as “Includes TLS/SSL
Certificates for internal use”, then went on to omit any description of
domain validation procedures. If these TLS certificates chain to an
included root as would be implied by including them in this CPS, then they
must not allow internal names and must conform to BR domain verification
rules. The reference to “TLS/SSL Certificates for internal use” was removed
from the current version of the CPS.
* Mozilla policy 2.2(2) requires the CPS to describe how email address
validation is performed for emailProtection (S/MIME) certificates. The
statement “or any other reliable means” in section 10.7 does not meet this
requirement. emSign improved this description in the latest version of the
CPS, but the “or any other reliable means” language remains.
* Mozilla policy 2.2(4)  requires the CPS to describe how IP address
validation is performed for TLS certificates. The statement “or any other
equivalent procedure, which proves the applicant’s right to use the IP”
that was in sections 10.1-10.3 did 

Re: Violation report - Comodo CA certificates revocation delays

[Wayne Thayer via dev-security-policy]

I just poked Comodo in the bug -
https://bugzilla.mozilla.org/show_bug.cgi?id=1492006

CT Logs are designed such that certificates cannot be removed from them.
The evidence will not disappear once the certificates expire.

On Wed, Oct 10, 2018 at 5:26 PM please please 
wrote:

> Any update behind the scenes about this issue? I've noticed that the soft
> limit to fill an Incident Report expired more than a week ago, and I'm
> starting to be a bit worried that some of the evidence in the CT logs might
> disappear if the investigation is not completed before December 6th, the
> earliest expiration date among the affected certificates.
>
> Guillaume Fortin-Debigaré
> --
> *From:* please please 
> *Sent:* September 17, 2018 23:39
> *To:* Wayne Thayer
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
>
> Good to know, and thank you very much for following up on this!
>
> Small update by the way: I finally received a reply from Comodo CA
> confirming their 2nd wave of revocations a few hours ago, on September 17
> at 16:55 UTC to be exact. Strangely, it was in response to an email where I
> informed them that I had already noticed they fully completed my revocation
> request. I don't think it's a relevant detail but I wanted to mention it to
> avoid any potential confusion.
>
> Guillaume Fortin-Debigaré
>
> --
> *From:* Wayne Thayer 
> *Sent:* September 17, 2018 20:09
> *To:* pleaseiwantt...@hotmail.com
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
>
> I have created a bug and requested a response from Comodo:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> As noted, there are no specific requirements regarding how CAs validate
> revocation requests in the BRs. Every CA may do this however they choose,
> so I don't believe there is any action required in regard to DigiCert's
> response to their problem report.
>
> - Wayne
>
> On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> Hello, I am the domain owner of debigare.com. I would like to make you
> aware that Comodo CA took more than 5 days to revoke certificates they had
> signed for my domain and subdomains after requesting them to do through
> their sslabuse email address, past the 24 hours maximum mentioned in the
> Baseline Requirements as stipulated in section 4.9.1.1.
>
> For context, I was previously using Cloudflare's Universal SSL feature,
> but disabling it did not revoke the old certificates that had not yet
> expired, but simply removed them from its system, and some of the
> certificates were still valid for more than 6 months.
>
> I first attempted to contact Cloudflare's support to ask them to revoke
> the certificates themselves on September 6 at 7:43 UTC. This only led to
> irrelevant responses and confused customer support agents that had no idea
> what I was talking about, and this appeared to go nowhere. I eventually got
> a response from them on September 11 at 5:53 UTC that they would request
> CAs to perform the revocation, but that was after I did so myself, and I
> never got a status report back afterwards.
>
> There were two CAs affected by this issue. The vast majority of
> certificates were signed by Comodo CA, and the rest by DigiCert. I did not
> run into any issues with DigiCert (they in fact proactively checked with
> Cloudflare my claim and revoked the certificates before I even had the
> chance to attempt their domain ownership challenge), but Comodo CA was
> another story entirely.
>
> My first request to Comodo CA to revoke the certificates for debigare.com
> and all of its subdomains was on September 8 at 4:37 UTC. I did not get a
> reply until September 9 at 15:53 UTC stating that the certificates have
> been revoked. Not only was this past the 24 hours requirement, but it was
> also false, as only the most recent certificates had been revoked, not all
> of them. I mentioned to them their mistake on September 10 at 5:55 UTC with
> a full list of affected certificates just in case my initial request was
> unclear to them, and never got a reply back. I did, however, notice that
> the certificates eventually got revoked on September 13 at 16:04 UTC
> according to their Certificate Transparency logs, a fact that I only
> discovered on September 15. Assuming the log is correct, that would be a
> delay of more than 3 days after notifying them of the incomplete
> revocation, more than 5 days after my initial request to them, and more
> than a week until I finally noticed the problem was fixed. It's also worth
> noting that throughout this entire series of events, Comodo CA never
> requested proof of domain ownership beyond the evidence I initially
> provided, so that cannot explain the delays.
>
> One detail that I'm not sure about is why my initial evidence for domain
> ownership was apparently sufficient for 

Re: Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

[Wayne Thayer via dev-security-policy]

Thank you for this report Fotis.

On Thu, Oct 11, 2018 at 6:13 AM Fotis Loukos via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Summary
> ---
>
> A number of Qualified Web Authentication Certificates have been issued
> with incorrect qcStatements encoding. A small survey displays that all
> certificates issued by a specific SubCA are affected by this issue
> (https://crt.sh/?CN=%25=1481). The CA has been notified about
> this, but more than a week has passed and it has not yet provided any
> feedback, while it continues to issue such malformed certificates (e.g.
> https://crt.sh/?id=816495298).
>
> Technical details
> -
>
> According to ETSI EN 319 412-5 (Electronic Signature and Infrastructure
> (ESI); Certificate Profiles; Part 5: QCStatements) section 4.2.3
> (QCStatement claiming that the certificate is a EU qualified certificate
> of a particular type), the QCStatement QcType with OID
> id-etsi-qcs-QcType (0.4.0.1862.1.6) declares that a certificate has been
> issued for a particular purpose (e-sign, e-seal, qualified web
> authentication certificate). Every certificate containing this
> QCStatement must have a SEQUENCE OF OBJECT IDENTIFIER which declares the
> purpose, e.g. id-etsi-qct-web (0.4.0.1862.1.6.3).
> T-Systems International GmbH has failed to follow this specification,
> and instead issues certificates having id-etsi-qct-web as a QCStatement.
> Such a certificate can be found at https://crt.sh/?asn1=795148644. You
> can compare this with https://crt.sh/?asn1=844599393 which has the
> QcType QCStatement correctly encoded.
>
> Disclosure to CA timeline
> -
>
> - 2 October 2018: First notification to the CA, with a detailed
> description of the issue.
> - 2 October 2018: Reply by a CA representative that they will look at it.
> - 8 October 2018: Second notification and request for feedback.
>
> No further communication has taken place.
>
> Impact to WebPKI
> 
>
> Two issues can be identified.
>
> The first issue is the incorrect encoding of the QCStatement. My
> assessment is that this problem does not affect the WebPKI, since as far
> as I can tell, no browsers decode or utilize the QCStatements extension.
>
> The second issue is the failure of the CA to identify the problem, reply
> in time, possibly revoke the problematic certificates and at least
> momentarily pause the issuance of new certificates until the issue is
> resolved. I consider this a serious issue that displays problematic
> practices within the CA.
>
> I share your concern for the CA's responsiveness, but I'm not seeing
anything that would make this a violation of the BRs or Mozilla's policies.

Regards,
> Fotis
>
> --
> Fotis Loukos, PhD
> Director of Security Architecture
> SSL Corp
> e: fot...@ssl.com
> w: https://www.ssl.com
>
>
___
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

[Tim Hollebeek via dev-security-policy]

I think "Not applicable" would be superior to "No stipulation", when 
appropriate.

"3.2.2.5. No IP address certificates are issued under this CPS." is even 
clearer.

I haven't looked into the implications of this, but perhaps it would be worth 
considering not allowing "No stipulation" in CPSs for sections that are not
marked "No stipulation" in the Baseline Requirements.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Wednesday, October 10, 2018 6:09 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Jakob Bohm 
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS
> 
> On 09/10/2018 23:15, Wayne Thayer wrote:
> > On Tue, Oct 9, 2018 at 12:48 PM Kathleen Wilson via
> > dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> >
> >> Oh, so rather than trying to define what "No Stipulation" means and
> >> when it can be used, we could take a different approach -- list the
> >> sections that cannot contain "No Stipulation" in the CPS.
> >>
> > This approach implies that we are adopting the RFC 3647 definition of
> > "no stipulation" meaning "we can do whatever we want", not the meaning
> > of "we don't do this" that I believe is intended in the examples your
> > provided. If we take this approach, we should specify those section
> > that **must be
> > present** and cannot contain "no stipulation" (or similar permissive
> > language). Omitting a section defined in RFC 3647 is equivalent to "no
> > stipulation".
> >
> 
> In formulating Mozilla Policy one should also consider the case that a section
> is rendered inapplicable by the contents of another section.
> 
> For example if another CP/CPS section clearly states that the certificates 
> will
> not contain IP addresses as names (alternative or otherwise), then it would
> be OK to not state how IP addresses are validated.  (Such a section might for
> example state that certificates only contain DNS names).
> 
> As second example, if another CP/CPS section enumerates the validation
> methods used, then it would be OK to omit sections about methods not in
> that enumeration.
> 
> As a third example, the parent section of the section listing BR methods
> could state (in various ways) that only the methods explicitly listed will be
> used.  This particular notation could avoid a CP/CPS change to a "This
> method is not used" section when the corresponding section in the BR is
> changed, added or removed.
> 
> >
> >> On 10/9/18 12:31 PM, Brown, Wendy (10421) wrote:
> >>> Tim  -
> >>>
> >>> I think that statement leaves out the next paragraph of RFC3647:
> >>> In a CP, it is possible to leave certain components, subcomponents,
> >> and/or elements unspecified, and to stipulate that the required
> >> information will be indicated in a policy qualifier, or the document
> >> to which a policy qualifier points. Such CPs can be considered
> >> parameterized definitions. The set of provisions should reference or
> >> define the required policy qualifier types and should specify any 
> >> applicable
> default values.
> >>>
> >>> I think normally the policy qualifier points to a CPS, but it might
> >>> be
> >> some other document.
> >>> But in any case if both CP & CPS say "No stipulation" in regards to
> >> something that Mozilla cares about like what validation methods are
> >> supported for TLS certificates, then it is very hard to evaluate that
> >> set of "disclosed business practices" to determine if the CA operates
> >> in accord with the BRs or Mozilla's policy.
> >>> I think there may be some sections of a CP/CPS that are less
> >>> critical,
> >> but in terms of any section that is critical to the evaluation for
> >> inclusion in a particular trust store, I would expect one of the 2
> >> documents to clearly state the operational practices of the CA rather
> >> than just stating "No Stipulation" in both CP & CPS, unless the
> >> Policy Qualifier in issued certificates points to some other document
> >> that contains that information.
> >>>
> >>> Again - just my personal opinion.
> >>>
> 
> 
> 
> Enjoy
> 
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.
> https://clicktime.symantec.com/a/1/sXnCWBuQE3OxwGzDGFCP8tz2qr4y8b
> NKgbC6-
> _XfwpE=?d=Z2HQ1P_v8531y6J8lUlVsUTcmCX72dez2n3uy6rBVqj3AP_W9Le5
> Kck3YIgBpWiS77d8jWkRS0b6l9KDqFwcKEocqyvVnN5uK-qbUnOkjeAK5nOY-
> I07AC1KoUfhN33_MJaNeohcavrTshCIAAtrsPn_ccAchU2O65lWqwDaHUoHRh
> 9gIYPwwxf7tCdkXlf5pf2-RTSRUapCGMR5i-
> D5rFzE5bLaRqyIJQawRpDBOC8lwAgcAIYySICtdAPtmTtxZaS1ekVbuYxfKKAqnD
> QXB4SuFx0Pm6w9JPnU0xYppl0EUNTCMyfc9XtS_ZVRv5C30dxjSrwQjQ4azrub
> pnWxwa2bSJTbuMGd25gNskRQAmSpLbSupgWEe7g2WWrxkA0nnmE8J4ksZu
> JonRs5qSCPxAduJkwssCKkmmZatvuGPimdKnfVibZ07vgopAqoQ7ZmszJyA1jt3
> Wv4weiQ=https%3A%2F%2Fwww.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 

Incorrect qcStatements encoding at a number of Qualified Web Authentication Certificates (QWACs)

[Fotis Loukos via dev-security-policy]

Summary
---

A number of Qualified Web Authentication Certificates have been issued
with incorrect qcStatements encoding. A small survey displays that all
certificates issued by a specific SubCA are affected by this issue
(https://crt.sh/?CN=%25=1481). The CA has been notified about
this, but more than a week has passed and it has not yet provided any
feedback, while it continues to issue such malformed certificates (e.g.
https://crt.sh/?id=816495298).

Technical details
-

According to ETSI EN 319 412-5 (Electronic Signature and Infrastructure
(ESI); Certificate Profiles; Part 5: QCStatements) section 4.2.3
(QCStatement claiming that the certificate is a EU qualified certificate
of a particular type), the QCStatement QcType with OID
id-etsi-qcs-QcType (0.4.0.1862.1.6) declares that a certificate has been
issued for a particular purpose (e-sign, e-seal, qualified web
authentication certificate). Every certificate containing this
QCStatement must have a SEQUENCE OF OBJECT IDENTIFIER which declares the
purpose, e.g. id-etsi-qct-web (0.4.0.1862.1.6.3).
T-Systems International GmbH has failed to follow this specification,
and instead issues certificates having id-etsi-qct-web as a QCStatement.
Such a certificate can be found at https://crt.sh/?asn1=795148644. You
can compare this with https://crt.sh/?asn1=844599393 which has the
QcType QCStatement correctly encoded.

Disclosure to CA timeline
-

- 2 October 2018: First notification to the CA, with a detailed
description of the issue.
- 2 October 2018: Reply by a CA representative that they will look at it.
- 8 October 2018: Second notification and request for feedback.

No further communication has taken place.

Impact to WebPKI


Two issues can be identified.

The first issue is the incorrect encoding of the QCStatement. My
assessment is that this problem does not affect the WebPKI, since as far
as I can tell, no browsers decode or utilize the QCStatements extension.

The second issue is the failure of the CA to identify the problem, reply
in time, possibly revoke the problematic certificates and at least
momentarily pause the issuance of new certificates until the issue is
resolved. I consider this a serious issue that displays problematic
practices within the CA.

Regards,
Fotis

-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Government of Spain FNMT: OU exceeds 64 characters. Incident Report

[JMT via dev-security-policy]

Good morning,

Government of Spain-Fábrica Nacional de Moneda y Timbre (FNMT) publication in  
m.d.s.p forum  of the incident report uploaded to bugzilla in response to bug 
reported by Wayne Thayer, https://bugzilla.mozilla.org/show_bug.cgi?id=1495507, 
Government of Spain FNMT: OU exceeds 64 characters 

Kind regards,

__

Hello Wayne, I´ll try to answer the questions of incident report.

1.  How your CA first became aware of the problem (e.g. via a problem 
report submitted to your Problem Reporting Mechanism, a discussion in 
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
time and date.
On 01/10/2018 20:30 (CEST) a message from Wayne Thayer was received at 
incidents report email account.

2.  A timeline of the actions your CA took in response. A timeline is a 
date-and-time-stamped sequence of all relevant events. This may include events 
before the incident was reported, such as when a particular requirement became 
applicable, or a document changed, or a bug was introduced, or an audit was 
done.

On 02/10/2018 an analysis of the subject was started. It was confirmed that 
there were some certificates with an ou field that exceeds the length of 64 
bytes.
Investigation efforts were continued to deepen on this subject. We have 
discovered another affected certificates by this issue. All of them are 
certificates of Spanish Public Bodies whose official 
(organization/organizational unit) names exceeds the length of 64 bytes.
On 03/10/2018 13:00 (CEST) the Management Committee of TSP met. The Committee 
examined the available information and decided:
- To replace affected certificates
- To develop automatic validations to ensure such issuance will not be repeated 
in the future.
- To include this rule in automatic and periodic controls over issued 
certificates

On 04/10/2018 we have started to contact with affected entities in order to 
coordinate certificate substitution

3.  Whether your CA has stopped, or has not yet stopped, issuing 
certificates with the problem. A statement that you have will be considered a 
pledge to the community; a statement that you have not requires an explanation.

We have stopped issuing certificates with this problem.

4.  A summary of the problematic certificates. For each problem: number of 
certs, and the date the first and last certs with that problem were issued.
Issue o/ou > 64 characters:
- Number of certs: 103 affected certificates (2 sub CAS)
- Date of first certificate: December 2014
- Date of last certificate: 27/09/2018
All of them are certificates of Spanish Public Bodies whose official 
(organization/organizational unit) names exceeds the length of 64 characters.

5.  The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is logged to CT 
and then list the fingerprints or crt.sh IDs, either in the report or as an 
attached spreadsheet, with one list per distinct problem.

Pending of update to show all certificates. It must be taken into account 
that “older” certificates are not logged to CT
https://crt.sh/?cablint=539=1488=cablint,zlint,x509lint=2014-01-01

https://crt.sh/?cablint=539=401=cablint,zlint,x509lint=2014-01-01

6.  Explanation about how and why the mistakes were made or bugs 
introduced, and how they avoided detection until now.
Length of o/ou fields were not controlled till now.
Because of an unfortunate misunderstanding in comprehension and interpretation 
of information of rfcs 5280/6818, X.500/520, some public mail threads 
(CABForum, ietf, etc) and practices of another CAS, we believed that this was a 
“de facto” authorized practice by the community. Therefore, we did not develop 
any automatic validation.

7.  List of steps your CA is taking to resolve the situation and ensure 
such issuance will not be repeated in the future, accompanied with a timeline 
of when your CA expects to accomplish these things.

- Contact with involved entities has started. We are working with each of them 
to replace every affected certificate by a new one.
- We are developing an automated validation control (software) to ensure it 
will not be repeated. In the meanwhile, registration officers have been ordered 
to perform a manual check before the approval of the issuing of the certificate.
- In addition, we will include a new rule in automatic and periodic controls 
over issued certificates to ensure that new measures are working (maybe based 
on certlint/cablint utils)


We will update the information of this incident periodically

--
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy