Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[Tom via dev-security-policy]

Le 15/03/2018 à 20:04, Wayne Thayer a écrit :

This incident, and the resulting action to "integrate GlobalSign's certlint
and/or zlint into our existing cert-checker pipeline" has been documented
in bug 1446080 [1]

This is further proof that pre-issuance TBS certificate linting (either by
incorporating existing tools or using a comprehensive set of rules) is a
best practice that prevents misissuance. I don't understand why all CA's
aren't doing this.

- Wayne

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



Should another bug be opened for the certificate issued by IdenTrust 
with apparently the same encoding problem?


https://crt.sh/?id=8373036=cablint,x509lint

Does Mozilla expects the revocation of such certificates?

https://groups.google.com/d/msg/mozilla.dev.security.policy/wqySoetqUFM/l46gmX0hAwAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[Wayne Thayer via dev-security-policy]

This incident, and the resulting action to "integrate GlobalSign's certlint
and/or zlint into our existing cert-checker pipeline" has been documented
in bug 1446080 [1]

This is further proof that pre-issuance TBS certificate linting (either by
incorporating existing tools or using a comprehensive set of rules) is a
best practice that prevents misissuance. I don't understand why all CA's
aren't doing this.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1446080
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[Wayne Thayer via dev-security-policy]

On Thu, Mar 15, 2018 at 12:22 PM, Tom via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Should another bug be opened for the certificate issued by IdenTrust with
> apparently the same encoding problem?
>
> Yes - this is bug 1446121 (
https://bugzilla.mozilla.org/show_bug.cgi?id=1446121)

https://crt.sh/?id=8373036=cablint,x509lint
>

Does Mozilla expects the revocation of such certificates?
>
> Yes, within 24 hours per BR 4.9.1.1 (9) "The CA is made aware that the
Certificate was not issued in accordance with these Requirements or the
CA’s Certificate Policy or Certification Practice Statement;"

Mozilla requires adherence to the BRs, and the BRs require CAs to comply
with RFC 5280.

https://groups.google.com/d/msg/mozilla.dev.security.policy/
> wqySoetqUFM/l46gmX0hAwAJ
>
> - Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Wayne Thayer via dev-security-policy]

I think this discussion has made it clear that the request for inclusion of
the TunRootCA2 root should be denied.

CAs inherently must be trusted, and trust must be earned. A CA can't simply
fix one problem after another as we find them during the inclusion process
and expect to be rewarded for their reactive efforts, nor can they ignore
program requirements until the time comes to get their inclusion request
approved. Recurrences of the same issue that the CA claimed to have fixed
are especially damaging.

As Ryan mentioned, section 7.1 of the Root Store Policy states that "We
will determine which CA certificates are included in Mozilla's root program
based on the benefits and risks of such inclusion to typical users of our
products." While I believe the decision to deny this request is fully
supported by that policy statement, I would be interested to know if anyone
thinks there are ways we could make our expectations clearer in this regard.

Regarding next steps, the Tunisian Government is welcome to submit a new
root (using a newly generated key pair) for inclusion. The current bug may
be reopened and used for the new request, but it will still need to go
through the entire process. The only real "shortcut" in the inclusion
process - as has been demonstrated by a few CAs recently who completed the
process in 9-18 months) - is to have all the requirements fully met before
the request is reviewed. Tests that are performed during the information
verification process are documented [1], and every previous inclusion
request is publicly accessible in Bugzilla and archives of this list, so
this really shouldn't be as difficult as it seems to be.

I agree with the comments Hans made on the desire to rapidly move through
the process with the new request. Establishing confidence in a CA takes
time, and attempts to move too quickly to regain trust can be extremely
counterproductive (e.g. StartCom).

Regarding the choice of auditor, Mozilla has not disqualified LSTI and so
will not require a different auditor to be selected if/when a new root is
submitted. However, given the concerns that have been raised with the
current audits, choosing a different auditor may help to gain the
confidence of the community in the new root and in the Tunisian Government
CA.

- Wayne

[1] https://wiki.mozilla.org/CA:TestErrors

On Thu, Mar 15, 2018 at 5:44 AM, okaphone.elektronika--- via
dev-security-policy  wrote:

> On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com  wrote:
> > Dear Wayne,
> > Based on the long discussion regarding our request, I would appreciate
> having your opinion on the following:
> > Move to a new root based on EJBCA (Enterprise License) and conduct a new
> audit with a new auditor as required by Mozilla and the BR.
> > We are ready and we do commit to do these steps in 6 months. As we hope
> that you would accept to resume the inclusion process from this point.
> > We are looking forward to hearing from you.
> >
> > Syrine.
>
> Do consider that it only makes sense to start with a new root (and do the
> required audits etc.) when you are sure that all problems have been fixed,
> in such a way that they (and others like them) will not happen again.
>
> Because if that isn't the case, the new root will soon be as useless as
> trust-anchor as the old one. The fastest way forward is probably to not try
> to do it quickly.
>
> CU Hans
> ___
> 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

Mis-issuance of certificate with https in CN/SAN

[Ben Wilson via dev-security-policy]

This mis-issuance incident was reported by Cybertrust Japan (CTJ), an 
intermediate CA of DigiCert.  
(https://bugzilla.mozilla.org/show_bug.cgi?id=1445857)

Here's the incident report:

1.How your CA first became aware of the problem (e.g. via a problem report 
submitted to your Problem Reporting Mechanism, via a discussion in 
mozilla.dev.security.policy, or via a Bugzilla bug), and the date.

CTJ found a misissued certificate through its regular quality-control checking 
using cablint on cert.sh.
https://crt.sh/?id=353098570=cablint

2.A timeline of the actions your CA took in response.

A.  Mar 12, 2018 13:02:22 (JST) - The certificate was issued
B.  Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check 
on cert.sh
C.  Mar 13, 2018 11:00 (JST) - Contacted the customer
D.  Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
E.  Mar 14, 2018 - patched and tested issuance system

 3.Confirmation that your CA has stopped issuing TLS/SSL certificates with 
the problem.

CTJ patched its system to reject the problematic request on Mar 14.

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.

Number of the affected certificate is one (1).  CTJ scanned all certificates 
issued in the past and only found the one reported above.

 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.

Please see https://crt.sh/?id=353098570=cablint

6.Explanation about how and why the mistakes were made or bugs introduced, 
and how they avoided detection until now.

The bug was not previously found by CTJ QA. The affected certificate was issued 
through an enterprise RA system. CTJ's front-end system rejects incorrect FQDN 
if request is for additional SAN(s) in certificate.  However, this checking 
function was missed for the CN.

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.

A. CTJ scanned already-issued certificates to see if they contained the 
incorrect string in the FQDN and to investigate if any additional problematic 
certificates existed.
B. CTJ patched its system on Mar 14.

Ben Wilson, JD, CISA, CISSP
DigiCert VP Compliance


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

Re: Mis-issuance of certificate with https in CN/SAN

[Jakob Bohm via dev-security-policy]

On 16/03/2018 05:28, Ben Wilson wrote:

This mis-issuance incident was reported by Cybertrust Japan (CTJ), an 
intermediate CA of DigiCert.  
(https://bugzilla.mozilla.org/show_bug.cgi?id=1445857)

Here's the incident report:

1.How your CA first became aware of the problem (e.g. via a problem report 
submitted to your Problem Reporting Mechanism, via a discussion in 
mozilla.dev.security.policy, or via a Bugzilla bug), and the date.

CTJ found a misissued certificate through its regular quality-control checking 
using cablint on cert.sh.
https://crt.sh/?id=353098570=cablint

2.A timeline of the actions your CA took in response.

A.  Mar 12, 2018 13:02:22 (JST) - The certificate was issued
B.  Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check 
on cert.sh
C.  Mar 13, 2018 11:00 (JST) - Contacted the customer
D.  Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
E.  Mar 14, 2018 - patched and tested issuance system

  3.Confirmation that your CA has stopped issuing TLS/SSL certificates with 
the problem.

CTJ patched its system to reject the problematic request on Mar 14.

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.

Number of the affected certificate is one (1).  CTJ scanned all certificates 
issued in the past and only found the one reported above.

  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.

Please see https://crt.sh/?id=353098570=cablint



Note: This is the CT precertificate.

Note 2: According to crt.sh, the OCSP response for this precertificate
is not correct.  (error message: "OCSP response contains bad number of
certificates").


6.Explanation about how and why the mistakes were made or bugs introduced, 
and how they avoided detection until now.

The bug was not previously found by CTJ QA. The affected certificate was issued 
through an enterprise RA system. CTJ's front-end system rejects incorrect FQDN 
if request is for additional SAN(s) in certificate.  However, this checking 
function was missed for the CN.

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.

A. CTJ scanned already-issued certificates to see if they contained the 
incorrect string in the FQDN and to investigate if any additional problematic 
certificates existed.
B. CTJ patched its system on Mar 14.

Ben Wilson, JD, CISA, CISSP
DigiCert VP Compliance





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

Re: TunRootCA2 root inclusion request

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com  wrote:
> Dear Wayne,
> Based on the long discussion regarding our request, I would appreciate having 
> your opinion on the following:
> Move to a new root based on EJBCA (Enterprise License) and conduct a new 
> audit with a new auditor as required by Mozilla and the BR.
> We are ready and we do commit to do these steps in 6 months. As we hope that 
> you would accept to resume the inclusion process from this point.
> We are looking forward to hearing from you.
> 
> Syrine.

Do consider that it only makes sense to start with a new root (and do the 
required audits etc.) when you are sure that all problems have been fixed, in 
such a way that they (and others like them) will not happen again.

Because if that isn't the case, the new root will soon be as useless as 
trust-anchor as the old one. The fastest way forward is probably to not try to 
do it quickly.

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

Re: Subscriber Certificate Structure

[YairE via dev-security-policy]

Hi Ryan, thanks for your reply

I'm afraid I didn't make my question clear enough or that i was missing 
something in the link you sent to me

what I am asking is this:
in a subscriber certificate under subject
every CA i saw puts a CN=domain name
what I understand from the BR is that the best structure would be without the 
CN field at all
so why does everyone put it?
and when I want to build a new certificate and I want it to be perfectly 
structured should I make it with this field or without it?


- about the CertificatePolicies - it was my mistake I had "fake" certs and in 
the real ones it is OK

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

Re: Subscriber Certificate Structure

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 15, 2018 at 7:37 AM YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan, thanks for your reply
>
> I'm afraid I didn't make my question clear enough or that i was missing
> something in the link you sent to me
>
> what I am asking is this:
> in a subscriber certificate under subject
> every CA i saw puts a CN=domain name
> what I understand from the BR is that the best structure would be without
> the CN field at all
> so why does everyone put it?
> and when I want to build a new certificate and I want it to be perfectly
> structured should I make it with this field or without it?


Sounds like you missed something from the link. I encourage you to read the
discussion around that in its totality.

The answer is because it’s presently (effectively) required by the BRs,
unless the cert is OV/EV, because you need a non-empty subject in order to
work on the web, and there are only certain allowed fields you can place
stuff in for DV.

The other reason is to support software that doesn’t support the
subjectAltName, but that software is both rarer these days and demonstrably
insecure (e.g. nameConstraints)



>
>
> - about the CertificatePolicies - it was my mistake I had "fake" certs and
> in the real ones it is OK
>
> Yair
> ___
> 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