Re: Summary of Camerfirma's Compliance Issues

[Paul Kehrer via dev-security-policy]

On Tue, Jan 19, 2021 at 6:37 PM Jonathan Rudenberg via
dev-security-policy  wrote:
>
> On Tue, Jan 19, 2021, at 12:01, Andrew Ayer via dev-security-policy wrote:
> > Camerfirma was warned in 2018 that trust in their CA was in jeopardy,
> > yet compliance problems continued.  There is no reason to believe
> > Camerfirma will improve, and there are many indications that they won't.
> > Mozilla's users deserve CAs that take security more seriously than this.
> > It's time to take action to protect Mozilla's users by distrusting
> > Camerfirma.
>
> I strongly agree. The consistent pattern of documented failures and 
> insufficient remediation is deeply problematic, and reflects a level of 
> danger to Mozilla users that can only be mitigated by distrusting the CA.
>
> Jonathan

I also agree with this sentiment. Camerafirma's extensively documented
issues (https://wiki.mozilla.org/CA:Camerfirma_Issues) and the
responses in this thread reveal a CA which cannot responsibly handle
the burden of being a publicly trusted authority.

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

Re: Policy Module Ownership

[Paul Kehrer via dev-security-policy]

This is a sad loss for the community, but thank you for everything
you've done these past years!

-Paul

On Wed, Jan 22, 2020 at 6:10 AM Wayne Thayer via dev-security-policy
 wrote:
>
> I have decided to leave Mozilla, effective this Friday.
>
> I expect Mozilla to hire a replacement, but that will of course take time.
> In the interim, I will remain the CA Certificate Policy Module Owner and
> contribute to the best of my ability in a volunteer capacity.
>
> Please feel free to contact me or Kathleen with any questions or concerns.
>
> I want to take this opportunity to once again thank everyone for your
> support and contributions to this amazing community.
>
> - Wayne
> ___
> 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: Certinomis Issues

[Paul Kehrer via dev-security-policy]

A publicly trusted CA is expected to demonstrate technical competence
around validation, issuance, and security of their infrastructure. When
non-compliant issuance occurs the community should expect any well operated
CA to rapidly detect, remediate the issue, and perform a root cause
analysis focused on how to prevent that entire class of problems in the
future.

Issues E and F argue that Certinomis is technically incapable of operating
a certificate authority in compliance with the expectations we have for
such trust. In issue E we see non-compliance with a BR requirement for OCSP
responder behavior for over 4 years. Incidentally, the requirement in
question was explicitly added to the BRs in response to a major CA security
incident. Issue F lists a pattern of repeated misissuance that suggests
repeated human typos with no systemic improvement.

Similarly, issues A through D show an apparent disinterest in policy,
compliance, and communications. Issuing a cross-certification for a CA that
was in the middle of major sanctions, having repeated audit gaps, ignoring
Mozilla root store policies for years, and generally declining to engage
with the community to help resolve these issues is not the action of an
organization that understands the responsibility of being a CA.

I believe the issues highlighted by Mozilla represent, in aggregate,
extremely strong evidence that Certinomis is unfit to operate a trusted
certificate authority.

-Paul

On April 17, 2019 at 2:44:44 AM, Wayne Thayer via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

Mozilla has decided that there is sufficient concern [1] about the
activities and operations of the CA Certinomis to collect together a list
of issues. That list can be found here:
https://wiki.mozilla.org/CA/Certinomis_Issues

Note that this list may expand or contract over time as issues are
investigated further, with information either from our or our community's
investigations or from Certinomis.

We expect Certinomis to engage in a public discussion of these issues and
give their comments and viewpoint. We also hope that our community will
make comments, and perhaps provide additional information based on their
own investigations.

When commenting on these issues, please clearly state which issue you are
addressing on each occasion. The issues have been given identifying letters
and numbers to help with this.

At the end of a public discussion period between Mozilla, our community,
and Certinomis, which we hope will be no longer than a couple of weeks,
Mozilla will move to make a decision about how to respond to these
concerns, based on the picture which has then emerged.

- Wayne

[1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues
___
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: 答复: Certificate Problem Report (9WG: CFCA certificate with invalid domain)

[Paul Kehrer via dev-security-policy]

Hi Jonathan,

When something like this occurs the Mozilla community asks for an incident
report explaining how the incident occurred, what was done to remediate it,
and what procedures and technical controls have been put in place to
prevent a future recurrence of the problem. You can see documentation about
that here: https://wiki.mozilla.org/CA/Responding_To_An_Incident

I am very interested in knowing how your registration authority
infrastructure allowed an invalid (and unaudited) SAN to be issued.

(Note that I am not a Mozilla representative, merely a member of the
community who has seen many incident reports)

-Paul

On March 1, 2019 at 11:57:05 AM, 孙圣男 via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

Dear Mozilla：
This problem had been confirmed. We contacted the customer and
confirmed this certificate haven't been deployed to production system, no
damage is caused. This certificate had been revoked in March 1, 2019. We had
fixed this bug in February 27 update.

Best wishes!

Jonathan Sun
Certificate Product Manager
International Coperation Group
Tel: +86 010 80864127


-邮件原件-
发件人: Buschart, Rufus 
发送时间: 2019年2月28日 19:00
收件人: r...@cfca.com.cn
主题: Certificate Problem Report (9WG: CFCA certificate with invalid domain)

Dear PKI team at CFCA!

There is a misissued certificate
https://crt.sh/?id=1231965201=cablint,x509lint,zlin from your CA which
is not revoked yet. I think you should have a look.


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik
Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich,
Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich,
HRB 6684; WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy
>  Im Auftrag von
> michel.lebihan2000--- via dev-security-policy
> Gesendet: Mittwoch, 27. Februar 2019 08:54
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: CFCA certificate with invalid domain
>
> Hello,
>
> I noticed this certificate
> https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an
> invalid domain `mail.xinhua08.con` in SANs. This looks like a typo and
`mail.xinhua08.com` is present in other certificates. Such an issue makes me
wonder about the quality of their validation.
> ___
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Paul Kehrer via dev-security-policy]

Hi Scott,

Comments inline.

On February 25, 2019 at 4:58:00 PM, Scott Rea via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

G’day Corey,

To follow up on this thread, we have confirmed with the developers of the
platform that the approach used to include 64-bit output from a CSPRNG in
the serialNumber is to generate the required output and then test it to see
if it can be a valid serialNumber. If it is not a valid serialNumber, it is
discarded, and new value is generated. This process is repeated until the
first valid serialNumber is produced.

This process ensures that 64 bits output from a CSPRNG is used to generate
each serialNumber that gets used, and this is complaint with the BRS
Section 7.1.

This approach (assuming it is accurately described) discards exactly half
of all values, thus halving the address space. That means there are 63-bits
of entropy, so I do not agree that this process is compliant with the
baseline requirements. More generally, RFC 5280 allows up to 20 octets in
the serial number field so why are you choosing to issue on the lower bound?



I will also point out that if the returned value is a valid as a
serialNumber, it is further checked to see if that value has not been used
before, since there is obviously a minimal chance of collision in any truly
random process. In this case the serialNumber value will also be discarded
and the process repeated.

I don't believe all public CAs do collision detection because many have
chosen to implement serial generation such that collision is highly
improbable. For example, a CA may choose to generate a 160-bit value and
clamp the high bit to zero. This provides 159-bits of entropy, with a
collision probability of roughly 1 in 2 ** 79.5. Alternately, a CA might
choose to issue with 80-bits of entropy concatenated with a 64-bit
nanosecond time resolution timestamp. This provides 1 in 2 ** 40 collision
probability for any given nanosecond. As a final example, Let's Encrypt's
Boulder CA generates a 136-bit random value and prefixes it with an 8-bit
instance ID:
https://github.com/letsencrypt/boulder/blob/a9a0846ee92efa01ef6c6e107d2e69f4ddbea7c0/ca/ca.go#L511-L532

1 in 2 ** 79.5 is roughly as probable as a randomly generated number
successfully passing typical Miller-Rabin primality testing while in
reality being composite. This is not a risk we worry about when creating
new root keys.


I think it reasonable to expect that EVERY implementation of a compliant CA
software is doing this post-processing to ensure the intended serialNumber
has not already been used, and this is not something unique to EJBCA. As
such, every CA out there will have some process that requires
post-processing of whatever value is returned with a possibility to have to
repeat the process if there is a collision.



Regards,


-- 

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

Re: TunRootCA2 root inclusion request

[Paul Kehrer via dev-security-policy]

In addition to the issues Ryan has listed, during the root inclusion
process multiple issues with their OCSP responder and CRL endpoints were
observed and fixed only after the flaws were documented in the bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=1233645).

I believe any CA seeking inclusion should be capable of doing the sorts of
checks the Mozilla community performs long prior to seeking root inclusion.
Failures like this inspire no confidence in the technical acumen of the
administrators and I do not believe this root inclusion request should be
accepted.

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

Re: Google OCSP service down

[Paul Kehrer via dev-security-policy]

Thank you for this comprehensive incident report Ryan. Your team's decision
to improve the documentation around the right address for reporting is
great to see! I wonder if it might also make sense to pull the contact
information directly on https://pki.goog above the fold?

-Paul (reaperhulk)

On February 22, 2018 at 12:53:32 PM, Ryan Hurst via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

I wanted to follow up with our findings and a summary of this issue for the
community.

Bellow you will see a detail on what happened and how we resolved the
issue, hopefully this will help explain what hapened and potentially others
not encounter a similar issue.

Summary
---
January 19th, at 08:40 UTC, a code push to improve OCSP generation for a
subset of the Google operated Certificate Authorities was initiated. The
change was related to the packaging of generated OCSP responses. The first
time this change was invoked in production was January 19th at 16:40 UTC.

NOTE: The publication of new revocation information to all geographies can
take up to 6 hours to propagate. Additionally, clients and middle-boxes
commonly implement caching behavior. This results in a large window where
clients may have begun to observe the outage.

NOTE: Most modern web browsers “soft-fail” in response to OCSP server
availability issues, masking outages. Firefox, however, supports an
advanced option that allows users to opt-in to “hard-fail” behavior for
revocation checking. An unknown percentage of Firefox users enable this
setting. We believe most users who were impacted by the outage were these
Firefox users.

About 9 hours after the deployment of the change began (2018-01-20 01:36
UTC) a user on Twitter mentions that they were having problems with their
hard-fail OCSP checking configuration in Firefox when visiting Google
properties. This tweet and the few that followed during the outage period
were not noticed by any Google employees until after the incident’s
post-mortem investigation had begun.

About 1 day and 22 hours after the push was initiated (2018-01-21 15:07
UTC), a user posted a message to the mozilla.dev.security.policy mailing
list where they mention they too are having problems with their hard-fail
configuration in Firefox when visiting Google properties.

About two days after the push was initiated, a Google employee discovered
the post and opened a ticket (2018-01-21 16:10 UTC). This triggered the
remediation procedures, which began in under an hour.

The issue was resolved about 2 days and 6 hours from the time it was
introduced (2018-01-21 22:56 UTC). Once Google became aware of the issue,
it took 1 hour and 55 minutes to resolve the issue, and an additional 4
hours and 51 minutes for the fix to be completely deployed.

No customer reports regarding this issue were sent to the notification
addresses listed in Google's CPSs or on the repository websites for the
duration of the outage. This extended the duration of the outage.

Background
--
Google's OCSP Infrastructure works by generating OCSP responses in batches,
with each batch being made up of the certificates issued by an individual
CA.

In the case of GIAG2, this batch is produced in chunks of certificates
issued in the last 370 days. For each chunk, the GIAG2 CA is asked to
produce the corresponding OCSP responses, the results of which are placed
into a separate .tar file.

The issuer of GIAG2 has chosen to issue new certificates to GIAG2
periodically, as a result GIAG2 has multiple certificates. Two of these
certificates no longer have unexpired certificates associated with them. As
a result, and as expected, the CA does not produce responses for the
corresponding periods.

All .tar files produced during this process are then concatenated with the
-concatenate command in GNU tar. This produces a single .tar file
containing all of the OCSP responses for the given Certificate Authority,
then this .tar file is distributed to our global CDN infrastructure for
serving.

A change was made in how we batch these responses, specifically instead of
outputting many .tar files within a batch, a concatenation was of all tar
files was produced.

The change in question triggered an unexpected behaviour in GNU tar which
then manifested as an empty tarball. These "empty" updates ended up being
distributed to our global CDN, effectively dropping some responses, while
continuing to serve responses for other CAs.

During testing of the change, this behaviour was not detected, as the tests
did not cover the scenario in which some chunks did not contain unexpired
certificates.

Findings

- The outage only impacted sites with TLS certificates issued by the GIAG2
CA as it was the only CA that met the required pre-conditions of the bug.
- The bug that introduced this failure manifested itself as an empty
container of OCSP responses. The root cause of the issue was an unexpected
behavior of GNU tar relating to concatenating tar files.
- The 

Re: TLS everywhere has a major flaw and needs refining to the page level.

[Paul Kehrer via dev-security-policy]

Clock skew issues are not an overlooked problem. The Chrome team has
published research around this in the past (
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/owc7DJkg098/d8k0LyrgAgAJ)
that led to a plan (
https://www.chromium.org/developers/design-documents/sane-time). I believe
all of that work has landed in Chrome. I don't have a source for what
percentage of TLS errors currently seen are clock skew at this point
(although perhaps Mozilla or the Chrome team have published newer numbers),
but significant effort has been spent to solve the root issue.


-Paul (reaperhulk)

On February 15, 2018 at 10:55:33 PM, Kevin Chadwick via dev-security-policy
(dev-security-policy@lists.mozilla.org) wrote:

The cookies etc. should be SSL only. Particular pages enforced, sure.

Enforcing TLS with HSTS sitewide means that users with failed
bios/laptop batteries have to know to reset their clock or get used to
bypassing SSL warnings or use out of date browsers to access sites.
A fairly common problem, not good. Think real world, please. This hurts
the most vulnerable.

Another solution may be to remove the cert is not valid YET
restriction but that is a can of worms.

Thankyou
___
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: Public trust of VISA's CA

[Paul Kehrer via dev-security-policy]

On February 14, 2018 at 4:17:16 AM, Wayne Thayer via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

> The most recent BR audit report for the Visa eCommerce Root contains 3
qualifications: http://enroll.visaca.com/WTBR%20eComm.pdf

Does Mozilla have any guidelines or official position on what constitutes
sufficient audit issues to result in sanctions? Frankly I'm stunned that
any CA in the Mozilla root program can apparently ignore the baseline
requirements for approximately 4 years after their effective date, get an
initial BR audit with multiple qualifications, and see no penalty from this
behavior. And this is disregarding several other BR violations found in the
wild by independent researchers. I realize I'm banging the same drum as in
my other thread, but without consistent enforcement of escalating penalties
I don't believe we're teaching CAs anything other than that Mozilla will
ultimately forgive almost any transgression. Unless you catch them on a bad
day, in which case you might get distrusted entirely.

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

Re: Misissuance/non-compliance remediation timelines

[Paul Kehrer via dev-security-policy]

On February 9, 2018 at 1:24:12 AM, Wayne Thayer (wtha...@mozilla.com) wrote:

On Tue, Feb 6, 2018 at 6:03 PM, Paul Kehrer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> So, how long is too long?
>

This is the crux of the issue for me. If a CA (that really should have
stopped responding 'good' for unknown certs back in 2013) needs to select,
purchase, and deploy an entirely new OCSP system, is 5 months a really long
time? From their perspective, probably not.

I agree that from their perspective that's a short period of time. However,
I strongly believe that asking the public to bear the burden of a CA's own
incompetence is, while historically what has been done, not tenable moving
forward. In the specific case of the OCSP issues I question why we should
give CAs half a year to remediate a fault that had already been a
requirement for 4 years when it was discovered. In many ways a CA's primary
job is knowing and following the rules, so why are we giving CAs who fail
in such colossal fashion a free pass?



I don't believe there is a standard answer to this question that can apply
to a whole class of issues, but I do think we could do a better job of
communicating our expectations when a situation like this arises by making
a statement such as 'being a CA that has been granted the public's trust,
Mozilla expects problem X to be resolved in Y days'. Responsible CAs will
meet the deadline and thus distinguish themselves from CAs that simply
aren't taking the problem seriously.

If Mozilla provides a deadline and a CA misses it, what's the penalty?

I believe a graduated notion of penalties and risk mitigation would make it
easier for Mozilla to push CAs. If the only penalty is distrust then
"little" things like a slow but steady trickle of misissued certificates,
operating your OCSP responder out of compliance for 4 years, or failing to
get a BR audit for 3 years after they became required never rise to the
level of a distrust conversation. If, on the other hand, there exists a set
of penalty tiers a CA can be placed on that path relatively quickly.
Instead of a "sudden" (from the perspective of the CA or subscribers who
aren't engaged with policy discussions on mdsp) distrust thread, there is
an escalation that makes everyone aware of a CA's need to shape up.


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

Misissuance/non-compliance remediation timelines

[Paul Kehrer via dev-security-policy]

A bit over 5 months ago I reported a series of OCSP responders that were
violating BRs (section 4.9.10) by returning GOOD on unknown serial numbers.
Since that time the majority of those responder endpoints have been fixed,
but several are still non-compliant; either with little communication or
continuing assurances that it will be fixed "soon", where soon is a date
that continuously slides into the future.

At the moment Mozilla possesses very few options when it comes to punitive
action and the lesson some CAs appear to be learning is that as long as you
don't rise to PROCERT levels of malfeasance/incompetence then the maximum
penalty is censure on bugzilla and email threads. Clearly this is not a
deterrent.

So, how long is too long? At what point should a CA incur consequences (and
what form can those consequences take) for failure to remediate despite
being given such immense latitude?

As a straw man: what if we developed a set of technical constraints related
to minimizing risk associated with CAs that are deemed to be acting poorly?
For example, CAs deemed a risk would have their certificate maximum
lifetime constrained to some amount less than the BRs currently allow.
Additional penalties could include removal of EV trust indicators,
constraining trust to a limited set of domains, marking contexts as
insecure, and finally full distrust. Once a CA lands in a risk category
further misissuance would escalate their risk to the community and thus
incur additional constraints. (I'm sure the community can come up with far
better tiers than I have!)

Adding controls like this will require significant time and effort from
Mozilla, but if we want to be able to manage the significant and ongoing
volume of misissuance/non-compliance we're seeing I believe some level of
granularity is needed.

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

Re: Serial number length

[Paul Kehrer via dev-security-policy]

On December 29, 2017 at 12:27:35 PM, David E. Ross via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

On 12/28/2017 10:33 PM, Peter Bowen wrote:
> On Thu, Dec 28, 2017 at 10:24 PM, Jakob Bohm via dev-security-policy
>  wrote:
>> After looking at some real certificates both in the browser and on
crt.sh, I
>> have some followup questions on certificate serial numbers:
>>
>> 4. If the answers are yes, no, yes, why doesn't cablint flag
>> certificates with serial numbers of less than or equal to 64 bits as
>> non-compliant?
>
> I can answer #4 -- your trusty cablint maintainer has fallen behind
> and hasn't added lints for recent ballots.
>

I know this would require changing not only software but also the format
of certificates. However, why not use UUID version 1? UUIDs
(Universally Unique IDentifiers) require no central registry. UUIDs are
specified in RFC 4122.

Modern X509 uses serial number as both a source of randomness and a unique
identifier. Unfortunately, trying to solve for uniqueness doesn't absolve
you from needing quality randomness. The reason for the "at least 64-bits
of random" requirement is to add entropy to the tbsCertificate structure to
make hash collision attacks more difficult. UUIDv1 is (almost) entirely
predictable and thus not suitable for this. And if you have a good random
source you might as well just generate a long random serial which has a
vanishingly small probability of collision.



>From :
> A Version 1 UUID is a universally unique identifier that is generated
> using a timestamp and the MAC address of the computer on which it was
> generated.MAC addresses are supposed to be unique for each device.
Continuously
varying time means that time-stamps are unique to the device, not
rolling over until around the year 3400.

Yes, it is possible that the manufacturer of a device -- especially now
with so many IoT devices being developed -- might reuse a MAC address.
This problem can be overcome if certification authorities are required
to obtain confirmation from their hardware suppliers that the MAC
addresses in their devices are indeed unique.



-- 
David E. Ross


President Trump: Please stop using Twitter. We need
to hear your voice and see you talking. We need to know
when your message is really your own and not your attorney's.
___
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: Violations of Baseline Requirements 4.9.10

[Paul Kehrer via dev-security-policy]

Hi Ben,

DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação
Electrónica do Estado, C=PT

Downloading the issuer (https://crt.sh/?id=8949008) and then running:

openssl ocsp -issuer 8949008.crt -serial 101010101010101101010101010
-no_nonce -url http://ocsp.root.cartaodecidadao.pt/publico/ocsp -noverify

gives this response:

101010101010101101010101010: good
This Update: Nov 14 23:59:47 2017 GMT

So this does not appear to be resolved.


DN: C=PT, O=SCEE, CN=ECRaizEstado

The SCEE root for the Government of Portugal is now responding with
unknown/revoked statuses.


DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A.,
OU=Accredited Certification Authority, CN=MULTICERT Certification Authority
002

Download https://crt.sh/?id=8642581 and run:

openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010
-no_nonce -url http://ocsp.multicert.com/ocsp -noverify

and

openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010
-no_nonce -url http://ocsp.multicert.com/procsp -noverify

and the responses are:

101010101010101101010101010: good
This Update: Nov 15 00:03:40 2017 GMT
Next Update: Nov 15 00:03:40 2017 GMT

101010101010101101010101010: good
This Update: Nov 15 00:03:58 2017 GMT
Next Update: Nov 15 00:03:58 2017 GMT

Not fixed.


DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A.,
OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de
Certificação 001

(Issuer: https://crt.sh/?id=128496365)

openssl ocsp -issuer 128496365.crt -serial 1010101010101010101002101010
-no_nonce -noverify -url http://ocsp.multicert.com/ocsp

1010101010101010101002101010: good
This Update: Nov 15 00:15:45 2017 GMT
Next Update: Nov 15 00:15:45 2017 GMT

Also not fixed.

I believe Kathleen has opened bugzilla issues for these so it would
probably be good to copy this correspondence there as well.

-Paul

On November 15, 2017 at 6:50:43 AM, Ben Wilson (ben.wil...@digicert.com)
wrote:

Could someone re-check Multicert and SCEE? (See below.)  They have
indicated to us that they have now patched their OCSP responder systems.



DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação
Electrónica do Estado, C=PT

Example cert: https://crt.sh/?id=12729446

OCSP URI: http://ocsp.root.cartaodecidadao.pt/publico/ocsp



DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A.,
OU=Accredited Certification Authority, CN=MULTICERT Certification Authority
002

Example cert: https://crt.sh/?id=117934576

OCSP URI: http://ocsp.multicert.com/ocsp

OCSP URI: http://ocsp.multicert.com/procsp



DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A.,
OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de
Certificação 001

Example cert: https://crt.sh/?id=11653177

OCSP URI: http://ocsp.multicert.com/ocsp



DigiCert/Government of Portugal, Sistema de Certificação Electrónica do
Estado (SCEE) / Electronic Certification System of the State:



DN: C=PT, O=SCEE, CN=ECRaizEstado

Example cert: https://crt.sh/?id=8322256

OCSP URI: http://ocsp.ecee.gov.pt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Francisco Partners acquires Comodo certificate authority business

[Paul Kehrer via dev-security-policy]

On November 1, 2017 at 2:23:17 PM, westmail24--- via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

Hello,


If I understand correctly, at the time of the public discussion for new
root certificates SSL.com (RA Comodo) Mozilla concealed information about
the acquisition of SSL business of Comodo and that now the past public
discussion about new root certificates SSL.com can be considered incorrect
on this moment of time.


I don't think it's going to be a productive avenue of discussion to imply
Mozilla acted in bad faith with regard to private knowledge of an impending
sale.

If people are seriously concerned by these sorts of transactions I'd urge
them to participate in discussions around mandatory CT as that provides
technical means to document the hypothetical malfeasance they're concerned
about.

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

Re: Public trust of VISA's CA

[Paul Kehrer via dev-security-policy]

I can confirm that as of this moment the VISA OCSP responders are still
responding GOOD for non-existent certificates. VISA was originally
contacted by me on August 29 so it has now been over 21 days since initial
report.

-Paul

On September 21, 2017 at 9:32:12 PM, Gervase Markham via
dev-security-policy (dev-security-policy@lists.mozilla.org) wrote:

Additionally, 13 days ago it was reported to VISA that their OCSP
responder was misconfigured to return "good" responses for non-existent
certificates:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398261
As far as I can see, this is the case for their end-entity certificates,
not just some roots or intermediates.

Two weeks later, they have not yet provided any response.

Gerv
___
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: Violations of Baseline Requirements 4.9.10

[Paul Kehrer via dev-security-policy]

On September 9, 2017 at 2:16:38 AM, Kathleen Wilson via dev-security-policy
(dev-security-policy@lists.mozilla.org) wrote:

Bugs filed…



~

Thanks,
Kathleen


Thank you very much Kathleen! If I receive additional responses I will
update the bugs directly.

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

Re: Violations of Baseline Requirements 4.9.10

[Paul Kehrer via dev-security-policy]

I have updated the list again to note the additional responders fixed (in
this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly
less enormous I've also started removing everything but the CA's name when
I have confirmed that all the reported responders are now properly
responding to my queries.


AS Sertifitseerimiskeskuse (SK)

CCADB does not list an email address. Not CC'd.

DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA,
emailAddress=p...@sk.ee
Example cert:
https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f
OCSP URI: http://ocsp.sk.ee/CA

Autoridad de Certificacion Firmaprofesional

Email sent to i...@firmaprofesional.com

DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068
Example cert:
https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35
OCSP URI: http://ocsp.firmaprofesional.com

DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244
Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de
Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068,
CN=AC Firmaprofesional - CA1
Example cert:
https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796
OCSP URI: http://ocsp.firmaprofesional.com

DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la
Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional -
AAPP
Example cert:
https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7
OCSP URI: http://ocsp.firmaprofesional.com

CA Disig a.s. (Fixed as of 2017-08-31)

--Data removed for brevity, see older emails for more info

certSIGN (partially resolved)

Email sent to off...@certsign.ro

DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN
Enterprise CA Class 3 G2
Example cert:
https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355
OCSP URI: http://ocsp.certsign.ro
Notes: This is fixed as of 2017-08-31

DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA
Example cert:
https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c
OCSP URI: http://ocsp.certsign.ro
Notes: Per Cristian Garabet this will be resolved 2017-09-15

Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)

CCADB does not list an email address. Not CC'd.

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
Locals de Catalunya, CN=EC-AL
Example cert:
https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
Locals de Catalunya, CN=EC-AL
Example cert:
https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2   (c)03, OU=Secretaria
d'Administracio i Funcio Publica, CN=EC-SAFP
Example cert:
https://crt.sh/?q=15d3c7463f477e2627c4c9a158e429abd6bfe63101d6745560a36d1c03363d30
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Universitats i
Recerca, CN=EC-UR
Example cert:
https://crt.sh/?q=7432b4c29e1360668814ec282ad78208cd521e62b8d8d60d5084fdf8daad57cb
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Universitats i
Recerca, CN=EC-UR
Example cert:
https://crt.sh/?q=3148d57a495fd7bdf4653dfdd3d3c9d186547df42e296c4e1b6a7c679179d03f
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio,
OU=Vegeu https://www.catcert.net/verCIC-3 (c)05, OU=Universitat Rovira i
Virgili, CN=EC-URV
Example cert:
https://crt.sh/?q=caa2a1fe7756bd5e227add40c5e06808dc0a79f1e8c93e4bf982df4893b284e4
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), OU=Serveis
Publics de Certificacio, OU=Vegeu https://www.catcert.net/verarrel (c)03,
OU=Jerarquia Entitats de Certificacio Catalanes, CN=EC-ACC
Example cert:
https://crt.sh/?q=356a5f4d994e9efa7caefc491768911d65ec25977465b610e2f29aa4472631c3
OCSP URI: http://ocsp.catcert.net

DN: 

Re: Violations of Baseline Requirements 4.9.10

[Paul Kehrer via dev-security-policy]

I have updated the list below to try to capture all the information
provided in this thread about which responders have been fixed (and
verified using another random serial number), which ones have a date, and
removed the ones that are actually under technical constraint that I missed.

I have received several responses from CAs that were CC'd informing me that
they are investigating but until the issues are resolved or I have a date
for resolution I have not noted those communications below.


AS Sertifitseerimiskeskuse (SK)

CCADB does not list an email address. Not CC'd.

DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA,
emailAddress=p...@sk.ee
Example cert:
https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f
OCSP URI: http://ocsp.sk.ee/CA

Autoridad de Certificacion Firmaprofesional

Email sent to i...@firmaprofesional.com

DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068
Example cert:
https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35
OCSP URI: http://ocsp.firmaprofesional.com

DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244
Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de
Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068,
CN=AC Firmaprofesional - CA1
Example cert:
https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796
OCSP URI: http://ocsp.firmaprofesional.com

DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la
Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional -
AAPP
Example cert:
https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7
OCSP URI: http://ocsp.firmaprofesional.com

CA Disig a.s.

Email sent to tspnot...@disig.sk

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service
Example cert:
https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2
OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service
Example cert:
https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417
OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1
Example cert:
https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947
OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2
Example cert:
https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341
OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2

certSIGN

Email sent to off...@certsign.ro

DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN
Enterprise CA Class 3 G2
Example cert:
https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355
OCSP URI: http://ocsp.certsign.ro
Notes: This is fixed as of 2017-08-31

DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA
Example cert:
https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c
OCSP URI: http://ocsp.certsign.ro
Notes: Per Cristian Garabet this will be resolved 2017-09-15

Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)

CCADB does not list an email address. Not CC'd.

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
Locals de Catalunya, CN=EC-AL
Example cert:
https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
Locals de Catalunya, CN=EC-AL
Example cert:
https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2   (c)03, OU=Secretaria
d'Administracio i Funcio Publica, CN=EC-SAFP
Example cert:
https://crt.sh/?q=15d3c7463f477e2627c4c9a158e429abd6bfe63101d6745560a36d1c03363d30
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Universitats i
Recerca, CN=EC-UR
Example cert:
https://crt.sh/?q=7432b4c29e1360668814ec282ad78208cd521e62b8d8d60d5084fdf8daad57cb
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 

RE: Violations of Baseline Requirements 4.9.10

[Paul Kehrer via dev-security-policy]

On August 30, 2017 at 4:53:54 AM, Ben Wilson via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

This CA is technically constrained:



DN: C=CH, L=Zurich, O=ABB, CN=ABB Issuing CA 6





Hi Ben,

ABB Intermediate CA 3 (https://crt.sh/?id=7739892), which issued ABB
Issuing CA 6, does have a name constraints extension. Unfortunately that NC
extension does not comply with BR 7.1.5 because it fails to encode an IPv6
exclusion:

The Subordinate CA Certificate MUST also include within excludedSubtrees an
iPAddress GeneralName of 32 zero octets (covering the IPv6 address range of
::0/0)

This is an interesting edge case since the CA is partially, but not fully
constrained.

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

Re: Violations of Baseline Requirements 4.9.10

[Paul Kehrer via dev-security-policy]

Hi David,

If you use the cert at https://crt.sh/?id=1616324 as issuer (the root
itself) and run this command:

openssl ocsp -issuer 1616324.crt -serial 10101010101010111101001101
-url http://ocsp.izenpe.com -noverify

You will get back

This Update: Jun 22 11:06:43 2017 GMT
Next Update: Jun 22 11:06:43 2018 GMT

Of course, no serverAuth certificates should be issued directly off the
root, but the root is still enabled for that purpose so the responder
should respond UNAUTHORIZED here (UNAUTHORIZED instead of UNKNOWN to allow
the root to stay offline).

On August 30, 2017 at 4:42:10 PM, David Fernandez via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

Hi Paul,
can you provide what you posted, for example attaching the ocsp response. I
mean if I query for a non-existant certificate, I get the following answer:

openssl ocsp -no_cert_verify -no_signature_verify -issuer SSLEV_IZENPE.cer
-serial 0x295990755083049101712519384020072382191 -url
http://ocsp.izenpe.com

Response verify OK
0x295990755083049101712519384020072382191: revoked
This Update: Aug 30 08:36:05 2017 GMT
Next Update: Sep 1 08:36:05 2017 GMT
Reason: certificateHold
Revocation Time: Jan 1 00:00:00 1970 GMT
___
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

Violations of Baseline Requirements 4.9.10

[Paul Kehrer via dev-security-policy]

I've recently completed a scan of OCSP responders with a focus on checking
whether they are compliant with BR section 4.9.10's requirement: "Effective
1 August 2013, OCSP responders for CAs which are not Technically
Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD"
status for such certificates." This rule was put in place in the wake of
the DigiNotar incident as an additional method of ensuring the CA is aware
of all issuances in its infrastructure and has been a requirement for over
4 years now.

The scan was performed by taking the list of responders (and valid issuer
name hash/issuer key hashes) that Andrew Ayer has aggregated and making an
OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef".
This serial is extremely unlikely to have been issued legitimately.

The following OCSP responders appear to be non-compliant with the BRs (they
respond GOOD and are not listed as technically constrained by crt.sh) but
are embedded in certificates issued in paths that chain up to trusted roots
in the Mozilla store. I have grouped them by owner where possible and put
notes about whether they've been contacted:

AS Sertifitseerimiskeskuse (SK)

CCADB does not list an email address. Not CC'd.

DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA,
emailAddress=p...@sk.ee
Example cert:
https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f
OCSP URI: http://ocsp.sk.ee/CA

Autoridad de Certificacion Firmaprofesional

Email sent to i...@firmaprofesional.com

DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068
Example cert:
https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35
OCSP URI: http://ocsp.firmaprofesional.com

DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244
Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de
Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068,
CN=AC Firmaprofesional - CA1
Example cert:
https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796
OCSP URI: http://ocsp.firmaprofesional.com

DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la
Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional -
AAPP
Example cert:
https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7
OCSP URI: http://ocsp.firmaprofesional.com

CA Disig a.s.

Email sent to tspnot...@disig.sk

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service
Example cert:
https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2
OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service
Example cert:
https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417
OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1
Example cert:
https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947
OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2
Example cert:
https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341
OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2

certSIGN

Email sent to off...@certsign.ro

DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN
Enterprise CA Class 3 G2
Example cert:
https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355
OCSP URI: http://ocsp.certsign.ro

DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA
Example cert:
https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c
OCSP URI: http://ocsp.certsign.ro

Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)

CCADB does not list an email address. Not CC'd.

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
Locals de Catalunya, CN=EC-AL
Example cert:
https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
Locals de Catalunya, CN=EC-AL
Example cert:
https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2   (c)03, OU=Secretaria
d'Administracio i Funcio Publica, CN=EC-SAFP
Example cert:

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Paul Kehrer via dev-security-policy]

On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote:
> IdenTrust is fully aware of the situation and has consulted with internal and 
> external parties to ensure that our course of action is appropriate and 
> commensurate with our business practices and accommodates our customer’s 
> needs.
> When IdenTrust initially established the ACES SSL profile, it was intended to 
> apply only to US government entities.  At that time, the Organization was 
> defined as a static value of “U.S. Government” in our profiles.  Later, when 
> non-agencies applied, IdenTrust reasoned at that time that this static value 
> continued to be acceptable as these entities must identify themselves as 
> organizations that act as relying parties, accepting certificates issued 
> under the ACES program, and are in some capacity associated with the U.S. 
> Government.  We have discussed internally and taken a fresh look at this 
> decision.   As a result, IdenTrust has updated the ACES SSL profile to use 
> the applicant Organization name in the Subject DN organization field.  This 
> change will accommodate all applications for ACES SSL certificates, both U.S. 
> agencies and non-agencies.  At the same time, we have modified the OCSP 
> validation URL from HTTPS to HTTP.  
> It is important to note that all certificates that are impacted by this 
> situation have been appropriately vetted by the IdenTrust Registration team 
> according to Identity Validation requirements stated in the ACES CP, 
> therefore the need to revoke affected certificates immediately is less 
> critical.  Our key objective is to revoke all incorrect certificates as 
> quickly as possible, while minimizing the impact to our customers and 
> avoiding disruption to critical business processes.  As such, IdenTrust is 
> working directly with these customers to initiate a replacement for the 
> offending certificates.  The replacement process allows the client to use an 
> online mechanism to request a new certificate with the correct attributes and 
> immediately download the new certificate.  The replacement process also 
> automatically revokes the certificate being replaced.  This will enable our 
> clients to receive a newly vetted certificate and they will not be 
> inconvenienced by a forced revocation, which would likely adversely impact 
> their business processes. IdenTrust will ultimately force a revocation, in 
> the event that the clients do not initiate a certificate replacement in 
> response to our communications.
>  
> Thank you for the opportunity to represent our position.

Is it Identrust's contention that the revocation rules required under the 
requirements they are audited under do not apply to these certificates because 
it would inconvenience their customers? This is a clear violation of the 
baseline requirements and I'd like some clarity on why Identrust believes it's 
permissible to pick and choose what their revocation timelines will be.

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

Re: Misissued certificates

[Paul Kehrer via dev-security-policy]

On August 10, 2017 at 9:44:01 PM, Jakob Bohm via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

On 11/08/2017 00:29, Jonathan Rudenberg wrote:
>
>> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>>
>> Can anyone point out a real world X.509 framework that gets confused by
>> a redundant pathlen:0 in a CA:FALSE certificate? (Merely to assess the
>> seriousness of the issue, given that the certificate was already
>> revoked).
>
> Yes, the cryptography Python package:
https://github.com/pyca/cryptography/issues/3856
>

Reading that issue, the text in comment #0 is unclear. Does the python
code reject such certificates, or somehow skip extensions and declaring
possibly invalid uses to be valid?


As of the current release pyca/cryptography raises an exception during
parsing for certificates that contain a pathLength and are CA:FALSE. This
immediately halts parsing and prevents the user from viewing any extensions.

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

Re: Certificates with invalidly long serial numbers

[Paul Kehrer via dev-security-policy]

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
> All CAS are required to maintain the capability to process and receive 
> revocation requests 24x7 under the baseline requirements. The headache is not 
> with the CA. Rather, it's notifying the customer that their certificate will 
> be revoked before the start of the next business day. Having a one to two 
> business day rule  instead of 24 hours for non compromise issues gives the 
> end entity time to receive the notification and replace their certificate 
> with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it does 
sound like a good solution. However, I think it's another example of the 
general difference of opinion between people on this list around whether we 
should be holding CAs to the highest standards or not. These mis-issued 
certificates are typically not a security concern, but they speak to either 
ignorance on the part of CA operators or a pattern of lackadaisical controls 
within the issuance systems. Neither of these is acceptable behavior at this 
juncture. Conformance with the BRs has been mandatory for over 5 years now. 
Customers need to be made aware of the failures of their chosen providers and 
the responsibilities incumbent upon them as subscribers, and if their own 
certificate installation/replacement processes are sufficiently archaic as to 
make it difficult to replace a certificate in an automated fashion then they 
should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business days" 
really mean?Does the CA get 1-2 business days followed by 1-2 for the customer? 
What if there's a holiday in the CA's country of operations followed by a 
holiday in the customer's home country? How quickly does this window extend to 
2+ weeks? If you were to go down this path I'd strongly prefer it to be a hard 
deadline (e.g. 72 hours) and not anything related to business days.

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

Re: Certificates with invalidly long serial numbers

[Paul Kehrer via dev-security-policy]

On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
> 24 hours is super short when it's a Saturday morning at 4 am and it’s a 
> European government entity. I agree that is what the policy says now, but, 
> for lower risk items, the policy should change, preferably to at least one 
> business day. 
> 

It is short, but any CA possessing global trust should already have procedures 
in place for handling revocation in a prompt manner. It seems odd that it would 
be onerous for them to revoke a non-compliant certificate. The only difference 
is a need to confirm to the CA's satisfaction that the given certificate is in 
violation of the BRs, which I would expect any competent CA to be eminently 
capable of doing.

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