Re: Summary of Camerfirma's Compliance Issues

[Kurt Roeckx via dev-security-policy]

On 2021-01-19 11:02, Ramiro Muñoz wrote:

El martes, 19 de enero de 2021 a las 0:49:42 UTC+1, Matt Palmer escribió:

On Sun, Jan 17, 2021 at 12:51:29AM -0800, Ramiro Muñoz via dev-security-policy 
wrote:

We don’t ask the community to disregard the data, on the contrary we ask
the community to analyze the data thoroughly including the impacts
produced.

OK, I'll bite. As a member of the community, I've analyzed the data
thoroughly, and I'm not impressed. Camerfirma does not appear to grasp the
fact that "nothing bad has happened yet" is a *bad take*. "Nothing bad has
happened yet" is how every CA starts its life. It is not something to be
proud of, it's the absolute bare minimum. The volume of incidents that
Camerfirma has had is troubling, but it's the repetition of the nature of
the incidents, and the lacklustre way in which they have been responded to,
that causes me to think that Camerfirma has no place in the Mozilla trust
store.

- Matt


Dear Matt,

Thanks for your input, we really appreciate your time in contributing to this 
discussion.

We are trying to make this discussion as objective as possible, and talking 
about objectivity I’d like to ask you where does the ‘bare minimum’ threshold 
stands according  to Mozilla Root Store Policy. And why you are positioning 
Camerfirma below such a ‘bare minimum’ bar considering that Camerfirma, 
according to the public data, is not the member with the highest number of 
incidents nor the member with the most severe ones.


I think you misunderstand Matt's mail.

If "something bad has happened" was the case, this would be a much 
different discussion. As far as we know, you're still meeting the bare 
minimum. But the bare minimum is not good enough.



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

Re: Extending Android Device Compatibility for Let's Encrypt Certificates

[Kurt Roeckx via dev-security-policy]

On Thu, Jan 07, 2021 at 09:31:17AM -0800, Aaron Gable wrote:
> In cases where we expect OpenSSL to be validating the chain, we expect that
> ISRG Root X1 is also in the trust store (unlike older versions of Android,
> where we know that it hasn't been added). As such, there will be two
> certificates in the chain which are also in the local trust store: ISRG
> Root X1 and the expired DST Root CA X3.
> 
> It is my understanding that OpenSSL 1.1.0+, with the `trusted_first` method
> as the default chain-building method, will go through the following steps:
> 1) Receive the chain "EE <-- R3 <-- ISRG Root X1 (cross-signed by DST Root
> CA X3)" from the server
> 2) Look to see if it can complete this chain using certificates from
> `-CAfile`, `-CApath`, or `-trusted`
> 3) See that ISRG Root X1 is already trusted
> 4) Return this chain, which successfully verifies.
> 
> The evidence that this works on OpenSSL 1.1.0+ comes from the very similar
> situation this past May. In that case, many servers were serving the chain
> "EE <-- Sectigo RSA Domain Validation Secure Server CA <-- USERTrust RSA
> Certification Authority <-- AddTrust External CA Root". In that situation,
> both the USERTrust RSA Certification Authority and the AddTrust External CA
> Root were in various trust stores, and then the AddTrust External CA Root
> expired. Clients which were using OpenSSL 1.1.0+ did not begin to fail at
> that time, because they were still able to trust the USERTrust RSA
> Certification Authority. Clients using OpenSSL 1.0.x were failing, because
> they couldn't recognize that one of the intermediates in the chain was in
> their own trust store.
> 
> If this understanding is incorrect or missing something, we'd love to be
> informed.

Yes, "trusted first" behaves that way and is on by default since
1.1.0 and can't be disabled. It was not clear to me that the X1
root was in the trust store if you use 1.1.0.


Kurt

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

Re: Extending Android Device Compatibility for Let's Encrypt Certificates

[Kurt Roeckx via dev-security-policy]

On 2021-01-07 01:48, Aaron Gable wrote:

As mentioned in the blog post, and as we'll elaborate on further in an
upcoming post, one of the drawbacks of this arrangement is that there
actually is a class of clients for which chaining to an expired root
doesn't work: versions of OpenSSL prior to 1.1. This is the same failure
mode as various clients ran into on May 30th of 2020, when the AddTrust
External CA root expired.


I'm not sure why you mention OpenSSL prior to 1.1. There was a bug in 
1.1.1h that no longer checked for expired roots, but it was fixed in 
1.1.1i. OpenSSL has no plan to allow expired roots by default.



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

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Kurt Roeckx via dev-security-policy]

On Thu, Aug 13, 2020 at 12:43:01PM -0700, Ronald Crane via dev-security-policy 
wrote:
> I'd argue that domain registrars, CAs, and hosting services _should_ have an
> obligation to deny services to obvious phishing domains. [1] (This is
> independent of what (if any) obligations they might currently have.)
> Phishing continues to be epidemic. It is not enough that some user agents
> attempt to prevent users from following suspected phishing links.
> 
> How this obligation should be implemented is an involved question that I'm
> not prepared to address. The first step, though, is establishing the
> principle that registrars, CAs, and hosting services are not mere pipe
> utilities with no obligations to prevent obvious malefactors from injecting
> sewage into them.
> 
> -R
> 
> [1] No, electric utilities, etc., should not also be obligated to deny them
> electricity, etc. This would require an impractical (and privacy-invading)
> level of investigation. An electric-utility customer does not submit a list
> of domain(s) to the electric utility to obtain service. A phisher _does_
> submit such a list to its registrar, CA, and host.

It's possible that the host does not know the anything related to
the DNS name, for instance because it rents virtual machines and
assigns them an IP address. The registrar might be hosting the
DNS.

You could also argue that the TLDs should be responsible for it.


Kurt

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

Re: Non-DER certificate (PKCS #7) in CA Issuers AIA field

[Kurt Roeckx via dev-security-policy]

On Fri, May 22, 2020 at 10:38:34AM +0200, Hanno Böck via dev-security-policy 
wrote:
> Just reported this to Chunghwa Telecom Co., Ltd.:
> 
> --
> 
> I'm contacting you about a problem with the certificate for
> *.hinet.net, as it can be found here [1].
> 
> The Authority Information Access / CA Issuers field points to:
> http://repository.publicca.hinet.net/certs/IssuedToThisCA.p7b
> 
> According to RFC 5280 this must be a DER-encoded certificate. See also
> recent discussion on the Mozilla policy list [2].
> However this does not look like a different certificate encoding (PKCS
> #7 binary).
> 
> Please make sure you serve a correct, DER-encoded intermediate via the
> AIA field.

It does say:
   or a
   collection of certificates in a BER or DER encoded "certs-only" CMS
   message as specified in [RFC2797].

And it's currently not clear to me if that PKCS #7 file is such a
file or not.


Kurt

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

Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours

[Kurt Roeckx via dev-security-policy]

On Thu, May 21, 2020 at 02:01:49PM -0700, Daniela Hood via dev-security-policy 
wrote:
> Hello Sandy,
> 
> GoDaddy received an email on Friday, May 7, 2020 12:06 UTC, reporting a key 
> compromise, by Sandy. Once received our team started working on making sure 
> that the certificate had indeed a compromised key, the investigation on the 
> certificate finished at that same day Friday, May 7th between 16:54 UTC and 
> 16:55 UTC. 
> After that we followed the Baseline Requirements 4.9.1 That says: "The CA 
> obtains evidence that the Subscriber's Private Key corresponding to the 
> Public Key in the Certificate suffered a Key Compromise;" We obtained the 
> evidence that the key was compromised when we finished our investigation at 
> 16:55 UTC, that was the time we set 24 hours revocation of the certificate, 
> the same was revoked at May 8th at 16:55 UTC.
> We communicated with the reporter as soon as we completed our investigation 
> and informed that the affected certificate would be revoked strictly within 
> 24 hours which we have done and can be confirmed here: 
> https://crt.sh/?id=2366734355

>From what I understand, you received the evidence at May 7, 2020
12:06 UTC, but it took you until 16:55 UTC to confirm that the
evidence you've received was valid.

I think the 24 hour starts at the time you receive the evidence, not
the time that you confirm the evidence is valid. Otherwise you can
just delay looking at the mail for say a week, and still claim
that you revoked it in 24 hours.


Kurt

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

Re: Digicert issued certificate with let's encrypts public key

[Kurt Roeckx via dev-security-policy]

On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via dev-security-policy 
wrote:
> On Sat, 16 May 2020 14:02:42 +0200
> Kurt Roeckx via dev-security-policy
>  wrote:
> 
> > https://crt.sh/?id=1902422627
> > 
> > It's a certificate for api.pillowz.kz with the public key of Let's
> > Encrypt Authority X1 and X3 CAs.
> > 
> > It's revoked since 2020-01-31, but I couldn't find any incident
> > report related to it.
> 
> Hi Kurt,
> 
> It's not obvious what's non-compliant about this certificate - could you
> explain?  Note that there is no requirement or security need for CAs to
> validate proof of possession of a private key.

I was under the impression that there was. But looking at the BRs,
3.2.1 is just empty.


Kurt

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

Digicert issued certificate with let's encrypts public key

[Kurt Roeckx via dev-security-policy]

Hi,

Browsing crt.sh, I found this:
https://crt.sh/?id=1902422627

It's a certificate for api.pillowz.kz with the public key of Let's
Encrypt Authority X1 and X3 CAs.

It's revoked since 2020-01-31, but I couldn't find any incident
report related to it.


Kurt

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

Re: Mozilla's Expectations for OCSP Incident Reporting

[Kurt Roeckx via dev-security-policy]

On 2020-05-15 08:47, Peter Gutmann wrote:

Hanno Böck  writes:


The impact it had was a monitoring system that checked whether the
certificate of a host was okay, using gnutls-cli with ocsp enabled (which
also uncovered a somewhat unexpected inconsistency in how the gnutls cli tool
behaves[1]).


Sure, but if the only impact was on a specially-configured setup (gnutls-cli
with OCSP explicitly enabled rather than a standard web browser) then it
didn't have any real impact on actual users.



Browsers by default just ignore any OCSP error. So while the browser 
might have seen an error getting the OCSP reply, the user is not aware 
of it.


So it's possible that a certificate was revoked, but because OCSP was 
down that the browser connected to the website without any error, while 
it should have given an error. So it's possible that there was a real 
impact on actual users.



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

Re: Mozilla's Expectations for OCSP Incident Reporting

[Kurt Roeckx via dev-security-policy]

On 2020-05-08 21:03, Wayne Thayer wrote:

It was recently reported [1] that IdenTrust experienced a multi-day OCSP
outage about two weeks ago. Other recent OCSP issues have resulted in
incident reports [3][4], so I am concerned that IdenTrust didn't report
this, and I created a bug [5] to ensure that we track the issue (assuming
the report of an extended outage is accurate).

I also created an issue [6] suggesting that Mozilla clarify expectations
for reporting CRL and OCSP outages. These services are notoriously
unreliable and I doubt that a constant barrage of reports for brief outages
would be manageable. I believe that Mozilla does expect CAs to report
"significant" outages, but there is currently no guidance to help CAs
determine when they should file a report.


Should we have minimum uptime requirements? For instance 90% for a 24 
hour period and 95% per 30 days?



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

Re: GTS - OCSP serving issue 2020-04-09

[Kurt Roeckx via dev-security-policy]

On 2020-04-16 14:56, Neil Dunbar wrote:


I would have thought that an OCSP-stapling implementation which got an 
OCSP status code 'successful' (0) with a 'revoked' status for the 
certificate would want to pass that on to the client, replacing any 
prior OCSP successful/status-good report, whether that prior report was 
still valid.


As owner of the certificate, I think you actually don't want to do that, 
because things will stop working. If it's revoked you want to get a new 
certificate, and as long as you don't have the new one, you want to use 
the old certificate and staple the good OCSP response.



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

Re: Is issuing a certificate for a previously-reported compromised private key misissuance?

[Kurt Roeckx via dev-security-policy]

On 2020-03-19 07:02, Matt Palmer wrote:

2. If there are not explicit prohibitions already in place, *should* there
be?  If so, should it be a BR thing, or a Policy thing?



I think there should be. I expect them to publish a CRL that says the 
reason for revocation is a key compromise. I expect them to check for 
other keys with the same public key at that time, and also revoke them. 
Before signing a new key, I expect them to have checked it against there 
list of previously reported key compromises.



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

Re: Which fields containing email addresses need to be validated?

[Kurt Roeckx via dev-security-policy]

On Thu, Feb 06, 2020 at 09:31:40PM +, Doug Beattie via dev-security-policy 
wrote:
> I don't agree that the CA MUST validate EVERY field.  CAs leverage
> enterprise RAs to validate some information in SMIME certificates, e.g., the
> subscribers name in the CN field because the CA can't readily validate that.

I don't care who does the validation, just that it's validated.


Kurt

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

Re: Which fields containing email addresses need to be validated?

[Kurt Roeckx via dev-security-policy]

On Thu, Feb 06, 2020 at 08:54:04PM +, Doug Beattie via dev-security-policy 
wrote:
> It's not against Mozilla policy to
> issue certificates with unvalidated email addresses in any field as long as
> the Secure Mail EKU is not included, so the intent should be to validate
> only those that are used for Secure Mail.

Any field in the certificate should be validated. If it contains
an email address, it should be validated. If it's not validated,
it should get removed.


Kurt

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

Re: Certificate OU= fields with missing O= field

[Kurt Roeckx via dev-security-policy]

On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via 
dev-security-policy wrote:
> Hi,
> 
> I recently noticed that a lot of leaf certificates [0] have
> organizationalUnitName specified without other organizational
> information such as organizationName. Many times this field is used
> for branding purposes, e.g. "issued through "
> or "SomeBrand SSL".
> 
> BR v1.6.6 § 7.1.4.2.2i has guidance on usage of the OU field: "The CA
> SHALL implement a process that prevents an OU attribute from including
> a name, DBA, tradename, trademark, address, location, or other text
> that refers to a specific natural person or Legal Entity unless the CA
> has verified this information in accordance with Section 3.2 and the
> Certificate also contains subject:organizationName, ,
> subject:givenName, subject:surname, subject:localityName, and
> subject:countryName attributes, also verified in accordance with
> Section 3.2.2.1."
> 
> As the organizationName and other related attributes are not set in
> many of those certificates, even though e.g. "COMODO SSL Unified
> Communications" is a very strong reference to Sectigo's ssl branding &
> business, I believe the referenced certificate is not issued in line
> with the BR.
> 
> Is the above interpretation of BR section 7.1.4.2.2i correct?

That OU clearly doesn't have anything to do with the subject that
was validated, so I also consider that a misissue.


Kurt

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

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On Wed, Oct 02, 2019 at 03:17:31PM -0700, Paul Walsh wrote:
> >> In separate research, CAs have shown data to demonstrate that website 
> >> owners want to have their identity verified. 
> > 
> > They have not. In fact, I would say that most website owners are perfectly
> > happy with DV certificates.
> 
> What’s your source of data to substantiate what you “would say”? We need to 
> start talking about facts and data.

How many DV, OV and EV certificates are there? I think it's rather
clear what most website owners use.


Kurt

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

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On Wed, Oct 02, 2019 at 02:48:56PM -0700, Paul Walsh wrote:
> On Oct 2, 2019, at 12:52 AM, Kurt Roeckx via dev-security-policy 
>  wrote:
> > 
> > On 2019-10-02 09:20, Kurt Roeckx wrote:
> >> On 2019-10-02 02:39, Paul Walsh wrote:
> >>> 
> >>> According to Ellis, the goal for a customer survey is to get feedback 
> >>> from people who had recently experienced "real usage" of the product. The 
> >>> key question in the survey for these people according to Ellis, is:
> >>> 
> >>> "How would you feel if you could no longer rely on MetaCert's green 
> >>> shield?
> >> No, the question he would be asking is:
> >> "How would you feel if you could no longer use MetaCert's EV certificates?"
> > 
> > And it's probably better to even turn that into:
> > How would you feel if you could no longer buy MetaCert's EV certificates?
> 
> [PW] MetaCert is not a CA. We don’t have any relationships with any CAs 
> either. 

Well, for what Ellis is talking about, it's asking about a
product, and how the user would feel if that product can't be used
anymore.

That just shows that there are users that want your product, not
that everybody wants it.

> Our research was aimed at end-users, as I said previously. We have proof that 
> users want to use a visual indicator for trust. And we also demonstrated that 
> it’s possible to protect users with well designed browser UI/UX.

Sure, there will be users that want that, nobody is denying that.

> In separate research, CAs have shown data to demonstrate that website owners 
> want to have their identity verified. 

They have not. In fact, I would say that most website owners are perfectly
happy with DV certificates.


Kurt

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

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On 2019-10-02 09:20, Kurt Roeckx wrote:

On 2019-10-02 02:39, Paul Walsh wrote:


According to Ellis, the goal for a customer survey is to get feedback 
from people who had recently experienced "real usage" of the product. 
The key question in the survey for these people according to Ellis, is:


"How would you feel if you could no longer rely on MetaCert's green 
shield?


No, the question he would be asking is:
"How would you feel if you could no longer use MetaCert's EV certificates?"


And it's probably better to even turn that into:
How would you feel if you could no longer buy MetaCert's EV certificates?


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

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On 2019-10-02 02:39, Paul Walsh wrote:


According to Ellis, the goal for a customer survey is to get feedback from people who had 
recently experienced "real usage" of the product. The key question in the 
survey for these people according to Ellis, is:

"How would you feel if you could no longer rely on MetaCert's green shield?


No, the question he would be asking is:
"How would you feel if you could no longer use MetaCert's EV certificates?"

Which is something totally different. It's very important to get the 
question right.



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

Re: DigiCert OCSP services returns 1 byte

[Kurt Roeckx via dev-security-policy]

On Mon, Sep 23, 2019 at 02:53:26PM -0700, Andy Warner via dev-security-policy 
wrote:
> 
> 1. The new text added to the Mozilla Recommended and Required Practices for 
> this topic states only OCSP status is required for precertificates. Many CAs 
> provide both CRLs and OCSP services and it would be problematic if these two 
> mechanisms provided different answers to the same question. 
> 
> The practice of revoking non-issued certificates would therefore lead to CRL 
> growth which would further make reliable revocation checking on bandwidth 
> constrained clients more difficult.

There have been suggestions to revoke them, but it's my
understanding that there is no such requirement.

> 2. There seem to be a number of assumptions that precertificate issuance and 
> certificate issuance is roughly atomic. In reality, a quorum of SCTs is 
> required prior to final certificate issuance, so that is not the case.

I don't see anybody suggesting that, nor how it's relevant.

With all the uptime requirements on the logs and the number of
available logs, I don't see why you should have a failure rate
of 1 in 2000, and that more seems like an implementation problem.

> 3. This raises the question of how much time a CA has from the time they 
> issue a precertificate to when the final certificate must be issued. When 
> there are logs ecosystem issues that are beyond the control of a CA, the gap 
> can easily be orders of magnitude higher than normal operating conditions.

At what is the issue with that?

> * Clarifications
> 
> This in turn raises the question if CAs can re-use authorization data such as 
> CAA records or domain authorizations from the precertificate? If a final 
> certificate has not been issued due to a persistent quorum failure, and that 
> failure persists longer than the validity of the used authorization data, can 
> the authorizations that were done prior to the precertificate issuance be 
> re-used?

So 1 year is sometimes not enough to get SCTs?


Kurt

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

Re: DigiCert OCSP services returns 1 byte

[Kurt Roeckx via dev-security-policy]

On 2019-09-16 14:02, Rob Stradling wrote:


ISTM that this "certificate presumed to exist" concept doesn't play
nicely with the current wording of BR 4.9.10:
'If the OCSP responder receives a request for status of a certificate
 that has not been issued, then the responder SHOULD NOT respond with
 a "good" status.'

If a certificate (with embedded SCTs and no CT poison extension) is
"presumed to exist" but the CA has not actually issued it, then to my
mind that's a "certificate that has not been issued"; and therefore, the
OCSP 'responder SHOULD NOT respond with a "good" status'.


The problem of course is that you don't query OCSP about a certificate, 
you query it about a serial number. And that serial number has been 
issued. So maybe the BRs should say serial number instead of certificate?



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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kurt Roeckx via dev-security-policy]

On 2019-09-04 14:14, Matt Palmer wrote:


If EV information is of use in anti-phishing efforts, then it would be best
for the providers of anti-phishing services to team up with CAs to describe
the advantages of continuing to provide an EV certificate.  If site owners,
who are presumably smart people with significant technical skills making
decisions on a rational basis, don't see the benefits (after a little
training), perhaps you should accept their decision, even if you disagree
with them or have a different commercial interest.


So I think what you're saying is that sites with EV will still be more 
trusted, but the browser isn't really aware of it.



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

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Kurt Roeckx via dev-security-policy]

On 2019-08-30 12:14, Jakob Bohm wrote:

On 30/08/2019 01:36, Jacob Hoffman-Andrews wrote:

Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652

On 2019.08.28 we read Apple’s bug report at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
responder returning incorrect results for a precertificate. This prompted us to 
run our own investigation. We found in an initial review that for 35 of our 
precertificates, we were serving incorrect OCSP results (“unauthorized” instead 
of “good”). Like DigiCert, this happened when a precertificate was issued, but 
the corresponding certificate was not issued due to an error.

We’re taking these additional steps to ensure a robust fix:
- For each precertificate issued according to our audit logs, verify that 
we are serving a corresponding OCSP response (if the precertificate is 
currently valid).
- Configure alerting for the conditions that create this problem, so we can 
fix any instances that arise in the short term.
- Deploy a code change to Boulder to ensure that we serve OCSP even if an 
error occurs after precertificate issuance.



For CAs affected by OCSP misbehavior in this particular scenario (Pre-
Cert issued and submitted to CT, actual cert not issued), they should
take a look at those error cases and subdivide them into:

1. No intent to actually issue the actual cert.  Best handling is to
   treat as revoked in all revocation protocols and logs, but with audit
   and incident systems reporting that the cert wasn't actually issued.
   ( *Most common case* ).

2. Intent to actually issue later, if/when something happens that just
   takes longer than usual.  Here it makes sense for OCSP and other such
   mechanisms to return "good", due to the ban on reporting "certificate
   hold" or otherwise exiting a revoked state.  It of cause remains
   possible to later revoke such a half-issued cert if there is a reason
   to do so.

3. Intent to issue in a few minutes, somehow OCSP was queried during the
   short processing delay between CT submission and actual issuing of
   cert with embedded CT proofs.  Because inserting the CT proofs in the
   OCSP responses probably awaits the same technical condition as the
   cert issuing, it makes sense to return "unknown" for those few
   minutes, as when delivery of the cert status to the OCSP servers is
   itself delayed by a few minutes (up to whatever limit policies set
   for updating revocation servers with knowledge of new certs).


It's not obvious for me why such cases exist, and I think it would at 
least be useful to have an actual list of why a pre-certificate was 
issued and the real certificate was not.


If the pre-certificate was issued, it means all validation should 
already have happened, and there is no reason not to issue the real 
certificate other than some problems preventing it. But the difference 
between 3) and 1) and 2) seems to be someone manually moved it from 3) 
to one of the other 2.


Examples of reasons for me are things like:
- There is some technical problem with a server, it will be issued when 
the server works again, or it's redirected to some other server. (like 
can't get enough SCTs.)

- You lint the pre certificate and see an issue (and should revoke it)

I think there shouldn't exist pre-certificates that are valid without 
the real certificate, after some delay. For instance, if you can't issue 
the real certificate within 24 hours, revoke the pre-certificate.



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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kurt Roeckx via dev-security-policy]

On Fri, Aug 16, 2019 at 12:42:35PM -0700, tim--- via dev-security-policy wrote:
> 
> By way of background, until recently almost all phishing and malware was on 
> unencrypted http sites. They received a neutral UI, and the bad guys didn’t 
> have to spend time and money getting a certificate, even a DV certificate, 
> that might leave traces as to their identity. Users were told (and remembered 
> the advice) to “look for the lock symbol” for greater security.
> 
> Then a few things happened in close proximity: (1) Google incentivized all 
> websites to move to encryption through the use of its “Not secure” warning, 
> (2) Mozilla instituted a similar “Not Secure” warning, and (3) Let’s Encrypt 
> began offering anonymous, automated DV certificates to everyone, including 
> known phishing sites, in part through Platinum-level financial support from 
> Mozilla and Google.
> 
> As a result, virtually all phishing has now moved to DV encrypted websites 
> which receive the lock symbol in Firefox, which was predictable. In fact, the 
> FBI just issued a warning to consumers not to trust the https or lock symbol 
> in browsers anymore [1], as half or more of phishing sites now display the 
> lock symbol. [2]
> 
> It’s unclear how Mozilla plans to ramp up protection for Firefox users. 
> Browser phishing filters such as Google Safe Browsing are good, but not 
> perfect. According to the most recent NSS labs report issued in October 2018, 
> GSB offers only about 79% user protection at “zero hour”, gradually rising to 
> 95% protection after 2 days. [3] However, most phishing sites are shut down 
> by then anyway. If a browser phishing filter is the main defense provided to 
> users by Firefox, this means thousands of users can be harmed before a site 
> is flagged for phishing. Clearly Mozilla should be looking for other ways to 
> protect them.
> 
> That’s where EV certificates can help. Data shows that websites with EV 
> certificates have a very low incidence of phishing. New research from RWTH 
> Aachen University presented at Usenix this week measured the incidence of 
> phishing sites using certificates of various validation levels [4]. EV 
> certificates made up 0.4% of the total population of phishing sites with 
> certificates but 7% of the “benign” (non-phishing) sites. Compare that to OV, 
> where 15% of phishing sites had that certificate type and 35% of benign sites 
> had the same. And compare that again to Let’s Encrypt certificates, which 
> made up 34% of certificates for phishing sites and only 17% for benign sites.
> 
> This research validates the results of an earlier study of 3,494 encrypted 
> phishing sites in February 2019 [5]. In this study the distribution of 
> encrypted phishing sites by certificate type was as follows:
> 
> EV0 phishing sites (0%)
> OV145 phishing sites (4.15%)*
> DV3,349 phishing sites (95.85%)
> 
> *(These phishing OV certs were mostly multi-SANs certs requested by CDNs such 
> as Cloudflare containing multiple URLs for websites whose content the Subject 
> of the OV cert did not control. Perhaps such certificates should be DV rather 
> than OV.)
> 
> Furthermore, research from Georgia Tech shows that EV sites have an 
> exceedingly low incidence of association with malware and known bad actors 
> [6].
> 
> 
> These studies show that the presence of an EV certificate has a strong 
> negative correlation with criminal activity intent on victimizing the site 
> visitor. In plain terms, users are safer when they visit sites with EV certs. 
> Now, how do we use that?

So they either don't have anything to do, just check some box, or need
to spend 1 minute to get a DV certs. And as your research shows,
DV certs are good enough to do phishing, they don't need EV certs,
so why would they bother?

But they you also say that 0.4% actually used an EV certificate.
My guess in that case is that they didn't actually bother to get
an EV ceritificate, but just hacked some website that just happens
to have an EV certificate.

I also think that 7% of the non-phising sites using EV
certificates doesn't make sense at all, and that's most likely a
sample bias.

> This is where the argument that “users don’t see the absence of positive 
> indicators” misses the mark for several reasons. 
> 1. The internet is in possession of a clear signal of a site’s safety for the 
> end user. The fact that popular end-user software fails to take advantage of 
> this signal is a shortcoming of that software, not the signal.

So here you turn a correlation into a causation.

> 3. User behavior also changes based on context. The site visitor who suffers 
> from interface blindness when everything is going well may become hyper aware 
> when something suspicious occurs. If nothing else, the presence of an EV cert 
> gives the likes of law enforcement a clear path forward when pursuing 
> perpetrators of online crime.

phishing sites don't expect everybody to be fooled. If 1 in 1
is 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kurt Roeckx via dev-security-policy]

On Wed, Aug 14, 2019 at 11:52:46PM -0700, Daniel Marschall via 
dev-security-policy wrote:
> In old Firefox, I get a green bar if I visit google.com and paypal.com, 
> telling me that this is a well-known company that got the EV certificate.
> The other fake domains goog1e.com and paypa1.com only have DV certificates by 
> Let's Encrypt.

The green bar does not indicate that it's a well-known company. It
means someone payed for an EV certificate. The green bar does not
in any way say it's more secure or indicate that you're talking to
some trustworthy company. It only gives you a false sense of
security.


Kurt

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

Re: [FORGED] Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kurt Roeckx via dev-security-policy]

On 2019-08-13 05:27, Peter Gutmann wrote:

Wayne Thayer via dev-security-policy  
writes:


Mozilla has announced that we plan to relocate the EV UI in Firefox 70, which
is expected to be released on 22-October. Details below.


Just out of interest, how are the CAs taking this?  If there's no more reason
to pay a substantial premium to enable additional UI bling in browsers, isn't
this going to kill the market for EV certs?


See the original mail for why the indication has been removed in browsers.

But EV is still useful for things like code signing and email. And I 
would argue that EV should be the only option for such certificates.



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

Re: Audit Reminder Email Summary

[Kurt Roeckx via dev-security-policy]

On Tue, Jul 16, 2019 at 12:12:57PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> Mozilla: Overdue Audit Statements
> CA Owner: LuxTrust
> Root Certificates:
>LuxTrust Global Root 2
> Standard Audit:
> https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf
> Standard Audit Period End Date: 2018-03-30
> BR Audit:
> https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf
> BR Audit Period End Date: 2018-03-30
> EV Audit:
> https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf
> EV Audit Period End Date: 2018-03-30
> CA Comments: null

For the overdue statements, I always see a comment, ussually
something like:
| ** Audit Case in the Common CA Database is under review for this root
| certificate.

But this root CA doesn't seem to have have any comment. Nor does this one:

> Mozilla: Overdue Audit Statements
> CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum)
> Root Certificates:
>Certum Trusted Network CA 2
>Certum CA
>Certum Trusted Network CA
> Standard Audit:
> https://bug1286477.bmoattachments.org/attachment.cgi?id=9001516
> Standard Audit Period End Date: 2018-03-26
> BR Audit: https://bug1286477.bmoattachments.org/attachment.cgi?id=9001514
> BR Audit Period End Date: 2018-03-26
> EV Audit: https://bug1286477.bmoattachments.org/attachment.cgi?id=9001515
> EV Audit Period End Date: 2018-03-26
> CA Comments: null

Will you open such audit cases? Is this just some timing problem
that the mails got sent before it could be opened?

I also miss things like the state in the intermediate summary you
sent.


Kurt

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

Re: Survey of (potentially noncompliant) Serial Number Lengths

[Kurt Roeckx via dev-security-policy]

On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via dev-security-policy 
wrote:
> 
> When a value in column E is 100%, this is pretty solid evidence of 
> noncompliance with BR 7.1.
> When the values in column E and G are both approximately 50%, this 
> suggests (but does not prove) that the CA is handling the output from 
> their CSPRNG correctly.

Sould F/G say >= 64, instead of > 64?


Kurt

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Kurt Roeckx via dev-security-policy]

On Thu, Mar 14, 2019 at 04:09:10PM -0700, Jaime Hablutzel via 
dev-security-policy wrote:
> > In accordance with our conversations to date, prior to 3/7 6:30pm AZ we 
> > utilized raw 64 bit output from CSPRING, with uniqueness and non zero 
> > checks. This new understanding of the rules calls for us to modify our 
> > original disclosure to 0 affected certificates.
> 
> "uniqueness and non zero checks" have crippled the effective 64 bit output 
> from the CSPRNG, so, as I can see it, all of your previously generated serial 
> numbers (according to the algorithm you disclosed [1]) could be considered 
> non-compliant to current BRs as explained below:
> 
> First, according to your algorithm, if the MSB in the fully random 8 octets 
> is 1 you add a leading 00 byte, so until that time you have 64 full bits of 
> entropy, i.e. 18446744073709551616 possible different values.
> 
> Then, you have to filter out some values. To begin with, you filter out the 
> value 0, leaving you with 18446744073709551615 possible values.
> 
> Now, you filter the previosly generated serial numbers (known to potential 
> attackers thanks to current CT deployment), let's say 100 at a given 
> point in time, so now you are left with 18446744073708551615 possible values.
> 
> And if we do the math:
> 
> 18446744073708551615 / 18446744073709551616 * 64 = 
> 63.9996530549578599433858
> 
> Which is less than the required 64 bits.
> 
> So any filtering operation (e.g. previously generated serial numbers) 
> actually reduce effective entropy and overall security as illustrated in the 
> fictional and forced scenario in [2].

The most obvious way to implement this is that in case the check
fails, you just generate an other serial. You can argue that that
new serial will contain 64 bit of entropy, but if you want to be
really correct, I think you're right and it doesn't.

Just as example, if you generate 64 bit random numbers, and throw
away all those that have the top bit set, which would be around
half of them, it's easy to see you've reduced it to 63 bit.

So you can argue that it's not possible to comply with the BRs by
just generating a 64 bit random number, you would need to generate
at least 65. But I would argue that such an implementation that
only generates 64 bits and does the checks is in the spirit of what
was intended.


Kurt

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Kurt Roeckx via dev-security-policy]

On Wed, Mar 13, 2019 at 05:56:55AM +0900, Hector Martin 'marcan' via 
dev-security-policy wrote:
> On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> > Note that even 7 bytes or less may still be valid - for example, if the
> > randomly generated integer was 4 [1], you might only have a one-byte serial
> > in encoded form ( '04'H ), and that would still be compliant. The general
> > burden of proof would be to demonstrate that these certificates were
> > generated with that given algorithm you described above.
> > 
> > [1] https://xkcd.com/221/
> 
> Not only that, but, in fact, any attempt to guarantee certain properties
> of the serial (such that it doesn't encode to 7 bytes or less) *reduces*
> entropy.

The expected distribution when generating a random 64 bit integer
and properly encoding that as DER is that:
- about 1/2 integers require 9 bytes
- about 1/2 integers require 8 bytes
- about 1/512 integers require 7 bytes
- about 1/131072 integers require 6 bytes
- about 1/33554432 integers require 5 bytes
- [...]

That a serial is smaller than 8 bytes is not an indication that it
doesn't contain enough entropy.


Kurt

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

Re: DarkMatter Concerns

[Kurt Roeckx via dev-security-policy]

On Sat, Feb 23, 2019 at 02:07:38PM +0400, Scott Rea via dev-security-policy 
wrote:
> G’day Wayne et al,
> 
> In response to your post overnight (included below), I want to assure you 
> that DarkMatter’s work is solely focused on defensive cyber security, secure 
> communications and digital transformation. We have never, nor will we ever, 
> operate or manage non-defensive cyber activities against any nationality.

Can you explain what you mean with defensive cyber security and
how this relates to the CA?


Kurt

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

Re: DarkMatter Concerns

[Kurt Roeckx via dev-security-policy]

On Fri, Feb 22, 2019 at 03:45:39PM -0800, cooperq--- via dev-security-policy 
wrote:
> On Friday, February 22, 2019 at 2:37:20 PM UTC-8, Jonathan Rudenberg wrote:
> > With regards to the broader question, I believe that DarkMatter's alleged 
> > involvement with hacking campaigns is incompatible with operating a 
> > trustworthy CA. This combined with the existing record of apparent 
> > incompetence by DarkMatter (compare the inclusion bugs for other recently 
> > approved CAs for contrast), makes me believe that the approval request 
> > should be denied and the existing intermediates revoked via OneCRL. I don't 
> > see how approving them, or the continued trust in their intermediates, 
> > would be in the interests of Mozilla's users or compatible with the Mozilla 
> > Manifesto.
> > 
> > Jonathan
> > 
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c29
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262#c32
> 
> I wrote a post about this issue this morning for EFF: 
> https://www.eff.org/deeplinks/2019/02/cyber-mercenary-groups-shouldnt-be-trusted-your-browser-or-anywhere-else
> 
> Given DarkMatter's business interest in intercepting TLS communications 
> adding them to the trusted root list seems like a very bad idea. (I would go 
> so far as revoking their intermediate certificate as well, based on these 
> revelations.)

I would also like to have a comment from the current root owner
(digicert?) on what they plan to do with it.


Kurt

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

Re: Discrepancy on Address

[Kurt Roeckx via dev-security-policy]

On 2019-02-08 1:04, identr...@gmail.com wrote:

On Thursday, February 7, 2019 at 6:47:03 PM UTC-5, iden...@gmail.com wrote:

On 04/04/2018 we found a discrepancy in the address values for some SSL 
certificates. A formal incident Report was just posted:
https://bugzilla.mozilla.org/show_bug.cgi?id=1526099


CORRECTION: This issue was found last Monday 4/4/2019 and it this date is 
properly reflected in the logged big.Sorry about this typo.


I guess the 4th of February ...


Kurt

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

Re: Changing Date Checks in Audit Reminder Emails

[Kurt Roeckx via dev-security-policy]

On 2019-02-04 21:33, Kathleen Wilson wrote:

All,

As you know, CCADB sends audit reminder emails regarding root certs in 
Mozilla's program on the 3rd Tuesday of each month.


We are going to update the date checks for determining when the email 
gets sent, so that rather than keying off of the Audit Statement Date, 
the check will key off of the Audit Period End date.


I will appreciate input on what the date ranges should be.

Here's the current logic with just the change to use Audit Period End Date.

1) If
(1 year - 30 days) < Audit Period End Date <= (1 year + 120 days)
Send Courtesy Audit Reminder
https://wiki.mozilla.org/CA/Email_templates#Courtesy_Audit_Reminder_Email_Template


So it would mail this every month, possible for 5 months. I think that's 
fine.


I think it should stop at + 90 days, because it's the overdue.


2) If
(1 year + 120 days) < Audit Period End Date <= (1 year + 240 days)
Send Overdue Audit Reminder
https://wiki.mozilla.org/CA/Email_templates#Overdue_Audit_Statement_Email_Template 


I think 240 days (8 months) is a rather long period to just say it's 
overdue. I suggest lowering that to 150 days or 180 days.



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

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

[Kurt Roeckx via dev-security-policy]

On Fri, Feb 01, 2019 at 03:02:17PM -0700, Wayne Thayer wrote:
> It was pointed out to me that the OCSP status of the misissued certificate
> that is valid for over 5 years is still "unknown" despite having been
> revoked a week ago. I asked KIR about this in the bug [1] and am surprised
> by their response:
> 
> This certificate is revoked on CRL. Because the certificate has been never
> > received by the customer its status on OCSP is "unknown". To make the
> > certificate "revoked" on OCSP first we should make it "valid" what makes no
> > sense. I know there is inconsistency between CRL and OCSP but there are
> > some scenarios when it can be insecure to make it valid just in order to
> > make it revoked.
> >
> 
> Upon further questioning KIR states:
> 
> Of course I can mark it as revoked after I make it valid, but I think it is
> > more secure practice not to change its status at all when the certificate
> > is not received by the customer. Let's suppose the scenario when your CA
> > generate certificate and the customer wants you to deliver it to its
> > office. What OCSP status the certificate should have when you are on your
> > way to the customer office? valid - I do not think so. When the certificate
> > is stolen you are in trouble. So the only option is "unknown" but then we
> > have different statuses on CRL and OCSP - but we are still safe. It is not
> > only my opinion, we had a big discuss with our auditors about that.
> >
> 
> Does anyone other then KIR and their auditor (Ernst & Young) think this is
> currently permitted? At the very least, I believe that returning "unknown"
> for a revoked certificate is misleading to Firefox users who will receive
> the "SEC_ERROR_OCSP_UNKNOWN_CERT" error instead of
> "SEC_ERROR_REVOKED_CERTIFICATE".
> 
> Does anyone other than KIR and Ernst & Young believe that this meets
> WebTrust for CAs control 6.8.12? [2]

If you follow the RFC, the "unknown" answer can mean that it
doesn't know, and that an other option like a CRL can be tried.
With "unknown", it doesn't say anything about being valid or not.

I don't think that interpretation is very useful. I think that the
OCSP server should know about the certificate before the customer
has the certificate. I think that if you have a properly signed
certificate within it's validity period, the OCSP should always
return either "good" or "revoked", never "unknown". Once a
certificate is generated and it's not revoked it's valid.

Would it be useful to have a requirement in the BRs that the OCSP
server should not answer with "unknown" for an issued certificate
within it's validity period?


Kurt

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

Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

[Kurt Roeckx via dev-security-policy]

On 2019-01-29 1:29, Wayne Thayer wrote:

Piotr just filed an incident report on the misissuance that was reported on
18-January: https://bugzilla.mozilla.org/show_bug.cgi?id=1523186


I guess this part is not very clear to me:

> We identified and removed from system the registration policy that
> issued the problematic certificate. The problematic policy template
> was not listed in policies allowed for Certificate Transparency
> logging but contained Signed Certificate Timestamp extension. The
> usage of such policy template should be blocked by the CT
> functionality. We had only one policy in such state.

I could read that as:
1) This certificate was not supposed to be logged in CT
2) The issuing should have been prevented

I assume 2) was meant.


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

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Kurt Roeckx via dev-security-policy]

On 2019-01-24 20:19, Tim Hollebeek wrote:

I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the Baseline Requirements.


The BR do not say anything about it.


It's also deprecated.  If anything, it should cease to exist.


I agree with that.


Requiring translation to a U-label by the CA adds a lot of additional complexity
with no benefit.


I have no idea what is so complex about that. When generating the 
certificate, it's really just calling a function. On the other hand, 
when reading a certificate you have to guess what they did.


And if it's really to complex, just remove the CN, or is that too 
complex too?



What users type and see are issues that are best left to Application Software
Suppliers (browsers).


So you're saying all the other software that deals with certificates 
should instead add complexity?



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

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Kurt Roeckx via dev-security-policy]

On 2019-01-24 15:41, Rob Stradling wrote:


Here's an example cert containing the A-label in the SAN:dNSName and the
U-label in the CN.  (It was issued by Sectigo, known back then as Comodo
CA, before we switched to always putting the A-label in the CN):

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

x509lint agrees with your opinion (unsurprisingly!), but both cablint
and zlint complain.


x509lint doesn't do anything related to this. I've disabled the code to 
check that the CN is one of the SANs because I didn't write the code 
related to the conversion from the U-label to the A-label yet. It used 
to behave exactly like zlint and say it doesn't match, but I think 
that's wrong. It's was clearly my intention to say that a certificate 
like that is the correct way to do it. One of the reasons I didn't do 
this is that it was not obvious to me at that time which is the correct 
standard to use, which I guess is why this thread was started.



Kurt

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

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Kurt Roeckx via dev-security-policy]

On 2019-01-24 12:08, Rob Stradling wrote:


Hi Kurt.

BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
address or Fully-Qualified Domain Name that is one of the values
contained in the Certificate’s subjectAltName extension (see Section
7.1.4.2.1)."

Fitting the U-label into subjectAltName:dNSName (an IA5String, not a
UTF8String) would be...hard, so in practice the dNSName has to contain
the A-label.

So what does "is one of the values" mean?  It's certainly valid to use
the A-label in both the CN and SAN:dNSName.  However, it's arguably
invalid (or at least it's not obviously valid) to put the A-label in the
SAN:dNSName and the corresponding U-label in the CN.  (i.e., the U-label
and the A-label are different representations of the same value, but
they are not the same value).


I expect all fields in the subject to be things you can just read, so 
U-labels. It does not make sense to show users an A-label, they do not 
understand what that means. The fields in a subject allows writing 
things in Unicode, there is no reason not to use it. The A-label is 
really just an technical thing related to DNS, and so only belongs in 
places where for technical reasons you need to use it. If you want to 
show them rfc5280 says you "should" convert them to Unicode. For fields 
where you can write Unicode, there really isn't a reason to not put the 
Unicode in it directly.


So in my opinion, the CN would be "gauß.siemens.de", and the SAN would 
be "xn--gau-7ka.siemens.de". They might add some alternatives like 
gauss.siemens.de to the SAN, and you can then also use that as CN. (But 
I think they should stop using that ss for ß, and really use gauß.)


I think that if you want to force the use of A-labels in the CN field 
that you should really update RFC5280 and X.520, so that IA5String is 
the only option in CN. But that just doesn't make any sense.



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

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Kurt Roeckx via dev-security-policy]

On 2019-01-24 9:47, Buschart, Rufus wrote:

Good morning!

I would like to sharpen my argument from below a little bit: If a CA gets a 
request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can 
the CA tell, that xn--gau-7ka is a punycode string in IDNA2008 and not only a 
very strange server name? At least I don't have a glass bowl to read the mind 
of my customers. Therefor I would say, it is perfectly okay to issue a 
certificate for xn--gau-7ka.siemens.de as long as you perform a successful 
domain validation for xn--gau-7ka.siemens.de.


Will you fill something in in the commonName? I think what is expected 
in the commonName is what the user would type and expect to see, I don't 
think the commonName should contain xn--gau-7ka.siemens.de. If you have 
a commonName, I would expect that it contains gauß.siemens.de. And if 
you create a commonName then, you are required to check that it matches 
the xn--gau-7ka.siemens.de in the SAN.



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

Re: Yet more undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2019-01-03 16:25, Jakob Bohm wrote:

There is the date fields in the SubCA certificate itself, as well as any
embedded CT data (assuming the parent CA is correctly CT-logged).


Do you expect precertificates for CA certificates?

I currently don't know if there are any requirements for logging CA 
certificates in CT. I assume it was only for subscriber certificates, 
but I didn't check what Google's current policy is. So it's possible 
that a CA certificate is only be logged the first time a subscriber 
certificate is generated.



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

Re: Online exposed keys database

[Kurt Roeckx via dev-security-policy]

On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy 
wrote:
> On 2018-12-18 11:44, Matt Palmer wrote:
> > It's currently loaded with great piles of Debian weak keys (from multiple
> > architectures, etc), as well as some keys I've picked up at various times.
> > I'm also developing scrapers for various sites where keys routinely get
> > dropped.
> 
> You might for instance also want to look at
> https://github.com/devttys0/littleblackbox, I'm not sure how useful it is.

You might also want to contact the people from
https://factorable.net/


Kurt

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

Re: Online exposed keys database

[Kurt Roeckx via dev-security-policy]

On 2018-12-19 10:55, Matt Palmer wrote:

On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy 
wrote:

On 2018-12-18 11:44, Matt Palmer wrote:

It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I've picked up at various times.
I'm also developing scrapers for various sites where keys routinely get
dropped.


You might for instance also want to look at
https://github.com/devttys0/littleblackbox, I'm not sure how useful it is.


Oh my, that's an interesting trove.  I was a bit worried at first that the
private keys weren't included, but it looks like there's at least some in
there.


I'm not sure how you feel about listing keys where you don't have the 
private key for, but are known to be compromised anyway. One potential 
source for such information might be CRLs where the reason for 
revocation was keyCompromise.


If you don't want to publish the private keys, distributing the public 
keys might be an option.



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

Re: Online exposed keys database

[Kurt Roeckx via dev-security-policy]

On 2018-12-18 11:44, Matt Palmer wrote:

It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I've picked up at various times.
I'm also developing scrapers for various sites where keys routinely get
dropped.


You might for instance also want to look at 
https://github.com/devttys0/littleblackbox, I'm not sure how useful it is.



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

Re: Incident report Certum CA: Corrupted certificates

[Kurt Roeckx via dev-security-policy]

On Tue, Dec 04, 2018 at 01:14:44PM -0500, Ryan Sleevi via dev-security-policy 
wrote:
> 
> > All issued certificates were unusable due to corrupted signature.
> >
> 
> Could you speak to more about how you assessed this? An incorrect signature
> on the CRL would not necessarily prevent the certificate from being used;
> it may merely prevent it from being revoked. That is, all 30,000 (revoked)
> certificates may have been usable due to the corrupted signature.

He explained before that the module that generated the corrupt
signature for the CRL was in a weird state after that and all
the newly issued certificates signed by that module also had
corrupt signatures.


Kurt

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

Re: Incident report Certum CA: Corrupted certificates

[Kurt Roeckx via dev-security-policy]

On 2018-12-04 10:25, Wojciech Trapczyński wrote:

On 04.12.2018 10:01, Kurt Roeckx via dev-security-policy wrote:

On 2018-12-04 7:24, Wojciech Trapczyński wrote:

Question 1: Was there a period during which this issuing CA had no
   validly signed non-expired CRL due to this incident?



Between 10.11.2018 01:05 (UTC±00:00) and 14.11.2018 07:35 (UTC±00:00) 
we were serving one CRL with corrupted signature.


Do you have any plans to prevent serving CRLs with an invalid 
signature and keep the old CRL in place until you have a valid one?


This one CRL with corrupted signature was serving between dates I 
mentioned. Starting from November 14th 07:35 (UTC±00:00) we are serving 
CRL with a valid signature. I have described it in the Bugzilla bug 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1511459#c2).


I think you misunderstood my question. I think you should never serve an 
invalid file. I think it's better to have a file that is 1 or 2 days old 
then it is to have an invalid file. So you could check that it's a valid 
file before you start serving it, and if it's invalid keep the old file.



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

Re: Incident report Certum CA: Corrupted certificates

[Kurt Roeckx via dev-security-policy]

On 2018-12-04 7:24, Wojciech Trapczyński wrote:

Question 1: Was there a period during which this issuing CA had no
   validly signed non-expired CRL due to this incident?



Between 10.11.2018 01:05 (UTC±00:00) and 14.11.2018 07:35 (UTC±00:00) we 
were serving one CRL with corrupted signature.


Do you have any plans to prevent serving CRLs with an invalid signature 
and keep the old CRL in place until you have a valid one?



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

Re: Audit Reminder Email Summary

[Kurt Roeckx via dev-security-policy]

On Tue, Oct 23, 2018 at 02:35:37PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> > > Mozilla: Audit Reminder
> > > Root Certificates:
> > > Certinomis - Root CA
> > > Standard Audit:
> > > https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
> > > Audit Statement Date: 2017-07-24
> > > BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
> > > BR Audit Statement Date: 2017-07-24
> > > CA Comments: null
> > 
> > This seems to be in French, and does not seem to even indicate
> > when the audit was done, just that the report itself is valid for
> > 2 years.
> 
> Our official requirement for the audit statements to be in English is new in
> version 2.6 of our policy (effective date July 1, 2018). Also, last July we
> were still having difficulty getting the ETSI auditors on board with
> specifying audit periods in their audit statements.

So it seems nothing changed related to this in the last month,
they are clearly late in providing a new audit statement.


Kurt

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

Re: Questions regarding the qualifications and competency of TUVIT

[Kurt Roeckx via dev-security-policy]

On 2018-10-31 16:42, Wiedenhorst, Matthias wrote:

In several emails, we answered to his complaint, explained our procedures and 
justified the classification of the encoding error as minor (non-critical) 
non-conformity.


I think we never consider encoding errors as a minor error.


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

Re: Questions regarding the qualifications and competency of TUVIT

[Kurt Roeckx via dev-security-policy]

On 2018-10-30 16:20, Ryan Sleevi wrote:

Given that the Supervisory Body and National Accreditation bodies exist to
protect the legal value of this scheme, the failure by TUVIT to uphold the
safety and security of the eIDAS regime represents an ongoing threat to the
ecosystem.


Do we have a way of verifying the accreditation, and do we verify that 
they have a valid accreditation? Should it be enough for us to check the 
accreditation, and just follow the process you are already doing?



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

Re: Audit Reminder Email Summary

[Kurt Roeckx via dev-security-policy]

On Tue, Oct 16, 2018 at 12:49:41PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
>  Forwarded Message 
> Subject: Summary of October 2018 Audit Reminder Emails
> Date: Tue, 16 Oct 2018 19:00:37 + (GMT)
> 
> Mozilla: Audit Reminder
> Root Certificates:
>AC Raíz Certicámara S.A.
> Standard Audit: 
> http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221203
> Audit Statement Date: 2017-08-09
> CA Comments: null

It covers the period of 2016-05-01 to 2017-04-30. They should have
a new audit report by now.

> Mozilla: Audit Reminder
> Root Certificates:
>Certinomis - Root CA
> Standard Audit:
> https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
> Audit Statement Date: 2017-07-24
> BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
> BR Audit Statement Date: 2017-07-24
> CA Comments: null

This seems to be in French, and does not seem to even indicate
when the audit was done, just that the report itself is valid for
2 years.


Kurt

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

Re: No Russian CAs

[Kurt Roeckx via dev-security-policy]

Probably because no Russian CA has applied to be in the root store.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kurt Roeckx via dev-security-policy]

On 2018-08-21 21:03, Kathleen Wilson wrote:

Mozilla: Overdue Audit Statements
Root Certificates:
    SwissSign Platinum CA - G2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Statement Date: 2017-03-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
BR Audit Statement Date: 2017-03-30
CA Comments: null


Is this not properly marked in the database?

I found https://bugzilla.mozilla.org/show_bug.cgi?id=1374381, which 
seems to be related to it, and was closed.


The linked audits there:
- For one claiming the period covering 2015: The statement does not 
state which period was covered.
- For one claiming the period covering 2016: The statement does not 
state which period was covered. A previous report from the auditor for 
that period stated that it was a point in time audit.
The changed report removed this sentence: "KPMG has performed a point in 
time audit. The reference date is 8 March 2017." and replaced
"We were not engaged to and did not conduct an examination, the object 
of which would be the expression of an opinion on the Application for 
Extended Validation (EV) Certificate. Accordingly, we do not express 
such an opinion. Had we performed additional procedures, other matters 
might have come to our attention that would have been reported to you"

with:
"KPMG has assessed the architecture, operation and procedures on a 
sample approach although we have not assessed every configuration 
setting on technical devices."
- The report from a new auditor covered the period: March, 9th 2017 
until June, 6th 2018, which is longer than 1 year.



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

Re: AC Camerfirma's undisclosed itermediate certificates incident report

[Kurt Roeckx via dev-security-policy]

On Thu, Aug 02, 2018 at 06:19:42AM -0700, Juan Angel Martin via 
dev-security-policy wrote:
>  
> 6) Explanation about how and why the mistakes were made or bugs introduced, 
> and how they avoided detection until now.
> 
> The procedure established to publish the CAs into CCADB wasn't correct cause 
> it didn’t foresee the contingency of the person in charge of disclosing CA’s 
> certificates into CCADB and the person acting as a backup weren’t available.

This looks like a process issue to me, and adding a 3rd person
won't fix that. The certificate should not having been used until
someone confirmed that it was done.


Kurt

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

Re: Chunghwa Telecom eCA Root Inclusion Request

[Kurt Roeckx via dev-security-policy]

On 2018-07-13 12:02, lcchen.ci...@gmail.com wrote:

We suggest that CA "in principle" must comply with the string length limit 
of RFC 5280 for organizationalUnitName or organizationName filed in Subject of a 
certificate. But if it is necessary after verification to express an organization’s name 
in the organizationalUnitName or organizationName filed of the subject field that exceeds 
the string length limit of RFC 5280, then Mozilla should not regard these special cases 
as errors of a CA. After all, X.500 standard has no limit on the length of the string, 
and let the issuing CA and the Subscriber who has accepted that SSL certificate may bear 
the possibility of any incompatibility issues.


As pointed out in the discussion, RFC 5280 itself has those limits, and 
references an older X.509 standard that also has the limits. RFC 5280 is 
what is implemented. What documents like CA/B Forum requirements or 
newer X.509 versions say is not relevant. The CA/B Forum can not remove 
requirements, only add new requirements. Implementations can and do 
implement the RFC 5280 / X.509 length limits.


If you want those lengths to be changed, an update of RFC 5280 is 
required. And it seems unlikely that this will actually get changed.



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

Re: [FORGED] TeletexString

[Kurt Roeckx via dev-security-policy]

On Sun, Jul 08, 2018 at 04:41:27PM -0400, Ryan Sleevi wrote:
> 
> Is that because you believe it forbidden by spec, or simply unwise?

It's because nobody implements the spec. Those the claim some
support for it are just broken. I have yet to see a certificate
that doesn't just put latin1 in it, which should get rejected.

rfc2459, from 1999, already said TeletexString is only for
backward compatability and you MUST switch to UTF8String by
2004, but you can keep using it forever if you established
an identity before that. Because clearly if you change the
encoding people will not recognize you anymore.

Anyway, at some point I started writing a proper parser for
teletexstring. But I don't think it's worth my time if there are 0
valid certificates using it. If someone can point me to a proper
parser of it, that is open source, I'm willing to use that.


Kurt

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

Re: [FORGED] TeletexString

[Kurt Roeckx via dev-security-policy]

On Sat, Jul 07, 2018 at 10:43:26AM +0200, Kurt Roeckx via dev-security-policy 
wrote:
> On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via 
> dev-security-policy wrote:
> > 
> > So for certlint I'd always warn for T61String with anything other than ASCII
> > (which century are they living in? Point them at UTF8 and tell them to come
> > back when they've implemented it), treat it as a probably 8859-1 string when
> > checking for validity, and report an error if they try anything like 
> > character
> > set switching and fancy escape sequences, which are pretty much guaranteed 
> > not
> > to work (i.e. display) properly.
> 
> I think it should generate an error on any character not defined
> in 102 and the space character. So any time you try to use anything
> in C0, C1 and G1, and those 6 in 102 that are not defined.

I just changed the check in x509lint to do that.


Kurt

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

Re: [FORGED] TeletexString

[Kurt Roeckx via dev-security-policy]

On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via dev-security-policy 
wrote:
> 
> So for certlint I'd always warn for T61String with anything other than ASCII
> (which century are they living in? Point them at UTF8 and tell them to come
> back when they've implemented it), treat it as a probably 8859-1 string when
> checking for validity, and report an error if they try anything like character
> set switching and fancy escape sequences, which are pretty much guaranteed not
> to work (i.e. display) properly.

I think it should generate an error on any character not defined
in 102 and the space character. So any time you try to use anything
in C0, C1 and G1, and those 6 in 102 that are not defined.


Kurt

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

Re: TeletexString

[Kurt Roeckx via dev-security-policy]

On Fri, Jul 06, 2018 at 02:43:45PM -0700, Peter Bowen via dev-security-policy 
wrote:
> In reviewing a recent CA application, the question came up of what is
> allowed in a certificate in data encoded as "TeletexString" (which is
> also sometimes called T61String).
> 
> Specifically, certlint will report an error if a TeletexString
> contains any characters not in the "Teletex Primary Set of Graphic
> Characters" unless the TeletexString contains an escape sequence. For
> example, including 'ä', or 'ö' will trigger this error unless preceded
> by an escape sequence.
> 
> In order to figure out what can be used, one need to reference X.690
> Table 3, which notes that G0 is assumed to start with character set
> 102.  Character set 102 is defined at
> https://www.itscj.ipsj.or.jp/iso-ir/102.pdf.  Note that 102 isn't the
> same as ASCII nor is it i the same as the first part of Unicode.

I'm not sure why you bring this up. Anyway, according to X.690,
the default is:

G0: 102
C0: 106
C1: 107

Or as escape sequences and locking shift:
ESC 2/8 7/5 LS0 (G0 102, locking shift 0)
ESC 2/1 4/5 (C0 106)
ESC 2/2 4/8 (C1 107)

But what is just as important is that G1 does not have a default,
while at least some people assume it's 103. While 102 is close to
ASCII, there is nothing for G1 that is close to latin1.



Kurt

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

Re: Audit Reminder Email Summary

[Kurt Roeckx via dev-security-policy]

On Tue, Jun 19, 2018 at 01:59:26PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> 
> Mozilla: Audit Reminder
> Root Certificates:
>SwissSign Platinum CA - G2
>SwissSign Silver CA - G2
> Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
> Audit Statement Date: 2017-03-30
> BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
> BR Audit Statement Date: 2017-03-30
> CA Comments: null

This was a point in time audit on 2017-03-08. They should have a
new report by now.


Kurt

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

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Kurt Roeckx via dev-security-policy]

On 2018-05-04 12:10, Tim Hollebeek wrote:

It has generally been understood that a string still "contains at least 112
bits of output from a CSPRNG" if that string has been fed through an
encoding mechanism like Base64 or Base32.

Furthermore, explicit requirements about including mixed case or special
characters leads to some very, very bad and borderline toxic security
requirements.  NIST has recently recanted and admitted they were very, very
wrong in this area and we should not repeat their mistake.

Anything we can do to clarify that an awesome password is:

string password = Base32.Encode(CSPRNG.ReadBytes(n));

where n >= 112, we should do.


Maybe you want n = 112 / 8 = 14 bytes.

> BTW United Airlines rates these sorts of passwords as "medium strength".
> Password meters that only pay attention to password complexity and not
> length are stupid.

And then you have sites that have a problem with passwords longer than 
12 characters, where you can't the base64 characters. Or where you log 
in using the number of your card and a pin number limited to 6 digits.



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

Re: 825 days success and future progress!

[Kurt Roeckx via dev-security-policy]

On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy 
wrote:
> seems
> to be mostly justified as a poor workaround for the browsers and
> certificate libraries not properly implementing reliable revocation
> checks.

The problem is not in the libraries, or even the applications
making use of them, it's that actually trying to check them is not
reliable. There are just too many cases where trying to check it
results in an error.

OCSP stapling should at least help with this. We should really
encourage people to use this, and have software enable this by
default. According to ssl-pulse 31% of the sites enable it.

There might also be library or application bugs. At least firefox
for me is annoying that if it for whatever reasons fails, it says
it's an internal server error (which as far as I know is never the
case), and then even doesn't seem to retry it and just give that
same error again.


Kurt

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

Re: Discovering unlogged certificates in internet-wide scans

[Kurt Roeckx via dev-security-policy]

On Sat, Mar 31, 2018 at 10:14:27PM +, Tim Smith via dev-security-policy 
wrote:
> Hi MDSP,
> 
> I went looking for corpuses of certificates that may not have been
> previously logged to CT and found some in the Rapid7 "More SSL" dataset,
> which captures certificates from their scans of non-HTTPS ports for
> TLS-speaking services.

Have you done the for their other scans?

There are more people that do such regular scans, and I wish they
all logged those certs as soon as they saw them.


Kurt

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

Re: Audit Reminder Email Summary

[Kurt Roeckx via dev-security-policy]

On Tue, Mar 20, 2018 at 12:07:54PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> Mozilla: Audit Reminder
> Root Certificates:
>Class 2 Primary CA
> Standard Audit:
> https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
> Audit Statement Date: 2017-01-14
> BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
> BR Audit Statement Date: 2017-01-14
> EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
> EV Audit Statement Date: 2017-01-14
> CA Comments: null

The audit period was 2015-10-14 to 2016-10-14, we should already
have received a new audit statement.


Kurt

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

Re: Code signing and malware

[Kurt Roeckx via dev-security-policy]

On Tue, Feb 27, 2018 at 12:09:01AM +0100, Jakob Bohm via dev-security-policy 
wrote:
> 
> Hence why an investigation is needed by the 3 CAs named in the paper
> (Comodo, Digicert and Apple).  They will probably have to do some deep
> log inspection to figure out patterns, besides reaching out to the
> researcher to see the raw data in confidence.

I've just tried to contact the author and hope to provide the CAs
with details.


Kurt

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

Code signing and malware

[Kurt Roeckx via dev-security-policy]

I just came across this:

https://www.recordedfuture.com/code-signing-certificates/

I think the most important part of it is: "we confirmed with a high 
degree of certainty that the certificates are created for a specific 
buyer per request only and are registered using stolen corporate identities"



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

Re: Certificates with 2008 Debian weak key bug

[Kurt Roeckx via dev-security-policy]

On 6/02/2018 17:10, Ryan Sleevi wrote:

The BRs actually seem to allow this, which at least looks like a bug in
the BRs to me.


It is allowed, and it's not a bug. It's specifically called out in 3.2.2 of
the BRs.


It seems that under 3.2.2.3 (b) they can just copy the ccTLD from the 
domain name, which seems rather useless to me.



Kurt


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

Re: Certificate for com and it

[Kurt Roeckx via dev-security-policy]

On 6/02/2018 16:52, Kurt Roeckx wrote:

On 6/02/2018 12:20, Hanno Böck wrote:

Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.


That certificate is revoked, not trusted by Mozilla or chrome.


I should probably more clear, the certificates of the CA have been revoked.


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

Re: Certificate for com and it

[Kurt Roeckx via dev-security-policy]

On 6/02/2018 12:20, Hanno Böck wrote:

Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.


That certificate is revoked, not trusted by Mozilla or chrome.


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

Re: Certificates with 2008 Debian weak key bug

[Kurt Roeckx via dev-security-policy]

On 5/02/2018 17:08, Hanno Böck wrote:

https://crt.sh/?id=308392091=ocsp


It has:
 Subject:
commonName= ftp.gavdi.pl
countryName   = PL

This looks like a combination that's not allowed. Either it's domain 
validated, in which case it should not have a countryName, or it should 
contain other fields.


The BRs actually seem to allow this, which at least looks like a bug in 
the BRs to me. It would be very handy that the OIDs from the BRs where 
used to indicate which validation was used.


It has:
X509v3 Certificate Policies:
Policy: 1.2.616.1.113527.2.5.1.9.6.3

That OID doesn't seem to be documented in the CPS.


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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Kurt Roeckx via dev-security-policy]

On Wed, Jan 10, 2018 at 01:33:20AM -0800, josh--- via dev-security-policy wrote:
> * Users have the ability to upload certificates for arbitrary names without 
> proving domain control.

So a user can always take over the domain of an other user on 
those providers just by installing a (self-signed) certificate?
I guess it works easiest if the other just doesn't have SSL.


Kurt

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

Re: Audit Reminder Email Summary

[Kurt Roeckx via dev-security-policy]

On 2018-01-04 01:36, Kathleen Wilson wrote:


Mozilla: Audit Reminder
Root Certificates:
    AC Raíz Certicámara S.A.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2120=pdf
Audit Statement Date: 2016-09-15
CA Comments: null


The audit period of that is 2015-07-01 to 2016-04-30. They clearly 
overdue, instead of just a reminder.



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

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

[Kurt Roeckx via dev-security-policy]

On Mon, Dec 25, 2017 at 07:59:12AM -0800, Peter Bowen via dev-security-policy 
wrote:
> On Mon, Dec 25, 2017 at 7:10 AM, Adrian R. via dev-security-policy
>  wrote:
> > since it's a webserver running on the local machine and is using that 
> > certificate key/pair, i think that someone more capable than me can easily 
> > extract the key from it.
> >
> > From my point of view as an observer it's plainly obvious that the private 
> > key must be on my local machine too, even if i haven't actually got to the 
> > key itself yet.
> 
> The problem is that this is not true.  I've not investigated this
> software at all, but there are two designs I have seen in other
> software:
> 
> 1) TCP Proxy: A pure TCP proxy could be forwarding all the packets to
> another host which has the key.
> 
> 2) "Keyless" SSL: https://www.cloudflare.com/ssl/keyless-ssl/ - they
> key is on a different host from the content
> 
> I'm sure there are other designs which would end up with the same
> result: 127.0.0.1 does not have the private key.  Given this,
> conjecture that there "must" be a private key compromise seems
> exaggerated.

In theory it could also be something like Intel SGX, but that seems
very unlikely.


Kurt

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

Re: On the value of EV

[Kurt Roeckx via dev-security-policy]

On Mon, Dec 18, 2017 at 03:04:11PM -0800, Ian Carroll via dev-security-policy 
wrote:
> 
> I do wonder how many users actually make the connection that the country code 
> next to the company name is in fact a country code.

And even if you do make the connection, it's not always obvious
even in which country a company is located. I guess for some, like
your bank or some local shop, it's obvious. For others it's not.


Kurt

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

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

[Kurt Roeckx via dev-security-policy]

On Fri, Dec 08, 2017 at 11:55:46PM +0100, Hanno Böck via dev-security-policy 
wrote:
> So I wonder: If a CA signs an intermediate - are they responsible
> making sure that reports brought to the subca are properly handled?

My first reaction would be if you sign it, you take
responsibility. That would be either handling it yourself, or
making sure that it's handled properly by the intermediate.

But it's not obvious to me who to contact to revoke a given
certifiate, and it would be really useful that given a certificate
it would be obvious what to do, who to contact, to get it revoked.


Kurt

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

Re: DigiCert ROCA fingerprint incident report

[Kurt Roeckx via dev-security-policy]

Hi,

What I miss is what has been done to prevent new ones from being
issued.


Kurt

On Tue, Nov 07, 2017 at 06:20:53PM +, Jeremy Rowley via dev-security-policy 
wrote:
> Hey everyone, 
> 
>  
> 
> Here's the DigiCert incident report about the ROCA fingerprints. Note that
> these were all issued by Symantec (ie, before the transaction closed).
> 
>  
> 
> We became aware of the issue when it was posted to the mailing list.
> However, at that time, the certs were not operated by DigiCert. We became
> aware that DigiCert needed to take action on close (Nov 1).  At that time,
> the new combined team launched an investigation to determine the impacted
> certs. Six certs were identified and revoked:
> 
>  
> 
> 
> 4a907fbfc90eb043c50c9c8ace6305a1
> 
> 
> 8008c178d0d4cd3d79acc09f6ac132c
> 
> 
> 2dab9a2d40a2f55c5d705551cf7cafe5
> 
> 
> 306b67f5c25ee0fd495d2be88979eb72
> 
> 
> 7c7b826b183093ba1e5b9850ac31d806
> 
> 
> 4c834767e44ecbd0cdef8e60c04dcf32
> 
>  
> 
> These certs were all revoked around Nov 3, within 24 hours of identifying
> the impacted certs at DigiCert. 
> 
>  
> 
> Jeremy
> 



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

[Kurt Roeckx via dev-security-policy]

On 2017-08-29 14:47, Paul Kehrer wrote:

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."


I have to wonder why you were able to find so many. Is this not covered 
in the audit?



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

[Kurt Roeckx via dev-security-policy]

On 2017-08-30 08:46, Adriano Santoni wrote:
 >>  - 2 are technically constrained sub-CAs ( 
https://crt.sh/?id=147626411 / https://crt.sh/?id=47081615 )


Those two are actually the same certificate; it's not clear to me why 
they appear twice on crt.sh


I didn't look if all the name constrains match, but they're at least in 
a different order.



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

Re: AC FNMT Usuarios and anyExtendedKeyUsage

[Kurt Roeckx via dev-security-policy]

On 2017-08-18 16:01, Eric Mill wrote:

Hi Jose,

There was no attachment to your email. Would you mind re-sending with an
attachment?


Attachments never make it to the list.


Kurt

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

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

[Kurt Roeckx via dev-security-policy]

On Fri, Aug 11, 2017 at 11:48:50AM -0400, Ryan Sleevi via dev-security-policy 
wrote:
> On Fri, Aug 11, 2017 at 11:40 AM, Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor  wrote:
> > > Given that these were all caught by cablint, has Let's Encrypt considered
> > > integrating it into your issuance pipeline, or automatically monitoring
> > > crt.sh (which runs cablint) for these issues so they don't need to be
> > > caught manually by researchers?
> >
> > The former has the risk of being unexpectedly fragile,
> 
> 
> Could you expand on this? It's not obvious what you mean.
> 
> 
> > This way: If cablint breaks, or won't complete in a timely fashion during
> > high volume issuance, it doesn't break the CA itself. But on the other hand
> > it also doesn't wail on Comodo's generously offered public service crt.sh.
> >
> 
> Could you expand on what you mean by "cablint breaks" or "won't complete in
> a timely fashion"? That doesn't match my understanding of what it is or how
> it's written, so perhaps I'm misunderstanding what you're proposing?

My understand is that it used to be very slow for crt.sh, but
that something was done to speed it up. I don't know if that change
was something crt.sh specific. I think it was changed to not
always restart, but have a process that checks multiple
certificates.


Kurt

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

Re: Certificates with common names not present in their SANs

[Kurt Roeckx via dev-security-policy]

On Sat, Aug 05, 2017 at 02:36:14PM -0700, alex.gaynor--- via 
dev-security-policy wrote:
> - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the 
> SAN

I think that's actually correrct?


Kurt

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

Re: StartCom cross-signs disclosed by Certinomis

[Kurt Roeckx via dev-security-policy]

On Thu, Aug 03, 2017 at 01:43:08PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> On Thursday, August 3, 2017 at 9:49:41 AM UTC-7, Jonathan Rudenberg wrote:
> > Even absent the BR-violating certificates and disclosure timeline, I 
> > believe this cross-sign is problematic because it appears to circumvent the 
> > prerequisites and process described in 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 for StartCom’s 
> > application for re-inclusion into the Mozilla root store. It’s not clear to 
> > me what the point of those requirements is if they can be avoided by 
> > obtaining cross-signatures from other CAs that are currently trusted by 
> > Mozilla.
> 
> It is common practice for a CA to get cross-signed by a currently-included 
> CA, so their cert chain is trusted while they are going through Mozilla's 
> long inclusion process. This is OK, as long as the currently-included CA 
> ensures that the subCA follows Mozilla's Root Store Policy.
> See section 5.3 of 
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

I would really like to see that they have at least opened a bug to
request the inclusion of that CA before it's cross-signed. It should
have already all the requirements that Mozilla has for including the
root CA certificate before it's cross signed.

I would prefer that it's even included in the Mozilla root store
before it's cross signed, or that it's been added to one of the
other root stores.


Kurt

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

Re: Bad characters in dNSNames

[Kurt Roeckx via dev-security-policy]

On 2017-07-26 12:21, Rob Stradling wrote:
At Jonathan's suggestion, I've used the crt.sh DB to produce this report 
of certs that have SAN:dNSName(s) that contain non-permitted characters:


The report says "CN or dNSName". It's my understanding that in the CN 
you can have international characters but that in the SAN you can't. Can 
you clarify that it's really only the SAN that you checked?



Kurt

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

Re: Miss-issuance: URI in dNSName SAN

[Kurt Roeckx via dev-security-policy]

On Tue, Jul 25, 2017 at 12:57:44PM -0400, Alex Gaynor via dev-security-policy 
wrote:
> Following up on this (and really several other threads). The BRs require
> mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
> are required to track m.d.s.p. per the Mozilla Root Policy, so really
> notifying this list _ought_ to qualify as notifying the CAs.

I think requests for revocation should be done using the contact
information they provided to do that.


Kurt

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

Re: How long to resolve unaudited unconstrained intermediates?

[Kurt Roeckx via dev-security-policy]

On Wed, Jul 12, 2017 at 12:12:13PM -0400, Ryan Sleevi wrote:
> 
> Consider, for example, a client that does not support path discovery
> (which, for example, includes most actively-deployed OpenSSL versions). If
> one were to extract certdata.txt into trust and distrust records, with the
> algorithm that OpenSSL uses, this would actively break connections to a
> number of sites, as it would encounter the distrusted certificates and
> cease path building. Mozilla Firefox, on the other hand, uses mozilla::pkix
> and implements a robust path discovery mechanism - the presence of a
> distrust record will have it 'unwind' on path discovery and continue trying
> alternative paths.
> 
> One can see this having played out in other situations in the past as well
> - such as Red Hat's decision to (temporarily) ship 1024-bit roots that were
> removed from the Mozilla Root CA store, due to their need to support
> OpenSSL clients that could not build alternative paths to the (included)
> 2048-bit roots.
> 
> In this sense, by keeping them separated - into certdata.txt and OneCRL -
> Mozilla is able to ensure certdata.txt is more usable by these clients.
> Including them in certdata.txt, while certainly more complete and
> comprehensive, would conversely mean more clients would break when
> consuming certdata.txt - or, if Mozilla were to try to maintain
> certdata.txt as an 'interoperable source of truth', would prevent the
> necessary changes to ensure users are safe.
> 
> Further, consider that while the use of OCSP or CRLs, and in particular,
> hard fail, is unsuitable for a client such as Mozilla Firefox, other
> products may have different requirements for both performance and
> availability. For example, for a mutually authenticating batch processing
> system, the additional latency and/or unreliability imposed by these
> revocation checking methods is not as significant to the overall product
> flow, and thus offers a better alternative than relying on either OneCRL or
> certdata.txt updates.
> 
> Because the situation varies by client - and, again, I want to stress that
> a "Web PKI" client that wishes to remain interoperable with 'the browsers'
> truly needs to be using the same code as 'the browsers' (and this is true
> across all major browser platforms) - keeping it distinct best serves the
> needs of various consumers, and allows the few distrust records included to
> be ones that minimize the large-scale compatibility impact that might
> otherwise be introduced.

So I think what you're saying is that adding it to certdata.txt
might result in it breaking for for non-browsers while it might
keep working for browsers because they behave better, and so you
prefer adding it to OneCRL.

I'm interested in having OpenSSL behave more like the browsers,
and so maybe some of the points you're making might not apply
in the future anymore.

You could argue that it's a bug in the other implementations that
they can't deal with it, and that you should not restrict what is
in certdata.txt to what all consumers of it can handle.


Kurt

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

Re: How long to resolve unaudited unconstrained intermediates?

[Kurt Roeckx via dev-security-policy]

On 2017-07-12 16:12, Ryan Sleevi wrote:

I don't know if this currently happens, but I would like to see all CA
certificates that are in OneCRL but are not revoked to be added to the root
store as distrusted too.



Why? I can share reasons why it might not be desirable, but rather than
start out negatively, I was hoping you could expand upon the reasons for
including.


My understanding is that certdata.txt is what is the trust of the root 
store is, and that OneCRL is mostly a browser only thing to get 
revocation information, but is also (ab)used to distrust something.


The certdata.txt currently does explicitly list CA certificates that 
shouldn't be trusted.


As far as I know external user of the trust information currently only 
use certdata.txt. So only adding it to OneCRL will not reach all the 
users of the trust store.


It could be that maybe the combination is what should be used, but as 
far as I know it's not documented as such and I doubt it gets used much 
outside Mozilla products.



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

Re: How long to resolve unaudited unconstrained intermediates?

[Kurt Roeckx via dev-security-policy]

On 2017-07-11 15:56, Nick Lamb wrote:

On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx  wrote:>

So at least some of them have been notified more than 3 months ago, and
a bug was filed a month later. I think you already gave them too much
time to at least respond to it, and suggest that you sent a new email
indicating that if they don't respond immediately that they will get
added to OneCRL.


Agreed. It may also make sense to add telemetry that allows Mozilla to 
determine whether listing such subCAs in the OneCRL are ever actually blocking 
anything. This makes  a difference in my opinion as to the severity of the 
breach of policy by the CA in question.


I don't know if this currently happens, but I would like to see all CA 
certificates that are in OneCRL but are not revoked to be added to the 
root store as distrusted too.



Kurt

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

Re: How long to resolve unaudited unconstrained intermediates?

[Kurt Roeckx via dev-security-policy]

On 2017-07-10 18:35, Alex Gaynor wrote:

Hi all,

I wanted to call some attention to a few intermediates which have been
hanging out in the "Audit required" section for quite a while:
https://crt.sh/mozilla-disclosures#disclosureincomplete

Specifically, the TurkTrust and Firmaprofesional ones. Both have issues
open in Bugzilla:

- https://bugzilla.mozilla.org/show_bug.cgi?id=1367842
- https://bugzilla.mozilla.org/show_bug.cgi?id=1368171

However, neither appears to have seen any attention from the CAs in the
past two months.

Section 5.3.2 of the Mozilla Root Policy says they have a week to disclose
the cert, however I'm a bit less clear on on what timeline they're required
to provide the audit statements.


We have a template for reminding about missing audits here: 
https://wiki.mozilla.org/CA:Email_templates#Disclosure_Incomplete_Email_Template


As far as I know, this was first sent on the 3rd of April, see the 
thread with subject: "Automated email reminders about intermediate certs 
missing audit or CP/CPS". I don't think such reminders were sent a 
second time.


So at least some of them have been notified more than 3 months ago, and 
a bug was filed a month later. I think you already gave them too much 
time to at least respond to it, and suggest that you sent a new email 
indicating that if they don't respond immediately that they will get 
added to OneCRL.



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

Re: P-521

[Kurt Roeckx via dev-security-policy]

On Tue, Jun 27, 2017 at 10:41:49AM -0700, Gervase Markham wrote:
> On 27/06/17 07:17, Kurt Roeckx wrote:
> > I suggest you keep it for now.
> 
> An opinion without a rationale is not all that useful :-)

A lot of software supports it, including NSS / Firefox. It's not
an ideal curve, and it should get replaced, but it's currently
better to have it then not.

I currently only count 222 certificate using P-521 that chain to
the Mozilla root store, and I guess some of those would fall back
to RSA.

I see no reason to say that they shouldn't be used at this time.


Kurt

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

Re: P-521

[Kurt Roeckx via dev-security-policy]

On 2017-06-27 15:51, Gervase Markham wrote:

This issue seems to come up regularly, and I can never find the
discussion I'm sure we had about it, so I'm starting a thread here with
"P-521" in the subject so it'll be clear.

Should we be permitting use of this curve in our policy?


I suggest you keep it for now.

You should probably allow ed25519 and ed448.


Kurt

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

Re: Unknown Intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-23 14:59, Rob Stradling wrote:

Reasons:
   - Some are only trusted by the old Adobe CDS program.
   - Some are only trusted for Microsoft Kernel Mode Code Signing.
   - Some are very old roots that are no longer trusted.


I wonder if Google's daedalus would like to see some of those.


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

Re: New undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-08 14:09, wiz...@ida.net wrote:

But Censys lists it as a trusted intermediate chaining to a root ( 
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS:

https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation


I got confused by crt.sh, it's not obvious if a certificate is in some 
root store or not. They have an other certificate 
(https://crt.sh/?q=ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa) 
for the same CA that is in the root store.


I have no idea what common implementations do when trying to validate a 
chain with such certificate in the middle.



With respect to Gerv's question: given the ample time to disclose 
intermediates, and given all CAs in the program indicated that they had, seems 
reasonable to immediately add undisclosed ones that are discovered to OneCRL. 
Other than some breakage, as already noted, main downside would seem to be 
potentially large growth in OneCRL.


I think there are 2 solutions: OneCRL or a whitelist. OneCRL is probably 
easier to do, no new code would need to be written in the browser or 
NSS. A whitelist would mean that that list would need to get updated 
regularly and that list is probably larger.



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

Re: New undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-08 14:16, Rob Stradling wrote:
crt.sh collates revocation information from all known CRL Distribution 
Point URLs for each CA.  The CDP URLs listed at 
https://crt.sh/?id=12729173 were observed in other certs issued by the  > same CA:


That shows:
http://www.cert.fnmt.es/crls/ARLFNMTRCM.crl

But tries to use:
http://www.cert.fnmt.es.testa.eu/crls/ARLFNMTRCMEU.crl


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

Re: New undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-08 13:31, richmoor...@gmail.com wrote:

This one is interesting since the domain name of the CRL resolves to an RFC 
1918 IP address. Surely that is a violation of the baseline requirements.

https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca


That seems to be a root CA. It does not mention any CRL. I don't expect 
a root CA to have a CRL. I'm not sure from where crt.sh is getting the 
CRL URL.



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

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Kurt Roeckx via dev-security-policy]

On Fri, Jun 02, 2017 at 04:50:44PM +0100, Gervase Markham wrote:
> On 02/06/17 12:24, Kurt Roeckx wrote:
> > Should that be "all certificates" instead of "all SSL certificates"?
> 
> No; the Baseline Requirements apply only to SSL certificates.

Then I don't understand what you're trying to do. If the BR
already apply to all SSL certificates, why would Mozilla need to
override this and say it applies to all SSL certificates?

The BR are at least confusing to what they claim to be about. The
title of the document says "for the issuance and management of
pubicly-trusted certificates". In the "notice to readers" they say
it's about server authentication, and seem to imply it doesn't
cover "web services", code signing, smime, ...

Maybe you want to say it also applies to client authentication?

I also think it's wrong to say it just applies to SSL
certificates, it also applies to at least the intermediate
CAs.

I also see very little reason why the BRs couldn't be applied to
all certificates if the put some effort in making the BRs actual
baseline requirements. About the only thing in the BRs that don't
apply to all certificates are the SAN requirements and things
related to having control over the domain name. It shouldn't be
that hard to move those things to a separate document instead.


Kurt

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

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Kurt Roeckx via dev-security-policy]

On 2017-06-02 12:28, Gervase Markham wrote:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla expects
CA operations relating to issuance of all SSL certificates in the scope
of this policy to conform to the Baseline Requirements."


Should that be "all certificates" instead of "all SSL certificates"?


Kurt

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

Re: StartCom issuing bogus certificates

[Kurt Roeckx via dev-security-policy]

On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via dev-security-policy 
wrote:
> The point is that "misissuance" of example.com is harmless as they are 
> reserved by IANA.

But example.com is a real domain that that even has an https
website. The certificate is issued by digicert, and the subject
says it's to ICANN. If the certificate is not requested by IANA
or ICANN nobody should issue a certificate for it.


Kurt

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

Re: Google Plan for Symantec posted

[Kurt Roeckx via dev-security-policy]

On Mon, May 22, 2017 at 05:33:26PM +0100, Gervase Markham via 
dev-security-policy wrote:
> Google are doing a phased distrust of old certs, but they have not set a
> date in their plan for total distrust of the old PKI. We should ask them
> what their plans are for that.

My understanding is that Google will rely on CT for it and
don't need to distrust anything. Either it's in CT and we
can check what they did, or it's not and it's not trusted.


Kurt

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

Re: Google Plan for Symantec posted

[Kurt Roeckx via dev-security-policy]

On Fri, May 19, 2017 at 01:04:45PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> 
> Gerv, thank you for all the effort you have been putting into this 
> investigation into Symantec's mis-issuances, and in identifying the best way 
> to move forward with the primary goal being to help keep end-users safe.
> 
> I fully support requiring Symantec to set up a new PKI on new infrastructure, 
> and to transition to it in phases, in order to minimize the impact and reduce
> the risk for end-users.
> 
> I think the general direction is correct, but I think there are a few details 
> to be ironed out, such as:
> 
> - What validity periods should be allowed for SSL certs being issued in the 
> old PKI (until the new PKI is ready)? I prefer that this be on the order of 
> 13 months, and not on the order of 3 years, so that we can hope to distrust 
> the old PKI as soon as possible. I prefer to not have to wait 3 years to stop 
> trusting the old PKI for SSL, because a bunch of 3-year SSL certs get issued 
> this year.

So I think we have a few categories of certificates:
- Those issued in the past, which can still be valid for up to 3
  years. I'm not sure when the last 5 year certificates are
  supposed to expire, or if they all expired, but I don't think
  those take long to expire.
- Those that still get issued before they move to some new PKI.

If you want to distrust their existing roots before those
certificates expire, this will most likely results in at least
some people having problems. And that it would be up to Symantec
to make sure those people get new certificates and started using
them.

>From the mail about Chrome's plan, I understand that Chrome's plan
is to only allow certificates from the old PKI if they qualify for
their CT requirements. They plan to only allow certificates issued
after 2016-06-01 because that's the date when they required CT
from Symantec. It seems that Symantec can still issue new certificates
using the old PKI up to 2017-08-08 that are still valid for 3
years.

I'm a little concerned that Firefox and Chrome will have different
certificates they don't trust, and would hope that you can come to
some agreement about when which one would get distrusted.

> - Perhaps the new PKI should only be cross-signed by a particular 
> intermediate cert of a particular root cert, so that we can begin to distrust 
> the rest of the old PKI as soon as possible.

I'm not really sure what you're saying here. If the new PKI is
signed by an other CA, does it matter if it's signed by their
root CA or some (dedicated) intermediate? I don't see how that
relates to distruting the old PKI.

I have a problem with one CA signing an other unrelated CA. I
would prefer that we have a policy that forbids that, and that the
CA should make sure it's own root gets added to the root store.
The only reason I can see for cross signing is for people that still
using an old root store.

> - I'm not sold on the idea of requiring Symantec to use third-party CAs to 
> perform validation/issuance on Symantec's behalf. The most serious concerns 
> that I have with Symantec's old PKI is with their third-party subCAs and 
> third-party RAs. I don't have particular concern about Symantec doing the 
> validation/issuance in-house. So, I think it would be better/safer for 
> Symantec to staff up to do the validation/re-validation in-house rather than 
> using third parties. If the concern is about regaining trust, then add 
> auditing to this.

So they should just create new root CAs and ask them to be
included in the root store?


Kurt

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

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Kurt Roeckx via dev-security-policy]

On 2017-05-19 14:18, Gervase Markham wrote:

Ryan Sleevi suggested a wording clarification/policy extension to the
multi-factor auth requirement, from:

"enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance"

to

"enforce multi-factor authentication for all accounts capable of causing
certificate issuance or performing validation functions"

The goal here was to cover RAs performing validation functions. Although
we are moving towards not permitting third parties to perform domain or
IP address ownership validation, it still seems to be to be a good
improvement that accounts involving certificate issuance or the input of
data into what will become an issued certificate should be multi-factor
protected.


I'm wondering why something like this should be in the Mozilla policy 
and not be part of something else that they get audited for.



Kurt


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