Microsoft to remove WoSign and StartCom certificates in Windows 10

[Percy via dev-security-policy]

https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/

Microsoft has concluded that the Chinese Certificate Authorities (CAs) WoSign 
and StartCom have failed to maintain the standards required by our Trusted Root 
Program. Observed unacceptable security practices include back-dating SHA-1 
certificates, mis-issuances of certificates, accidental certificate revocation, 
duplicate certificate serial numbers, and multiple CAB Forum Baseline 
Requirements (BR) violations.

Thus, Microsoft will begin the natural deprecation of WoSign and StartCom 
certificates by setting a “NotBefore” date of 26 September 2017. This means all 
existing certificates will continue to function until they self-expire. Windows 
10 will not trust any new certificates from these CAs after September 2017.

Microsoft values the global Certificate Authority community and only makes 
these decisions after careful consideration as to what is best for the security 
of our users.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Peter Gutmann via dev-security-policy]

Matthew Hardeman via dev-security-policy 
 writes:

>I merely raise the point that IF the framers of the 20 bytes rule did, in
>fact, simultaneously intend that arbitrary SHA-1 hash results should be able
>to be stuffed into the serial number field AND SIMULTANEOUSLY that the DER
>encoded integer field value must be a positive integer and that insertion of
>a leading 0x00 byte to ensure that the high order bit would be 0 (thus
>regarded as a positive value per the coding), THEN it must follow that at
>least in the minds of those who engineered the rule, that the inserted 0x00
>byte must not be part of the 20 byte maximum size of the value AS legitimate
>SHA-1 values of 20 bytes do include values where the high order bit would be
>1 and without pre-padding the proper interpretation of such a value would be
>as a negative integer.

That sounds like sensible reasoning.  So you need to accept at least 20 + 1
bytes, or better yet just set it to 32 or 64 bytes and be done with it because
there are bound to be implementations out there that don't respect the 20-byte
limit.  At the very least though you'd need to be able to handle 20 + 1.

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

RE: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

24 hours is super short when it's a Saturday morning at 4 am and it’s a 
European government entity. I agree that is what the policy says now, but, for 
lower risk items, the policy should change, preferably to at least one business 
day. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Tuesday, August 8, 2017 12:46 PM
To: Jakob Bohm 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

It's from the BRs 4.9.1.1:

 The CA SHALL revoke a Certificate within 24 hours if one or more of the 
following occurs:

It's also not a penalty on the CA, it's a remediation step for them to 
undertake.

Alex

On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Some people seemed to require 24-hour revocation of these, which I 
> also find possibly excessive.
>
> On 08/08/2017 20:28, Alex Gaynor wrote:
>
>> I think you're largely objecting to a strawman, no one is proposing 
>> revoking trust in any of these threads.
>>
>> The only CAs that have ever had _any_ penalty applied to them have 
>> been for grotesque abuse of the trust vested in them.
>>
>> Alex
>>
>> On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy < 
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> On 08/08/2017 18:43, Ryan Sleevi wrote:
>>>
>>> On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:

 I was not advocating "letting everyone decide".  I was advocating 
 that
> Mozilla show some restraint, intelligence and common sense in 
> wielding the new weapons that certlint and crt.sh have given us.
>
> This shouldn't be race as to who wields the weapon first, 
> forgiving CAs only if they happen to report faster than some other 
> newsgroup participant.
>
> This is similar to if a store boss gets a new surveillance camera 
> in the shop and sees that some employees are taking extra breaks 
> when there are few customers in the store.  It would be 
> unreasonable for such a store boss to discipline this with similar 
> zeal as seeing some employees genuinely steeling cash out of the 
> register or selling stolen items out of the back door.  Instead 
> the fact that they work less when there is less work to do should 
> inspire reevaluation of any old rule that they are not allowed to 
> have a watercooler chat during work hours.
>
> Now such a reevaluation might result in requiring them to use such 
> occasions to clean the floors or do some other chores (Mozilla equiv:
> Deciding that the rule is important for good reason and needs to 
> be followed in the future) or it could result in relaxing the rule 
> as long as they stand ready the moment a customer arrives (Mozilla equiv:
> Relaxing the requirement, initially just for Mozilla, later 
> perhaps as a BR change).
>
> Dogmatically insisting on enforcing rules that were previously not 
> enforced due to lack of detection, just because "rules are rules" 
> or other such arguments seems overzealous.
>
>
> Such tools have been available for over a year. CAs have been 
> aware of
 this, the ability to run it over their own corpus and self-detect 
 and self-report. These tools, notably, were created by one of the 
 newest CA applicants - Amazon - based on a methodical study of what 
 is required of a CA.

 Your attempts to characterize it as overzealous ignore this 
 entirely. At this point, it's gross negligence, and attempts to 
 argue otherwise merely suggest a lack of understanding or concern 
 for standards compliance and interoperability.

 Mozilla has already communicated to CAs these tools exist and their 
 relevance to CAs.

 Perhaps we can move on from misguided apologetics and instead focus 
 on how to make things better. Suggestions we ignore these, at this 
 point, are neither productive nor relevant. Attempts to suggest 
 tortured metaphors are like attempting to suggest rich people 
 deserve to be robbed, or poor people just need to work harder - 
 arguments that are both hollow and borderline offensive in their 
 reductionism. A pattern of easily preventable misissuance has been 
 happening,CAs have been repeatedly told to self-detect, and 
 clearly, some CAs, like presumably some businesses, aren't taking 
 security seriously. That needs to stop.


 I am questioning the fairness of applying these tools, which did 
 not
>>> exist when the rules were written, to enforce every rule with the 
>>> same high weight.  I am not apologizing for bad behavior, I am 
>>> saying if everybody gets scrutinized this hard, we will eventually 
>>> have to distru

RE: High traffic on this list, and Mozilla root program involvement

[Jeremy Rowley via dev-security-policy]

Do you want that added as a new bug for all the issues listed?  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Tuesday, August 8, 2017 10:02 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: High traffic on this list, and Mozilla root program involvement

Hi everyone,

Wow, traffic on this group has exploded :-) Thank you to everyone who has
been bringing incidents to our attention.

Clearly, many of these items need official responses and action from
representatives of the Mozilla root program. I have been on holiday quite a
lot recently, and that includes this week, and any time I have had has been
fighting fires relating to my other responsibilities and requirements placed
on me. But please rest assured, all this has not been forgotten.

In the mean time, I would hope CAs would be picking up incidents relating to
themselves, doing investigations and publishing best-practice-style incident
reports here once those investigations were concluded. I probably need to
write a wiki page on this, but in brief best practice involves much more
than "we revoked the certificates concerned", it needs to say "this is how
this happened", and "this is what we've done/are doing to make sure it won't
happen again".

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[identrust--- via dev-security-policy]

On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
> that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
> required to have the plaintext HTTP scheme according to Baseline Requirements 
> section 7.1.2.2(c).
> 
> Here’s the list of certificates: https://misissued.com/batch/4/
> 
> Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[identrust--- via dev-security-policy]

On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy 
> >  wrote:
> > 
> > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
> >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder 
> >> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI 
> >> is required to have the plaintext HTTP scheme according to Baseline 
> >> Requirements section 7.1.2.2(c).
> >> 
> >> Here’s the list of certificates: https://misissued.com/batch/4/
> >> 
> >> Jonathan
> > 
> > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in this 
> > context.  That being said, we have altered our profiles for certificates 
> > issued under this Sub CA to include only HTTP OCSP URLs.  All certificates 
> > issued going forward will contain an HTTP OCSP URL.  We will also examine 
> > all 
> > other sub CA to ensure only HTTP OCSP URLs are included.  Thank you for 
> > giving 
> > us an opportunity to address this with the community
> 
> Thanks for the update.
> 
> Can you also clarify why the subject organizationName is "U.S. Government” 
> for all of these certificates, despite the other subject fields indicating 
> organizations that are not a component of the US Government?
> 
> Jonathan

Yes,
IdenTrust ACES SSL Certificates are issued in accordance with the ACES
certificate policy defined by U.S. General Service Administration 
(http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/documents/ACES-CP-v3-2_signed_05122017.pdf)
 
and the GSA approved IdenTrust CPS
(https://secure.identrust.com/certificates/policy/aces/IdenTrust_ACES_CPS_v5.1_20161110.pdf)
These ACES SSL certificates are issued to either U.S. Government agencies
and/or their sub-contractors in support of government programs\projects.  The
CP requires an approved CA, such as IdenTrust, to identify U.S. Government in
subject organizationName along with other applicable organizations (e.g.
sub-contractors, or local government agency, etc...).
Marco Schambach
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[identrust--- via dev-security-policy]

On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy 
> >  wrote:
> > 
> > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
> >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder 
> >> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI 
> >> is required to have the plaintext HTTP scheme according to Baseline 
> >> Requirements section 7.1.2.2(c).
> >> 
> >> Here’s the list of certificates: https://misissued.com/batch/4/
> >> 
> >> Jonathan
> > 
> > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in this 
> > context.  That being said, we have altered our profiles for certificates 
> > issued under this Sub CA to include only HTTP OCSP URLs.  All certificates 
> > issued going forward will contain an HTTP OCSP URL.  We will also examine 
> > all 
> > other sub CA to ensure only HTTP OCSP URLs are included.  Thank you for 
> > giving 
> > us an opportunity to address this with the community
> 
> Thanks for the update.
> 
> Can you also clarify why the subject organizationName is "U.S. Government” 
> for all of these certificates, despite the other subject fields indicating 
> organizations that are not a component of the US Government?
> 
> Jonathan

Yes,
IdenTrust ACES SSL Certificates are issued in accordance with the ACES 
certificate policy defined by U.S. General Service Administration 
(http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/documents/ACES-CP-v3-2_signed_05122017.pdf)
 and the GSA approved IdenTrust CPS 
(https://secure.identrust.com/certificates/policy/aces/IdenTrust_ACES_CPS_v5.1_20161110.pdf)
 
These ACES SSL certificates are issued to either U.S. Government agencies 
and/or their sub-contractors in support of government programs\projects.  The 
CP requires an approved CA, such as IdenTrust, to identify U.S. Government in 
subject organizationName along with other applicable organizations (e.g. 
sub-contractors, or local government agency, etc...).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SSL.com root inclusion request

[Aaron Wu via dev-security-policy]

This request from SSL.com is to include the “SSL.com Root Certification 
Authority RSA”, “SSL.com Root Certification Authority ECC”, “SSL.com EV Root 
Certification Authority RSA”, and “SSL.com EV Root Certification Authority ECC” 
root certificates, turn on the Email and Websites trust bits for the two non-EV 
roots, turn on the Websites trust bit for the two EV roots, and enable EV 
treatment for the two EV roots.

SSL.com is a commercial organization that provides digital certificates in over 
150 countries worldwide, with the goal of expanding adoption of encryption 
technologies and best practices through education, tools and expertise.

The request is documented in the following bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1277336

BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8881939

Summary of Information Gathered and Verified: 
https://bugzilla.mozilla.org/attachment.cgi?id=8895068


* Root Certificate Download URL: 
RSA: https://www.ssl.com/repository/SSLcomRootCertificationAuthorityRSA.cer
ECC: https://www.ssl.com/repository/SSLcomRootCertificationAuthorityECC.cer
EV RSA R2: hhttps://www.ssl.com/repository/SSLcom-RootCA-EV-RSA-4096-R2.pem
EV ECC: www.ssl.com/repository/SSLcomEVRootCertificationAuthorityECC.cer


* Documents are in English
https://www.ssl.com/repository/ 
CP/CPS: https://www.ssl.com/app/uploads/2017/06/SSLcom_CP_CPS_Version_1_2_1.pdf 

* CA Hierarchy: 
The SSL.com root certificates currently only have internally-operated 
intermediate certificates. These root certs have not been cross-signed by any 
other CA. It is possible that these root certs may issue externally operated 
subCA in the future, but SSL.com states that they will comply to Mozilla's Root 
CA Program and be either technically constrained or publicly disclosed and 
audited.

* This request is to turn on the Email and Websites trust bits for the two 
non-EV roots, turn on the Websites trust bit for the two EV roots, and enable 
EV treatment for the two EV roots.

** Organization and Identity Verification Procedures are described in section 
3.2 of the CP/CPS.
Section 3.2.2.1: If the Subject Identity Information is to include the name or 
address of an organization, SSL.com shall verify the identity and address of 
the Applicant. This verification shall use documentation provided by, or 
through communication with, at least one of the following:
1) A government agency in the jurisdiction of the Applicant’s legal creation, 
existence, or recognition;
2) A third party database that is periodically updated and considered a 
Reliable Data Source as defined in Section 3.2.2.7;
3) A site visit by SSL.com or a third party who is acting as an agent for 
SSL.com; or
4) An Attestation Letter, as defined in Section 1.6.1
SSL.com may use the same documentation or communication described in 1) through 
4) above to verify both the Applicant’s identity and address.
Alternatively, SSL.com may verify the address of the Applicant (but not the 
identity of the Applicant) using a utility bill, bank statement, credit card 
statement, government-issued tax document, or other form of identification that 
SSL.com determines to be reliable.

** Section 3.2.2.4 defines the permitted processes and procedures for 
validating the Applicatn’s ownership or control of the domain. Please see the 
CP/CPS for further details in each section.
*** 3.2.2.4.1 Validating the Applicant as a Domain Contact
Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact directly with the Domain Name Registrar.
*** 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
Confirming the Applicant's control over the FQDN by sending a Random Value via 
email, fax, SMS, or postal mail and then receiving a confirming response 
utilizing the Random Value. The Random Value MUST be sent to an email address, 
fax/SMS number, or postal mail address identified as a Domain Contact.
*** 3.2.2.4.3 Phone Contact with Domain Contact
Confirming the Applicant's control over the requested FQDN by calling the 
Domain Name Registrant's phone number and obtaining a response confirming the 
Applicant's request for validation of the FQDN. SSL.com or Delegated Third 
Party MUST place the call to a phone number identified by the Domain Name 
Registrar as the Domain Contact.
Each phone call SHALL be made to a single number and MAY confirm control of 
multiple FQDNs, provided that the phone number is identified by the Domain 
Registrar as a valid contact method for every Base Domain Name being verified 
using the phone call.
*** 3.2.2.4.4 Constructed Email to Domain Contact
Confirm the Applicant's control over the requested FQDN by (i) sending an email 
to one or more addresses created by using 'admin', 'administrator', 
'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by the 
at-sign ("@"), followed by an Authorization Domain Name, (ii) including a 
Random Value in the email, and (iii) recei

Re: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

I agree that the 24 hours seems excessive for some of these. Ive proposed at 
the cab forum we bifuracte the revocation periods to key compromise vs non key 
compromise. I'd love support there on the proposal. However, I think that until 
the rules change formally, CAs should be required to meet that strict period. 
It's not hard to make a change once general agreement is reached.

> On Aug 8, 2017, at 1:02 PM, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> Some people seemed to require 24-hour revocation of these, which I also
> find possibly excessive.
> 
>> On 08/08/2017 20:28, Alex Gaynor wrote:
>> I think you're largely objecting to a strawman, no one is proposing
>> revoking trust in any of these threads.
>> The only CAs that have ever had _any_ penalty applied to them have been for
>> grotesque abuse of the trust vested in them.
>> Alex
>> On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> On 08/08/2017 18:43, Ryan Sleevi wrote:
>>> 
> On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:
> 
> I was not advocating "letting everyone decide".  I was advocating that
> Mozilla show some restraint, intelligence and common sense in wielding
> the new weapons that certlint and crt.sh have given us.
> 
> This shouldn't be race as to who wields the weapon first, forgiving CAs
> only if they happen to report faster than some other newsgroup
> participant.
> 
> This is similar to if a store boss gets a new surveillance camera in the
> shop and sees that some employees are taking extra breaks when there are
> few customers in the store.  It would be unreasonable for such a store
> boss to discipline this with similar zeal as seeing some employees
> genuinely steeling cash out of the register or selling stolen items out
> of the back door.  Instead the fact that they work less when there is
> less work to do should inspire reevaluation of any old rule that they
> are not allowed to have a watercooler chat during work hours.
> 
> Now such a reevaluation might result in requiring them to use such
> occasions to clean the floors or do some other chores (Mozilla equiv:
> Deciding that the rule is important for good reason and needs to be
> followed in the future) or it could result in relaxing the rule as
> long as they stand ready the moment a customer arrives (Mozilla equiv:
> Relaxing the requirement, initially just for Mozilla, later perhaps as a
> BR change).
> 
> Dogmatically insisting on enforcing rules that were previously not
> enforced due to lack of detection, just because "rules are rules" or
> other such arguments seems overzealous.
> 
> 
 Such tools have been available for over a year. CAs have been aware of
 this, the ability to run it over their own corpus and self-detect and
 self-report. These tools, notably, were created by one of the newest CA
 applicants - Amazon - based on a methodical study of what is required of a
 CA.
 
 Your attempts to characterize it as overzealous ignore this entirely. At
 this point, it's gross negligence, and attempts to argue otherwise merely
 suggest a lack of understanding or concern for standards compliance and
 interoperability.
 
 Mozilla has already communicated to CAs these tools exist and their
 relevance to CAs.
 
 Perhaps we can move on from misguided apologetics and instead focus on
 how to make things better. Suggestions we ignore these, at this point, are
 neither productive nor relevant. Attempts to suggest tortured metaphors are
 like attempting to suggest rich people deserve to be robbed, or poor people
 just need to work harder - arguments that are both hollow and borderline
 offensive in their reductionism. A pattern of easily preventable
 misissuance has been happening,CAs have been repeatedly told to
 self-detect, and clearly, some CAs, like presumably some businesses, aren't
 taking security seriously. That needs to stop.
 
 
>>> I am questioning the fairness of applying these tools, which did not
>>> exist when the rules were written, to enforce every rule with the same
>>> high weight.  I am not apologizing for bad behavior, I am saying if
>>> everybody gets scrutinized this hard, we will eventually have to
>>> distrust pretty much all the CAs, because there is no such thing as a
>>> perfect CA organization.
>>> 
>>> So we need to prioritize the rules instead of just saying off-with-
>>> their-heads (revoke all affected certificates in 24 hours) whenever any
>>> formal rule was broken without actually harming security.
>>> 
>>> An example of a graduated response:
>>> 
>>> - Deliberately issued super-interception certificate: Instant revocation
>>>  of CA trust.
>>> - SubCA that does no vetting at all: Instant revocation and adding to
>

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 11:26:11 AM UTC-7, Jakob Bohm wrote:
> On 08/08/2017 18:43, Ryan Sleevi wrote:
> > On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:
> >> I was not advocating "letting everyone decide".  I was advocating that
> >> Mozilla show some restraint, intelligence and common sense in wielding
> >> the new weapons that certlint and crt.sh have given us.
> >>
> >> This shouldn't be race as to who wields the weapon first, forgiving CAs
> >> only if they happen to report faster than some other newsgroup
> >> participant.
> >>
> >> This is similar to if a store boss gets a new surveillance camera in the
> >> shop and sees that some employees are taking extra breaks when there are
> >> few customers in the store.  It would be unreasonable for such a store
> >> boss to discipline this with similar zeal as seeing some employees
> >> genuinely steeling cash out of the register or selling stolen items out
> >> of the back door.  Instead the fact that they work less when there is
> >> less work to do should inspire reevaluation of any old rule that they
> >> are not allowed to have a watercooler chat during work hours.
> >>
> >> Now such a reevaluation might result in requiring them to use such
> >> occasions to clean the floors or do some other chores (Mozilla equiv:
> >> Deciding that the rule is important for good reason and needs to be
> >> followed in the future) or it could result in relaxing the rule as
> >> long as they stand ready the moment a customer arrives (Mozilla equiv:
> >> Relaxing the requirement, initially just for Mozilla, later perhaps as a
> >> BR change).
> >>
> >> Dogmatically insisting on enforcing rules that were previously not
> >> enforced due to lack of detection, just because "rules are rules" or
> >> other such arguments seems overzealous.
> >>
> > 
> > Such tools have been available for over a year. CAs have been aware of 
> > this, the ability to run it over their own corpus and self-detect and 
> > self-report. These tools, notably, were created by one of the newest CA 
> > applicants - Amazon - based on a methodical study of what is required of a 
> > CA.
> > 
> > Your attempts to characterize it as overzealous ignore this entirely. At 
> > this point, it's gross negligence, and attempts to argue otherwise merely 
> > suggest a lack of understanding or concern for standards compliance and 
> > interoperability.
> > 
> > Mozilla has already communicated to CAs these tools exist and their 
> > relevance to CAs.
> > 
> > Perhaps we can move on from misguided apologetics and instead focus on how 
> > to make things better. Suggestions we ignore these, at this point, are 
> > neither productive nor relevant. Attempts to suggest tortured metaphors are 
> > like attempting to suggest rich people deserve to be robbed, or poor people 
> > just need to work harder - arguments that are both hollow and borderline 
> > offensive in their reductionism. A pattern of easily preventable 
> > misissuance has been happening,CAs have been repeatedly told to 
> > self-detect, and clearly, some CAs, like presumably some businesses, aren't 
> > taking security seriously. That needs to stop.
> > 
> 
> I am questioning the fairness of applying these tools, which did not
> exist when the rules were written, to enforce every rule with the same
> high weight. 

Did anything prevent the CAs responsible from writing these tools?

Do you believe there is any excuse for issuance in 2017 that violates these 
rules?

Is your view that until someone else does the CA's work for them (reading and 
understanding the rules), the CA should not be responsible for reading or 
understanding themselves?

You're arguing against a strawman. It's 2017 - it's both time to stop making 
excuses and time to recognize that the ability of CAs to adhere to the rules is 
core to their trustworthiness. Technical rules are but a proxy for procedure 
rules.

> I am not apologizing for bad behavior, I am saying if
> everybody gets scrutinized this hard, we will eventually have to
> distrust pretty much all the CAs, because there is no such thing as a
> perfect CA organization.

No, you are apologizing for their bad behaviour by suggesting they shouldn't be 
held to an objective standard, because someone else hadn't done the work for 
them. The compliance or noncompliance is extremely relevant to the CAs ability 
to react and respond to changes, and you continue to offer a view that suggests 
CAs shouldn't have to respond consistently or should not be expected to 
consistently follow the rules, which undermine the very trust.

If these are violations, and they are, we should expect each CA to take action 
and explain to the community why they failed to detect these issues, as well as 
what changes they are making in the future to stay on top. Prioritization is 
both a misdirect to responsibility and an attempt to undermine trustworthiness.

> 
> So we need to prioritize the rules instead of just saying o

Re: CA Problem Reporting Mechanisms

[Jeremy Rowley via dev-security-policy]

+1. CAs should be required to support certificate problem reports sent through 
a specified email address. It simplifies the process a lot if CAs use at least 
one common mechanism.

> On Aug 8, 2017, at 12:22 PM, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> 
>> On Aug 8, 2017, at 10:36, David E. Ross via dev-security-policy 
>>  wrote:
>> 
>> On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
>>> 
 On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
  wrote:
 
 On 16/05/17 02:26, userwithuid wrote:
> After skimming the responses and checking a few CAs, I'm starting to
> wonder: Wouldn't it be easier to just add another mandatory field to
> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
> policy and just use that to provide a public list?
 
 Well, such contacts are normally per CA rather than per root. I guess we
 could add it on the CA's entry.
>>> 
>>> I’ve been reporting a fair amount of misissuance this week, and the 
>>> responses to the Problem Reporting question in the April CA communication 
>>> leave a lot to be desired. Several CAs do not have any contact details at 
>>> all, and others require filling forms with captchas.
>>> 
>>> I think it’d be very useful if CAs were required maintain a problem 
>>> reporting email address and keep it current in the CCADB, this requirement 
>>> could go in the Mozilla Root Store policy or the CCADB policy. If they want 
>>> to also maintain other modes of contact, they can but no matter what an 
>>> email address should be required.
>>> 
>>> Jonathan
>>> 
>> 
>> I think that a public point of contact for a certification authority was
>> a requirement under Mozilla's policy.  I cannot find such a requirement
>> now unless the Baseline Requirements, which are included by reference in
>> Mozilla's policy, require it.
> 
> Yes, section 4.9.3 of the Baseline Requirements says:
> 
>> The CA SHALL provide Subscribers, Relying Parties, Application Software 
>> Suppliers, and other third parties with clear instructions for reporting 
>> suspected Private Key Compromise, Certificate misuse, or other types of 
>> fraud, compromise, misuse, inappropriate conduct, or any other matter 
>> related to Certificates. The CA SHALL publicly disclose the instructions 
>> through a readily accessible online means.
> 
> However, it does not specify that email is required. I’m proposing that 
> Mozilla require that one of the methods for reporting be email and that the 
> email address be recorded in the CCADB.
> 
> Jonathan
> ___
> 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: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

It's from the BRs 4.9.1.1:

 The CA SHALL revoke a Certificate within 24 hours if one or more of
the following occurs:

It's also not a penalty on the CA, it's a remediation step for them to
undertake.

Alex

On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Some people seemed to require 24-hour revocation of these, which I also
> find possibly excessive.
>
> On 08/08/2017 20:28, Alex Gaynor wrote:
>
>> I think you're largely objecting to a strawman, no one is proposing
>> revoking trust in any of these threads.
>>
>> The only CAs that have ever had _any_ penalty applied to them have been
>> for
>> grotesque abuse of the trust vested in them.
>>
>> Alex
>>
>> On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> On 08/08/2017 18:43, Ryan Sleevi wrote:
>>>
>>> On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:

 I was not advocating "letting everyone decide".  I was advocating that
> Mozilla show some restraint, intelligence and common sense in wielding
> the new weapons that certlint and crt.sh have given us.
>
> This shouldn't be race as to who wields the weapon first, forgiving CAs
> only if they happen to report faster than some other newsgroup
> participant.
>
> This is similar to if a store boss gets a new surveillance camera in
> the
> shop and sees that some employees are taking extra breaks when there
> are
> few customers in the store.  It would be unreasonable for such a store
> boss to discipline this with similar zeal as seeing some employees
> genuinely steeling cash out of the register or selling stolen items out
> of the back door.  Instead the fact that they work less when there is
> less work to do should inspire reevaluation of any old rule that they
> are not allowed to have a watercooler chat during work hours.
>
> Now such a reevaluation might result in requiring them to use such
> occasions to clean the floors or do some other chores (Mozilla equiv:
> Deciding that the rule is important for good reason and needs to be
> followed in the future) or it could result in relaxing the rule as
> long as they stand ready the moment a customer arrives (Mozilla equiv:
> Relaxing the requirement, initially just for Mozilla, later perhaps as
> a
> BR change).
>
> Dogmatically insisting on enforcing rules that were previously not
> enforced due to lack of detection, just because "rules are rules" or
> other such arguments seems overzealous.
>
>
> Such tools have been available for over a year. CAs have been aware of
 this, the ability to run it over their own corpus and self-detect and
 self-report. These tools, notably, were created by one of the newest CA
 applicants - Amazon - based on a methodical study of what is required
 of a
 CA.

 Your attempts to characterize it as overzealous ignore this entirely. At
 this point, it's gross negligence, and attempts to argue otherwise
 merely
 suggest a lack of understanding or concern for standards compliance and
 interoperability.

 Mozilla has already communicated to CAs these tools exist and their
 relevance to CAs.

 Perhaps we can move on from misguided apologetics and instead focus on
 how to make things better. Suggestions we ignore these, at this point,
 are
 neither productive nor relevant. Attempts to suggest tortured metaphors
 are
 like attempting to suggest rich people deserve to be robbed, or poor
 people
 just need to work harder - arguments that are both hollow and borderline
 offensive in their reductionism. A pattern of easily preventable
 misissuance has been happening,CAs have been repeatedly told to
 self-detect, and clearly, some CAs, like presumably some businesses,
 aren't
 taking security seriously. That needs to stop.


 I am questioning the fairness of applying these tools, which did not
>>> exist when the rules were written, to enforce every rule with the same
>>> high weight.  I am not apologizing for bad behavior, I am saying if
>>> everybody gets scrutinized this hard, we will eventually have to
>>> distrust pretty much all the CAs, because there is no such thing as a
>>> perfect CA organization.
>>>
>>> So we need to prioritize the rules instead of just saying off-with-
>>> their-heads (revoke all affected certificates in 24 hours) whenever any
>>> formal rule was broken without actually harming security.
>>>
>>> An example of a graduated response:
>>>
>>> - Deliberately issued super-interception certificate: Instant revocation
>>>   of CA trust.
>>> - SubCA that does no vetting at all: Instant revocation and adding to
>>>   OneCRL.
>>> - Certificate issued to someone who should not have it (like the github
>

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

Some people seemed to require 24-hour revocation of these, which I also
find possibly excessive.

On 08/08/2017 20:28, Alex Gaynor wrote:

I think you're largely objecting to a strawman, no one is proposing
revoking trust in any of these threads.

The only CAs that have ever had _any_ penalty applied to them have been for
grotesque abuse of the trust vested in them.

Alex

On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 08/08/2017 18:43, Ryan Sleevi wrote:


On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:


I was not advocating "letting everyone decide".  I was advocating that
Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in the
shop and sees that some employees are taking extra breaks when there are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.



Such tools have been available for over a year. CAs have been aware of
this, the ability to run it over their own corpus and self-detect and
self-report. These tools, notably, were created by one of the newest CA
applicants - Amazon - based on a methodical study of what is required of a
CA.

Your attempts to characterize it as overzealous ignore this entirely. At
this point, it's gross negligence, and attempts to argue otherwise merely
suggest a lack of understanding or concern for standards compliance and
interoperability.

Mozilla has already communicated to CAs these tools exist and their
relevance to CAs.

Perhaps we can move on from misguided apologetics and instead focus on
how to make things better. Suggestions we ignore these, at this point, are
neither productive nor relevant. Attempts to suggest tortured metaphors are
like attempting to suggest rich people deserve to be robbed, or poor people
just need to work harder - arguments that are both hollow and borderline
offensive in their reductionism. A pattern of easily preventable
misissuance has been happening,CAs have been repeatedly told to
self-detect, and clearly, some CAs, like presumably some businesses, aren't
taking security seriously. That needs to stop.



I am questioning the fairness of applying these tools, which did not
exist when the rules were written, to enforce every rule with the same
high weight.  I am not apologizing for bad behavior, I am saying if
everybody gets scrutinized this hard, we will eventually have to
distrust pretty much all the CAs, because there is no such thing as a
perfect CA organization.

So we need to prioritize the rules instead of just saying off-with-
their-heads (revoke all affected certificates in 24 hours) whenever any
formal rule was broken without actually harming security.

An example of a graduated response:

- Deliberately issued super-interception certificate: Instant revocation
  of CA trust.
- SubCA that does no vetting at all: Instant revocation and adding to
  OneCRL.
- Certificate issued to someone who should not have it (like the github
  certs issued by WoSign): 24 hour revocation, faster if possible.
- Certificate that violates rules and triggers a bug preventing Mozilla
  NSS from detecting if it is revoked: 24 hour revocation and adding
  special case code to NSS to treat this form of certificate as not valid
  instead of non-revocable.
- Certificate issued in such a way as to increase the risk of
  post-issuance attacks (such as SHA-1 cert issued in 2016 or later with
  insufficient random bits near the start of the TBSCertificate): 24 hour
  revocation of cert itself, issuing SubCA revoked with 2 month delay to
  replace affected good certificates from a new clean SubCA.
- Single Certificate that violates rules, but works with revocation
  checking in NSS and was issued to the proper party (possesses domai

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

[Jakob Bohm via dev-security-policy]

On 08/08/2017 19:44, Ryan Sleevi wrote:

On Tuesday, August 8, 2017 at 8:52:54 PM UTC+9, Jakob Bohm wrote:

On 08/08/2017 12:54, Nick Lamb wrote:

On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm  wrote:

Since the CT made it possible, I have seen an increasing obsession with
enforcing every little detail of the BRs, things that would not only
have gone unnoticed, but also been considered unremarkable before CT.


Even if I had no other reason to be concerned about violations of the BRs (and I do 
have plenty, as we saw here in this case it looks like the certificate can be 
revoked but it effectively can't) the Brown M&M Rider reason is enough,

The rider (hospitality and technical requirements for a performing artist) can be 
pretty detailed, some venues may glance at it and agree to whatever is inside 
without knowing the details. This is a _huge_ problem, and Van Halen is famous for 
a clause in their rider (requiring a bowl of M&Ms but with the brown ones 
removed) which they say existed not out of spite but precisely to check that the 
venue had actually read the rider in full and not just skimmed it, so that they 
would have early warning if a particular venue were sloppy and might cause surprise 
problems with technical implementation.

We need CAs to be detail oriented. It is not enough to "kinda, mostly" get this 
job right. If you can't do _exactly_ what it says in the BRs, don't bother doing it at 
all. Neither Mozilla nor any other trust store compel CAs to stay in this business, if 
they decide they'd rather sell pancakes or mow lawns, that's up to them. So long as they 
want to be trusted public CAs, they need to obey the rules that are in place to make that 
safe for everybody.



While the Brown M&M Rider argument would be good if, like the van Halen
clause, there was only a small number of such intentional gotcha rules,
in this case we are dealing with a large corpus of rules, some explicit,
some in documents referenced from other documents etc.

That makes the situation much more like the situation with other large
sets of rules for people to follow, which means that there will, in
practice, always be rules more important than others.  And hence a
natural expectation that those tasked with enforcing the rules actually
know the difference and don't issue large penalties for what is
obviously minor infractions.

Now in this *specific* case, it has been found that Mozilla's NSS
doesn't handle HTTPS OCSP URLs in a good way, and thus Mozilla has a
specific need to prevent their public use until NSS gains the ability to
handle them safely (because there is a benefit to it).  Discussing that
benefit and planning appropriate transition plans is an issue for
another thread, possibly in another forum.


While you may feel this way, it is again inaccurate to present it as such. It is an intentional 
design decision by the NSS and Firefox developers, made independently by folks at Apple, Google, 
and Microsoft as well for nearly two decades. This isn't "oops, NSS doesn't support it" - 
it is "this is a terrible idea"
> I realize you are trying to present it as a bug, in order to justify 
the presence of brown M&Ms as "not important," but you are failing to 
recognize such URLs DO break implementations and are forbidden for 
legitimate reasons.




Actually I have long considered it a bug/errata in the PKIX standards.
Thus I was somewhat triggered when this suddenly became an enforced
rule.  I wasn't making this up to defend the CA that issued those
certificates.


But certainly, further arguments on this point are best suited for another 
forum, because there is no good reason to change here.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Matthew Hardeman via dev-security-policy]

It seems this thread has diverged a bit from its stated purpose, the 
determination of the question of mis-issuance of a set of certificates which 
have (possibly) longer than allowed serial numbers.

I raised a question as to the history of the selection of the 20 bytes limit 
for serial numbers and it was pointed out that this is the size of an SHA-1 
hash.

As the principal use of serial these days is double-duty as both unique 
identifier within an issuer DN as well as an early-in-the-certificate-document 
insertion of unpredictable entropy for mitigation of pre-image collision 
attacks, the continued merits of the notion of serial number as needing to 
store an SHA-1 value are certainly questionable.

I merely raise the point that IF the framers of the 20 bytes rule did, in fact, 
simultaneously intend that arbitrary SHA-1 hash results should be able to be 
stuffed into the serial number field AND SIMULTANEOUSLY that the DER encoded 
integer field value must be a positive integer and that insertion of a leading 
0x00 byte to ensure that the high order bit would be 0 (thus regarded as a 
positive value per the coding), THEN it must follow that at least in the minds 
of those who engineered the rule, that the inserted 0x00 byte must not be part 
of the 20 byte maximum size of the value AS legitimate SHA-1 values of 20 bytes 
do include values where the high order bit would be 1 and without pre-padding 
the proper interpretation of such a value would be as a negative integer.

The language of the 20 bytes rule is actually ambiguous.  If that ambiguity is 
coupled with a possible (prior) intent that it be possible to store a SHA-1 
output as the serial number, it's more than just ambiguous.   If it is 
essential that the total encoded representation within the certificate 
structure not exceed 20 bytes, I would think that a clarification in line with 
Peter Bowen's proposal in this thread might be appropriate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

I think you're largely objecting to a strawman, no one is proposing
revoking trust in any of these threads.

The only CAs that have ever had _any_ penalty applied to them have been for
grotesque abuse of the trust vested in them.

Alex

On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 08/08/2017 18:43, Ryan Sleevi wrote:
>
>> On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:
>>
>>> I was not advocating "letting everyone decide".  I was advocating that
>>> Mozilla show some restraint, intelligence and common sense in wielding
>>> the new weapons that certlint and crt.sh have given us.
>>>
>>> This shouldn't be race as to who wields the weapon first, forgiving CAs
>>> only if they happen to report faster than some other newsgroup
>>> participant.
>>>
>>> This is similar to if a store boss gets a new surveillance camera in the
>>> shop and sees that some employees are taking extra breaks when there are
>>> few customers in the store.  It would be unreasonable for such a store
>>> boss to discipline this with similar zeal as seeing some employees
>>> genuinely steeling cash out of the register or selling stolen items out
>>> of the back door.  Instead the fact that they work less when there is
>>> less work to do should inspire reevaluation of any old rule that they
>>> are not allowed to have a watercooler chat during work hours.
>>>
>>> Now such a reevaluation might result in requiring them to use such
>>> occasions to clean the floors or do some other chores (Mozilla equiv:
>>> Deciding that the rule is important for good reason and needs to be
>>> followed in the future) or it could result in relaxing the rule as
>>> long as they stand ready the moment a customer arrives (Mozilla equiv:
>>> Relaxing the requirement, initially just for Mozilla, later perhaps as a
>>> BR change).
>>>
>>> Dogmatically insisting on enforcing rules that were previously not
>>> enforced due to lack of detection, just because "rules are rules" or
>>> other such arguments seems overzealous.
>>>
>>>
>> Such tools have been available for over a year. CAs have been aware of
>> this, the ability to run it over their own corpus and self-detect and
>> self-report. These tools, notably, were created by one of the newest CA
>> applicants - Amazon - based on a methodical study of what is required of a
>> CA.
>>
>> Your attempts to characterize it as overzealous ignore this entirely. At
>> this point, it's gross negligence, and attempts to argue otherwise merely
>> suggest a lack of understanding or concern for standards compliance and
>> interoperability.
>>
>> Mozilla has already communicated to CAs these tools exist and their
>> relevance to CAs.
>>
>> Perhaps we can move on from misguided apologetics and instead focus on
>> how to make things better. Suggestions we ignore these, at this point, are
>> neither productive nor relevant. Attempts to suggest tortured metaphors are
>> like attempting to suggest rich people deserve to be robbed, or poor people
>> just need to work harder - arguments that are both hollow and borderline
>> offensive in their reductionism. A pattern of easily preventable
>> misissuance has been happening,CAs have been repeatedly told to
>> self-detect, and clearly, some CAs, like presumably some businesses, aren't
>> taking security seriously. That needs to stop.
>>
>>
> I am questioning the fairness of applying these tools, which did not
> exist when the rules were written, to enforce every rule with the same
> high weight.  I am not apologizing for bad behavior, I am saying if
> everybody gets scrutinized this hard, we will eventually have to
> distrust pretty much all the CAs, because there is no such thing as a
> perfect CA organization.
>
> So we need to prioritize the rules instead of just saying off-with-
> their-heads (revoke all affected certificates in 24 hours) whenever any
> formal rule was broken without actually harming security.
>
> An example of a graduated response:
>
> - Deliberately issued super-interception certificate: Instant revocation
>  of CA trust.
> - SubCA that does no vetting at all: Instant revocation and adding to
>  OneCRL.
> - Certificate issued to someone who should not have it (like the github
>  certs issued by WoSign): 24 hour revocation, faster if possible.
> - Certificate that violates rules and triggers a bug preventing Mozilla
>  NSS from detecting if it is revoked: 24 hour revocation and adding
>  special case code to NSS to treat this form of certificate as not valid
>  instead of non-revocable.
> - Certificate issued in such a way as to increase the risk of
>  post-issuance attacks (such as SHA-1 cert issued in 2016 or later with
>  insufficient random bits near the start of the TBSCertificate): 24 hour
>  revocation of cert itself, issuing SubCA revoked with 2 month delay to
>  replace affected good certificates from a new clean SubCA.
> - Single Certificate that violates rules, but

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 08/08/2017 18:43, Ryan Sleevi wrote:

On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:

I was not advocating "letting everyone decide".  I was advocating that
Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in the
shop and sees that some employees are taking extra breaks when there are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.



Such tools have been available for over a year. CAs have been aware of this, 
the ability to run it over their own corpus and self-detect and self-report. 
These tools, notably, were created by one of the newest CA applicants - Amazon 
- based on a methodical study of what is required of a CA.

Your attempts to characterize it as overzealous ignore this entirely. At this 
point, it's gross negligence, and attempts to argue otherwise merely suggest a 
lack of understanding or concern for standards compliance and interoperability.

Mozilla has already communicated to CAs these tools exist and their relevance 
to CAs.

Perhaps we can move on from misguided apologetics and instead focus on how to 
make things better. Suggestions we ignore these, at this point, are neither 
productive nor relevant. Attempts to suggest tortured metaphors are like 
attempting to suggest rich people deserve to be robbed, or poor people just 
need to work harder - arguments that are both hollow and borderline offensive 
in their reductionism. A pattern of easily preventable misissuance has been 
happening,CAs have been repeatedly told to self-detect, and clearly, some CAs, 
like presumably some businesses, aren't taking security seriously. That needs 
to stop.



I am questioning the fairness of applying these tools, which did not
exist when the rules were written, to enforce every rule with the same
high weight.  I am not apologizing for bad behavior, I am saying if
everybody gets scrutinized this hard, we will eventually have to
distrust pretty much all the CAs, because there is no such thing as a
perfect CA organization.

So we need to prioritize the rules instead of just saying off-with-
their-heads (revoke all affected certificates in 24 hours) whenever any
formal rule was broken without actually harming security.

An example of a graduated response:

- Deliberately issued super-interception certificate: Instant revocation
 of CA trust.
- SubCA that does no vetting at all: Instant revocation and adding to
 OneCRL.
- Certificate issued to someone who should not have it (like the github
 certs issued by WoSign): 24 hour revocation, faster if possible.
- Certificate that violates rules and triggers a bug preventing Mozilla
 NSS from detecting if it is revoked: 24 hour revocation and adding
 special case code to NSS to treat this form of certificate as not valid
 instead of non-revocable.
- Certificate issued in such a way as to increase the risk of
 post-issuance attacks (such as SHA-1 cert issued in 2016 or later with
 insufficient random bits near the start of the TBSCertificate): 24 hour
 revocation of cert itself, issuing SubCA revoked with 2 month delay to
 replace affected good certificates from a new clean SubCA.
- Single Certificate that violates rules, but works with revocation
 checking in NSS and was issued to the proper party (possesses domains,
 matches any real world identity in DN etc.): Revoke after 14 days, try
 to replace before that.
- Thousands of certificates that violate rules, but work with revocation
 checking in NSS and were issued to the proper parties (example: O=
 field replaced by "test" after full vetting of actual name): Revoke
 after 2 months, try to replace before that.
- Certificate that violates a previously unclear interpretation of a
 rule, but works with revocation checking in NSS and was issued to 

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

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 8:52:54 PM UTC+9, Jakob Bohm wrote:
> On 08/08/2017 12:54, Nick Lamb wrote:
> > On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm  wrote:
> >> Since the CT made it possible, I have seen an increasing obsession with
> >> enforcing every little detail of the BRs, things that would not only
> >> have gone unnoticed, but also been considered unremarkable before CT.
> > 
> > Even if I had no other reason to be concerned about violations of the BRs 
> > (and I do have plenty, as we saw here in this case it looks like the 
> > certificate can be revoked but it effectively can't) the Brown M&M Rider 
> > reason is enough,
> > 
> > The rider (hospitality and technical requirements for a performing artist) 
> > can be pretty detailed, some venues may glance at it and agree to whatever 
> > is inside without knowing the details. This is a _huge_ problem, and Van 
> > Halen is famous for a clause in their rider (requiring a bowl of M&Ms but 
> > with the brown ones removed) which they say existed not out of spite but 
> > precisely to check that the venue had actually read the rider in full and 
> > not just skimmed it, so that they would have early warning if a particular 
> > venue were sloppy and might cause surprise problems with technical 
> > implementation.
> > 
> > We need CAs to be detail oriented. It is not enough to "kinda, mostly" get 
> > this job right. If you can't do _exactly_ what it says in the BRs, don't 
> > bother doing it at all. Neither Mozilla nor any other trust store compel 
> > CAs to stay in this business, if they decide they'd rather sell pancakes or 
> > mow lawns, that's up to them. So long as they want to be trusted public 
> > CAs, they need to obey the rules that are in place to make that safe for 
> > everybody.
> > 
> 
> While the Brown M&M Rider argument would be good if, like the van Halen
> clause, there was only a small number of such intentional gotcha rules,
> in this case we are dealing with a large corpus of rules, some explicit,
> some in documents referenced from other documents etc.
> 
> That makes the situation much more like the situation with other large
> sets of rules for people to follow, which means that there will, in
> practice, always be rules more important than others.  And hence a
> natural expectation that those tasked with enforcing the rules actually
> know the difference and don't issue large penalties for what is
> obviously minor infractions.
> 
> Now in this *specific* case, it has been found that Mozilla's NSS
> doesn't handle HTTPS OCSP URLs in a good way, and thus Mozilla has a
> specific need to prevent their public use until NSS gains the ability to
> handle them safely (because there is a benefit to it).  Discussing that
> benefit and planning appropriate transition plans is an issue for
> another thread, possibly in another forum.

While you may feel this way, it is again inaccurate to present it as such. It 
is an intentional design decision by the NSS and Firefox developers, made 
independently by folks at Apple, Google, and Microsoft as well for nearly two 
decades. This isn't "oops, NSS doesn't support it" - it is "this is a terrible 
idea"

I realize you are trying to present it as a bug, in order to justify the 
presence of brown M&Ms as "not important," but you are failing to recognize 
such URLs DO break implementations and are forbidden for legitimate reasons.

But certainly, further arguments on this point are best suited for another 
forum, because there is no good reason to change here.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Jonathan Rudenberg via dev-security-policy]

> On Aug 8, 2017, at 08:58, Fiedler, Arno via dev-security-policy 
>  wrote:
> 
> Dear Mozilla Security Policy Community,
> 
> Thanks for the advice about the short serial numbers and apologies for the 
> delayed response.
> 
> Since 2016, all D-TRUST TLS certificates based on electronic Certificate 
> Requests have a certificate serial number which includes 64 bits of entropy.
> 
> Between 2012 and July 6th, 2017 we produced a small number of certificates 
> with  paper-based Certificate Registration Requests using 64 bits of entropy 
> in the "DNqualifier" field instead of the serial number field.
> 
> Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits of 
> entropy in the serial number.
> 
> I hope this helps and please do not hesitate to contact us if there are any 
> further questions.

Hi Arno,

It doesn’t look like this certificate has been revoked yet? 
https://crt.sh/?id=174827359&opt=cablint

Can you explain why it hasn’t been revoked yet and when it will be?

Thanks,

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

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Ryan Sleevi via dev-security-policy]

On Wednesday, August 9, 2017 at 12:22:53 AM UTC+9, Fiedler, Arno wrote:
> Dear Mozilla Security Policy Community,
> 
> Thanks for the advice about the short serial numbers and apologies for the 
> delayed response.
> 
> Since 2016, all D-TRUST TLS certificates based on electronic Certificate 
> Requests have a certificate serial number which includes 64 bits of entropy.
> 
> Between 2012 and July 6th, 2017 we produced a small number of certificates 
> with  paper-based Certificate Registration Requests using 64 bits of entropy 
> in the "DNqualifier" field instead of the serial number field.
> 
> Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits of 
> entropy in the serial number.
> 
> I hope this helps and please do not hesitate to contact us if there are any 
> further questions.
> 
> Best regards
> Arno Fiedler
> Standardization & Consulting
> Bundesdruckerei GmbH
> Kommandantenstraße 18 · 10969 Berlin · Deutschland
> 
> Tel. :+ 49 30 25 98 - 3009
> Mobil: + 49 172 3053272
> 
> arno.fied...@bdr.de · www.bundesdruckerei.de
> 
> Sitz der Gesellschaft: Berlin · Handelsregister: AG Berlin-Charlottenburg HRB 
> 80443. USt.-IdNr.: DE 813210005
> Aufsichtsratsvorsitzender: Willi Berchtold
> Geschäftsführer: Ulrich Hamann (Vorsitzender), Christian Helfrich
> 
> This message is intended only for the use of the individual or entity to 
> which it is addressed, and may contain information that is privileged, 
> confidential and exempt from disclosure under applicable law. If the reader 
> of this message is not the intended recipient, or the employee or agent 
> responsible for delivering the message to the intended recipient, we hereby 
> give notice that any dissemination, distribution or copying of this 
> communication is strictly prohibited. If you have received this message in 
> error, please delete the message and notify us immediately.
> Diese Nachricht kann vertrauliche und gesetzlich geschützte Informationen 
> enthalten. Sie ist ausschließlich für den Adressaten bestimmt. Wenn Sie nicht 
> der beabsichtigte Adressat sind, möchten wir Sie hiermit darüber informieren, 
> dass das Weiterleiten, Verteilen oder Kopieren dieser Mail nicht gestattet 
> ist. Wenn Sie diese Mail irrtümlicherweise erhalten haben, informieren Sie 
> uns bitte schnellstmöglich und löschen Sie bitte die Mail.

Thanks for acknowledging this, Arno, but I can't help but feel this is an 
insufficient and incomplete analysis.

Could you share more along the following:
1) How many certificates were affected?
2) How did you determine this?
3) Did you detect this prior to July 7?
4) If not, why not, given the availability of tools?
5) Have you completed an analysis of what the root cause of your failure to 
follow the Baseline Requirements was?
6) If so, what was it? If not, why not?
7) Was this detected by your audits?
8) If so, why was it not noted at the time? If not, what would you suggest be 
added to prevent this in the future?
9) What systematic steps have you taken to ensure compliance with the BRs in a 
timely fashion?

The goal here is not penance from a CA, nor is it granting indulgences or 
special dispensation - it's about demonstrating an awareness of the 
requirements and the opportunity to improve how a CA is managed to comply to 
these requirements, if it is to continue to be trusted as a CA.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:
> I was not advocating "letting everyone decide".  I was advocating that
> Mozilla show some restraint, intelligence and common sense in wielding
> the new weapons that certlint and crt.sh have given us.
> 
> This shouldn't be race as to who wields the weapon first, forgiving CAs
> only if they happen to report faster than some other newsgroup
> participant.
> 
> This is similar to if a store boss gets a new surveillance camera in the
> shop and sees that some employees are taking extra breaks when there are
> few customers in the store.  It would be unreasonable for such a store
> boss to discipline this with similar zeal as seeing some employees
> genuinely steeling cash out of the register or selling stolen items out
> of the back door.  Instead the fact that they work less when there is
> less work to do should inspire reevaluation of any old rule that they
> are not allowed to have a watercooler chat during work hours.
> 
> Now such a reevaluation might result in requiring them to use such
> occasions to clean the floors or do some other chores (Mozilla equiv:
> Deciding that the rule is important for good reason and needs to be
> followed in the future) or it could result in relaxing the rule as
> long as they stand ready the moment a customer arrives (Mozilla equiv:
> Relaxing the requirement, initially just for Mozilla, later perhaps as a
> BR change).
> 
> Dogmatically insisting on enforcing rules that were previously not
> enforced due to lack of detection, just because "rules are rules" or
> other such arguments seems overzealous.
> 

Such tools have been available for over a year. CAs have been aware of this, 
the ability to run it over their own corpus and self-detect and self-report. 
These tools, notably, were created by one of the newest CA applicants - Amazon 
- based on a methodical study of what is required of a CA.

Your attempts to characterize it as overzealous ignore this entirely. At this 
point, it's gross negligence, and attempts to argue otherwise merely suggest a 
lack of understanding or concern for standards compliance and interoperability.

Mozilla has already communicated to CAs these tools exist and their relevance 
to CAs.

Perhaps we can move on from misguided apologetics and instead focus on how to 
make things better. Suggestions we ignore these, at this point, are neither 
productive nor relevant. Attempts to suggest tortured metaphors are like 
attempting to suggest rich people deserve to be robbed, or poor people just 
need to work harder - arguments that are both hollow and borderline offensive 
in their reductionism. A pattern of easily preventable misissuance has been 
happening,CAs have been repeatedly told to self-detect, and clearly, some CAs, 
like presumably some businesses, aren't taking security seriously. That needs 
to stop.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jonathan Rudenberg via dev-security-policy]

> On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy 
>  wrote:
> 
> On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
>> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder 
>> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI 
>> is required to have the plaintext HTTP scheme according to Baseline 
>> Requirements section 7.1.2.2(c).
>> 
>> Here’s the list of certificates: https://misissued.com/batch/4/
>> 
>> Jonathan
> 
> IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in this 
> context.  That being said, we have altered our profiles for certificates 
> issued under this Sub CA to include only HTTP OCSP URLs.  All certificates 
> issued going forward will contain an HTTP OCSP URL.  We will also examine all 
> other sub CA to ensure only HTTP OCSP URLs are included.  Thank you for 
> giving 
> us an opportunity to address this with the community

Thanks for the update.

Can you also clarify why the subject organizationName is "U.S. Government” for 
all of these certificates, despite the other subject fields indicating 
organizations that are not a component of the US Government?

Jonathan

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

High traffic on this list, and Mozilla root program involvement

[Gervase Markham via dev-security-policy]

Hi everyone,

Wow, traffic on this group has exploded :-) Thank you to everyone who
has been bringing incidents to our attention.

Clearly, many of these items need official responses and action from
representatives of the Mozilla root program. I have been on holiday
quite a lot recently, and that includes this week, and any time I have
had has been fighting fires relating to my other responsibilities and
requirements placed on me. But please rest assured, all this has not
been forgotten.

In the mean time, I would hope CAs would be picking up incidents
relating to themselves, doing investigations and publishing
best-practice-style incident reports here once those investigations were
concluded. I probably need to write a wiki page on this, but in brief
best practice involves much more than "we revoked the certificates
concerned", it needs to say "this is how this happened", and "this is
what we've done/are doing to make sure it won't happen again".

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

[Nick Lamb via dev-security-policy]

Unless I am greatly misunderstanding this certificate appears unsuited to 
actual use in a web server, due to the Common Name not in the least bit 
resembling a DNS name or IP address. So this is a pretty clear example of the 
situation where a CA has misunderstood Mozilla policy requirements concerning 
what would be "in scope" for the policy, rather than issuing certificates that 
obviously could be used for TLS while denying that they "intended" to do so.

The Transparency log shows nothing since 2016, maybe FNMT can tell us whether 
this means all issuance from the affected subCA has ceased? If so maybe a 
revocation (including via OneCRL) is in order.

During the previous m.d.s.policy discussion we were assured that audits should 
pick up any such issuance. Was such an audit performed between the date of the 
assurance and today? Did it pick this up? I think the answer to that question 
is important _regardless_ of action specific to this incident because it will 
help inform the future use of audit.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Problem Reporting Mechanisms

[Tim Hollebeek via dev-security-policy]

See BR 1.5.2.  CAs are already required to have contact information in their 
CPS.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+thollebeek=trustwave@lists.mozilla.org] 
On Behalf Of David E. Ross via dev-security-policy
Sent: Tuesday, August 8, 2017 10:37 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Problem Reporting Mechanisms

On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
> 
>> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>>  wrote:
>>
>> On 16/05/17 02:26, userwithuid wrote:
>>> After skimming the responses and checking a few CAs, I'm starting to
>>> wonder: Wouldn't it be easier to just add another mandatory field to 
>>> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via 
>>> policy and just use that to provide a public list?
>>
>> Well, such contacts are normally per CA rather than per root. I guess 
>> we could add it on the CA's entry.
> 
> I've been reporting a fair amount of misissuance this week, and the responses 
> to the Problem Reporting question in the April CA communication leave a lot 
> to be desired. Several CAs do not have any contact details at all, and others 
> require filling forms with captchas.
> 
> I think it'd be very useful if CAs were required maintain a problem reporting 
> email address and keep it current in the CCADB, this requirement could go in 
> the Mozilla Root Store policy or the CCADB policy. If they want to also 
> maintain other modes of contact, they can but no matter what an email address 
> should be required.
> 
> Jonathan
> 

I think that a public point of contact for a certification authority was a 
requirement under Mozilla's policy.  I cannot find such a requirement now 
unless the Baseline Requirements, which are included by reference in Mozilla's 
policy, require it.

--
David E. Ross


President Trump demands loyalty to himself from Republican members of Congress. 
 I always thought that members of Congress -- House and Senate -- were required 
to be loyal to the people of the United States.  In any case, they all swore an 
oath of office to be loyal to the Constitution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062&d=m8yJ2Wj4I3PpA9lLssqYcKc5sstI-v_FHXLApAaMgw&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Fiedler, Arno via dev-security-policy]

Dear Mozilla Security Policy Community,

Thanks for the advice about the short serial numbers and apologies for the 
delayed response.

Since 2016, all D-TRUST TLS certificates based on electronic Certificate 
Requests have a certificate serial number which includes 64 bits of entropy.

Between 2012 and July 6th, 2017 we produced a small number of certificates with 
 paper-based Certificate Registration Requests using 64 bits of entropy in the 
"DNqualifier" field instead of the serial number field.

Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits of 
entropy in the serial number.

I hope this helps and please do not hesitate to contact us if there are any 
further questions.

Best regards
Arno Fiedler
Standardization & Consulting
Bundesdruckerei GmbH
Kommandantenstraße 18 · 10969 Berlin · Deutschland

Tel. :+ 49 30 25 98 - 3009
Mobil: + 49 172 3053272

arno.fied...@bdr.de · www.bundesdruckerei.de

Sitz der Gesellschaft: Berlin · Handelsregister: AG Berlin-Charlottenburg HRB 
80443. USt.-IdNr.: DE 813210005
Aufsichtsratsvorsitzender: Willi Berchtold
Geschäftsführer: Ulrich Hamann (Vorsitzender), Christian Helfrich

This message is intended only for the use of the individual or entity to which 
it is addressed, and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law. If the reader of this message 
is not the intended recipient, or the employee or agent responsible for 
delivering the message to the intended recipient, we hereby give notice that 
any dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this message in error, please delete the 
message and notify us immediately.
Diese Nachricht kann vertrauliche und gesetzlich geschützte Informationen 
enthalten. Sie ist ausschließlich für den Adressaten bestimmt. Wenn Sie nicht 
der beabsichtigte Adressat sind, möchten wir Sie hiermit darüber informieren, 
dass das Weiterleiten, Verteilen oder Kopieren dieser Mail nicht gestattet ist. 
Wenn Sie diese Mail irrtümlicherweise erhalten haben, informieren Sie uns bitte 
schnellstmöglich und löschen Sie bitte die Mail.

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

Re: dNSName containing '/' / low serial number entropy

[Arno Fiedler via dev-security-policy]

Dear Mozilla Security Policy Community,

Thanks for the advice about the short serial numbers and apologies for the 
delayed response. 

Since 2016, all D-TRUST TLS certificates based on electronic Certificate 
Requests have a certificate serial number which includes 64 bits of entropy. 

Between 2012 and July 6th, 2017 we produced a small number of certificates with 
 paper-based Certificate Registration Requests using 64 bits of entropy in the 
“DNqualifier” field instead of the serial number field. 

Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits of 
entropy in the serial number.

I hope this helps and please do not hesitate to contact us if there are any 
further questions.

Best regards
Arno Fiedler
Standardization & Consulting
Bundesdruckerei GmbH
Kommandantenstraße 18 · 10969 Berlin · Deutschland



Am Mittwoch, 19. Juli 2017 00:26:16 UTC+2 schrieb Charles Reiss:
> https://crt.sh/?id=174827359 is a certificate issued by D-TRUST SSL 
> Class 3 CA 1 2009 containing the DNS SAN 
> 'www.lbv-gis.brandenburg.de/lbvagszit' (containing a '/') with a 
> notBefore in April 2017.
> 
> The certificate also seems to have a short certificate serial number, 
> which cannot include 64 bits of entropy. Many certificates issued by 
> this CA appears to use large serial numbers (e.g. [1]). But there are 
> certificates with much shorter sequential-looking serial numbers with 
> notBefores shortly before [2] and after [3] this certificate's and as 
> recent as 4 July 2017 [4].
> 
> [1] https://crt.sh/?id=137090990 , https://crt.sh/?id=124715040
> [2] 
> https://censys.io/certificates/4445455caca3e9cf2ab2b673304487cb220871aa6d5ac1bf03827f74609c3646
> [3] 
> https://censys.io/certificates/8d08033efe732e8fb6c2f3257c52b500af991bd1f363ffd6e29ec1812a943cd9
> [4] https://crt.sh/?id=173758922
> 
> 
> I did a cursory check on censys.io to see if there were other cases of 
> short serial numbers in certificates with recent notBefores that are 
> trusted by Mozilla:
> 
> - Digidentity Services CA - G2 (https://crt.sh/?caid=868 ; chains to 
> Staat der Nederlanden Root CA - G2) has issued certificates which serial 
> numbers that appear to be of the form 0x1000 + sequential counter 
> with notBefores as recent as 8 June 2017.
> 
> - Siemens Issuing CA Internet Server 2016 (https://crt.sh/?caid=26087 ; 
> chains to QuoVadis Root CA 2 G3) has issued certificates with 4-byte 
> serial numbers with notBefores as recent as 11 July 2017, though they do 
> not appear to be assigned sequentially.
> 
> D-Trust and QuoVadis both indicated no problems complying with version 
> 2.4.1 of Mozilla's certificate policies (which requires, among other 
> things, 64 bits of serial number entropy) by 1 June 2017 when they 
> replied to Mozilla's April CA communication. The Government of the 
> Netherlands indicated they needed a delay for CPS translation only.

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

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

[identrust--- via dev-security-policy]

On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
> that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
> required to have the plaintext HTTP scheme according to Baseline Requirements 
> section 7.1.2.2(c).
> 
> Here’s the list of certificates: https://misissued.com/batch/4/
> 
> Jonathan

IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in this 
context.  That being said, we have altered our profiles for certificates 
issued under this Sub CA to include only HTTP OCSP URLs.  All certificates 
issued going forward will contain an HTTP OCSP URL.  We will also examine all 
other sub CA to ensure only HTTP OCSP URLs are included.  Thank you for giving 
us an opportunity to address this with the community
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Problem Reporting Mechanisms

[Jonathan Rudenberg via dev-security-policy]

> On Aug 8, 2017, at 10:36, David E. Ross via dev-security-policy 
>  wrote:
> 
> On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
>> 
>>> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>>>  wrote:
>>> 
>>> On 16/05/17 02:26, userwithuid wrote:
 After skimming the responses and checking a few CAs, I'm starting to
 wonder: Wouldn't it be easier to just add another mandatory field to
 the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
 policy and just use that to provide a public list?
>>> 
>>> Well, such contacts are normally per CA rather than per root. I guess we
>>> could add it on the CA's entry.
>> 
>> I’ve been reporting a fair amount of misissuance this week, and the 
>> responses to the Problem Reporting question in the April CA communication 
>> leave a lot to be desired. Several CAs do not have any contact details at 
>> all, and others require filling forms with captchas.
>> 
>> I think it’d be very useful if CAs were required maintain a problem 
>> reporting email address and keep it current in the CCADB, this requirement 
>> could go in the Mozilla Root Store policy or the CCADB policy. If they want 
>> to also maintain other modes of contact, they can but no matter what an 
>> email address should be required.
>> 
>> Jonathan
>> 
> 
> I think that a public point of contact for a certification authority was
> a requirement under Mozilla's policy.  I cannot find such a requirement
> now unless the Baseline Requirements, which are included by reference in
> Mozilla's policy, require it.

Yes, section 4.9.3 of the Baseline Requirements says:

> The CA SHALL provide Subscribers, Relying Parties, Application Software 
> Suppliers, and other third parties with clear instructions for reporting 
> suspected Private Key Compromise, Certificate misuse, or other types of 
> fraud, compromise, misuse, inappropriate conduct, or any other matter related 
> to Certificates. The CA SHALL publicly disclose the instructions through a 
> readily accessible online means.

However, it does not specify that email is required. I’m proposing that Mozilla 
require that one of the methods for reporting be email and that the email 
address be recorded in the CCADB.

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

Re: CA Problem Reporting Mechanisms

[David E. Ross via dev-security-policy]

On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
> 
>> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>>  wrote:
>>
>> On 16/05/17 02:26, userwithuid wrote:
>>> After skimming the responses and checking a few CAs, I'm starting to
>>> wonder: Wouldn't it be easier to just add another mandatory field to
>>> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
>>> policy and just use that to provide a public list?
>>
>> Well, such contacts are normally per CA rather than per root. I guess we
>> could add it on the CA's entry.
> 
> I’ve been reporting a fair amount of misissuance this week, and the responses 
> to the Problem Reporting question in the April CA communication leave a lot 
> to be desired. Several CAs do not have any contact details at all, and others 
> require filling forms with captchas.
> 
> I think it’d be very useful if CAs were required maintain a problem reporting 
> email address and keep it current in the CCADB, this requirement could go in 
> the Mozilla Root Store policy or the CCADB policy. If they want to also 
> maintain other modes of contact, they can but no matter what an email address 
> should be required.
> 
> Jonathan
> 

I think that a public point of contact for a certification authority was
a requirement under Mozilla's policy.  I cannot find such a requirement
now unless the Baseline Requirements, which are included by reference in
Mozilla's policy, require it.

-- 
David E. Ross


President Trump demands loyalty to himself from Republican members
of Congress.  I always thought that members of Congress -- House
and Senate -- were required to be loyal to the people of the
United States.  In any case, they all swore an oath of office
to be loyal to the Constitution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

I was not advocating "letting everyone decide".  I was advocating that
Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.

This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.

This is similar to if a store boss gets a new surveillance camera in the
shop and sees that some employees are taking extra breaks when there are
few customers in the store.  It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door.  Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.

Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as a
BR change).

Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.

On 08/08/2017 15:16, Alex Gaynor wrote:

This methodology of "letting everyone decide which parts of the spec/BRs
aren't important" doesn't make sense. If there's something wrong with the
spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of
the "fetch" specification). Giving each CA unilateral authority to ignore
what they want is not how we get to a cleaner, better, more secure, spec or
PKI. BTW, the reason you know they were unilaterally ignoring things is
that this thread was started by an independent security researcher, and not
by the CAs in question!

If the CAs had noticed themselves, they could have sent an email to
m.d.s.p, "Hey, we noticed some of our certs were triggering warnings on
crt.sh, we looked into and it's because of an encoding issue with large
serials. We're revoking those certs, and looking into the bug in our
issuance code, but we're pretty sure this happened because the text in RFC
5280 is a bit vague, can we do something to make this more clear?"

Alex

On Mon, Aug 7, 2017 at 9:25 PM, Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Ryan Sleevi via dev-security-policy 
writes:


Pragmatically, does anything known break on the extra byte there?


Yes. NSS does. Because NSS properly implements 5280.


I would say that's probably more a flaw in NSS then.  Does anyone's
implementation seriously expect things to work, and by extension break if
they
don't, as 5280 says it should?  What happens to NSS if it sees a policy
explicitText longer than 200 bytes?  If it sees a CRL with an unknown
critical
extension?  If it sees a CRL with one of the extensions where you ignore
the
actual contents of the CRL and instead use revocation information hidden
in a
sub-extension (sorry, can't remember the name of that one at the moment).

That's just the first few things that came to mind, there are a million
(well,
thousands.  OK, maybe hundreds.  At least a dozen) bizarre, arbitrary, and
often illogical requirements (for example with the critical extension thing
the only sensible action is to do the opposite of what the RFC says) in
5280
that I'm pretty sure NSS, and probably most other implementations as well,
don't conform to, or are even aware of.  So saying "it happens to break our
code" is a perfectly valid response, but claiming better standards
conformance
than everyone else is venturing onto thin ice.

More generally, I don't think there's any PKI implementation that can
claim to
"properly implement 5280" because there's just too much weird stuff in
there
for anyone to fully comprehend and be conformant to.  As a corollary, since
there are also things in there that are illogical, a hypothetical
implementation that really was fully conformant could be regarded as broken
when it does things that the spec requires but that no-one would expect an
implementation to do.

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




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Can this be responded to more directly and comprehensively please?

Are there any staff or personnel being shared between WoSign and Startcom?
No

This includes any staff from (or paid by) Qihoo 360 its subsidiaries, 
contractors, or affiliates--does anyone do any work (paid or unpaid) for both 
Wosign and Startcom?
No

Are there any personnel switching between WoSign and Startcom?
No
 



On Tuesday, August 8, 2017 at 4:39:39 AM UTC-4, Inigo Barreira wrote:
> Hi,
> 
> 1.- yes, I said many times that it was not a good decission and of 
> course not the best way to start, but at all times these test certs 
> were under control, lived only for some minutes. Everything was 
> explained in bugzilla #1369359
> 
> 2.- Those pre-certificates were related to these test certificates for the CT 
> testing, and yes, technically they didn´t exist for EJBCA, so we were dealing 
> with them on how to revoke them without issuing them wrongly and finally got 
> a solution, and then inmediately revoked them.
> 
> So, these two issues were related to the same generic problem, the CT 
> testing, which was only for Chrome compliance, but that were all the time 
> controlled by us. It was a bad practice that it´s not happening again with 
> the countermeasures set as explained. 
> 
> 3.- No, there´s nothing related to Wosign nor Richard Wang. As indicated in 
> our remediation plan, 360 owns 100% of StartCom and we´ve performed all the 
> changes proposed there to have nothing related to Wosign nor Richard. This is 
> indicated in bugzilla #1311832 and also in the remediation plan delivered 
> last year.
> Also in our remediation plan, there was a chart in which was indicated how 
> the Company is structured, and in the case of StartCom Spain, this is 100% 
> owned by the StartCom UK, and I´m director in both offices.
> 
> And the reason why Richard Wang is director again in StartCom UK is due to 
> some bank issues. Richard was removed as director of the StartCom UK at that 
> time, but didn´t realize about his signatory rights in the UK bank account. 
> We thought we could change that easily but was not possible. We´ve been 
> dealing with our lawyers, Alliotts, and finally agreed that signing again 
> Richard was going to be quicker and easier. I had planned to go to London for 
> changing it end of july, beginning of august but due to some personal 
> matters, it was imposible and have had to delay until September. Once we 
> finish this bank issue, Richard will be removed again.
> In any case these are internal issues that don´t affect the PKI itself, these 
> are administrative tasks, but the fact that Richard is again director in 
> StartCom UK is just for this matter and has no other responsibility or 
> function within StartCom.
> 
> 
> Let me know if you need more clarification or have some other doubts 
> or questions
> 
> Best regards
> 
> Iñigo Barreira
> CEO
> StartCom CA Limited
> 
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+inigo=startcomca.com@lists.mozilla
> .org] On Behalf Of Jakob Bohm via dev-security-policy
> Sent: lunes, 7 de agosto de 2017 22:03
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: StartCom cross-signs disclosed by Certinomis
> 
> On 07/08/2017 11:21, Franck Leroy wrote:
> > Hello
> > I see many reactions that are not in line with the reality because you 
> > don’t have all the history on the subject.
> > I’ll try to summarize.
> > Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque 
> > Country) and he left this company in order to join StartCom.
> > Not long after he arrives at StartCom (days? Weeks? I don’t know) we 
> > discover the deal that has been made by the previous CEO (Eddy Nigg) with 
> > the Chinese’s guys and the relations with WoSign.
> > Inigo could have resign in regard to the trap the hiring was, but he 
> > decided to face, and to setup the remediation plan defined by Mozilla 
> > community.
> > As said Jon Snow in S07E01: “I will not punish a son for this father’s 
> > sins”.
> > So instead of denigrate Inigo’s work, as a community we should encourage 
> > and support him.
> > Setting up a new company, with a new datacentre, new pki software, 
> > NO client, NO revenue, with Chinese employees far away speaking not fluent 
> > English and with the pressure of the market, it is definitely not an easy 
> > task! Personally I would not have tried this, so bravo for Inigo’s bravery… 
> > One of the major thing to solve in addition of the remediation plan was to 
> > be back in the business as soon as possible, because without any incomes a 
> > company cannot survive.
> > So Inigo contacted me to know if Certinomis could help him to be back in 
> > the business. As you can imagine we did not said yes immediately.
> > But Inigo is not an anonymous guy coming from a strange area of Spain. He 
> > has been for many years an active CABForum member. He is also an active 
> > expert at ESTI, 

Re: StartCom cross-signs disclosed by Certinomis

[urijah--- via dev-security-policy]

Can this be responded to more directly and comprehensively please?

Are there any staff or personnel being shared between WoSign and Startcom?
This includes any staff from (or paid by) Qihoo 360 its subsidiaries, 
contractors, or affiliates--does anyone do any work (paid or unpaid) for both 
Wosign and Startcom? Are there any personnel switching between WoSign and 
Startcom? 



On Tuesday, August 8, 2017 at 4:39:39 AM UTC-4, Inigo Barreira wrote:
> Hi, 
> 
> 1.- yes, I said many times that it was not a good decission and of course not 
> the best way to start, but at all times these test certs were under control, 
> lived only for some minutes. Everything was explained in bugzilla #1369359 
> 
> 2.- Those pre-certificates were related to these test certificates for the CT 
> testing, and yes, technically they didn´t exist for EJBCA, so we were dealing 
> with them on how to revoke them without issuing them wrongly and finally got 
> a solution, and then inmediately revoked them.
> 
> So, these two issues were related to the same generic problem, the CT 
> testing, which was only for Chrome compliance, but that were all the time 
> controlled by us. It was a bad practice that it´s not happening again with 
> the countermeasures set as explained. 
> 
> 3.- No, there´s nothing related to Wosign nor Richard Wang. As indicated in 
> our remediation plan, 360 owns 100% of StartCom and we´ve performed all the 
> changes proposed there to have nothing related to Wosign nor Richard. This is 
> indicated in bugzilla #1311832 and also in the remediation plan delivered 
> last year.
> Also in our remediation plan, there was a chart in which was indicated how 
> the Company is structured, and in the case of StartCom Spain, this is 100% 
> owned by the StartCom UK, and I´m director in both offices.
> 
> And the reason why Richard Wang is director again in StartCom UK is due to 
> some bank issues. Richard was removed as director of the StartCom UK at that 
> time, but didn´t realize about his signatory rights in the UK bank account. 
> We thought we could change that easily but was not possible. We´ve been 
> dealing with our lawyers, Alliotts, and finally agreed that signing again 
> Richard was going to be quicker and easier. I had planned to go to London for 
> changing it end of july, beginning of august but due to some personal 
> matters, it was imposible and have had to delay until September. Once we 
> finish this bank issue, Richard will be removed again.
> In any case these are internal issues that don´t affect the PKI itself, these 
> are administrative tasks, but the fact that Richard is again director in 
> StartCom UK is just for this matter and has no other responsibility or 
> function within StartCom.
> 
> 
> Let me know if you need more clarification or have some other doubts or 
> questions
> 
> Best regards
> 
> Iñigo Barreira
> CEO
> StartCom CA Limited
> 
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] 
> On Behalf Of Jakob Bohm via dev-security-policy
> Sent: lunes, 7 de agosto de 2017 22:03
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: StartCom cross-signs disclosed by Certinomis
> 
> On 07/08/2017 11:21, Franck Leroy wrote:
> > Hello
> > I see many reactions that are not in line with the reality because you 
> > don’t have all the history on the subject.
> > I’ll try to summarize.
> > Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque 
> > Country) and he left this company in order to join StartCom.
> > Not long after he arrives at StartCom (days? Weeks? I don’t know) we 
> > discover the deal that has been made by the previous CEO (Eddy Nigg) with 
> > the Chinese’s guys and the relations with WoSign.
> > Inigo could have resign in regard to the trap the hiring was, but he 
> > decided to face, and to setup the remediation plan defined by Mozilla 
> > community.
> > As said Jon Snow in S07E01: “I will not punish a son for this father’s 
> > sins”.
> > So instead of denigrate Inigo’s work, as a community we should encourage 
> > and support him.
> > Setting up a new company, with a new datacentre, new pki software, NO 
> > client, NO revenue, with Chinese employees far away speaking not fluent 
> > English and with the pressure of the market, it is definitely not an easy 
> > task! Personally I would not have tried this, so bravo for Inigo’s bravery… 
> > One of the major thing to solve in addition of the remediation plan was to 
> > be back in the business as soon as possible, because without any incomes a 
> > company cannot survive.
> > So Inigo contacted me to know if Certinomis could help him to be back in 
> > the business. As you can imagine we did not said yes immediately.
> > But Inigo is not an anonymous guy coming from a strange area of Spain. He 
> > has been for many years an active CABForum member. He is also an active 
> > expert at ESTI, where he was 

AC FNMT Usuarios and anyExtendedKeyUsage

[Jonathan Rudenberg via dev-security-policy]

The "AC FNMT Usuarios” intermediate operated by the Government of Spain, 
Fábrica Nacional de Moneda y Timbre (FNMT) issues certificates that are not 
BR-compliant. This was acknowledged during the FNMT root inclusion request 
discussion and allowed as long as the intermediate "never issues TLS/SSL 
certificates”[0].

Recently, some certificates issued from this intermediate were logged to CT, so 
we can see what they look like[1].

While they do not contain dnsName SANs, they do contain the anyExtendedKeyUsage 
EKU which makes them technically usable for TLS server authentication and in 
scope for the Mozilla Root Store Policy.

Additionally, I was able to find one of these certificates[2] served from a TLS 
server in Censys[3].

This is information that does not appear to have been available at the time of 
the root inclusion discussion last year, so I thought I’d point it out.

Jonathan

[0] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7wIZmwp4qGQ/wRQgVVz2CQAJ
[1] https://crt.sh/?Identity=%25&iCAID=6664
[2] https://crt.sh/?opt=cablint&id=145250473
[3] https://censys.io/ipv4/213.96.188.218


___
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

[Alex Gaynor via dev-security-policy]

Hi all,

Following up on this thread, 8 days ago I emailed Camerfirma, I have not
heard back from them, nor have they taken any action. What is the
appropriate next step here?

Alex

On Mon, Jul 31, 2017 at 10:14 AM, Alex Gaynor  wrote:

> I've been attempting to report a bunch of miss-issued certificates this
> weekend (hobbies are important!) I've primarily been using
> https://ccadb-public.secure.force.com/mozillacommunications/
> CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC&QuestionId=
> Q00028 as my reference (without which I would be totally lost!)
>
> So far I've encountered issues with:
>
> - DocuSign (OpenTrust/Keynectis) - who neglected to fill out that field
> - StartCom - who filled out "web publication", I don't know what that means
>
> To all the CAs who included a straightforward email or webform in there,
> thank you!
>
> Alex
>
> On Mon, Jul 31, 2017 at 10:10 AM, Gervase Markham via dev-security-policy
>  wrote:
>
>> On 25/07/17 18:13, Jeremy Rowley wrote:
>> > I would also love to see a more standardized notice mechanism that is
>> > universal to all CAs. Right now, notifying CAs is a pain as some have
>> > different webforms, some use email, and some don't readily tell you how
>> to
>> > contact them about certificate problems.
>>
>> "Not readily telling" is a BR violation; if you come across a CA like
>> that, please do let us know. The info should be in the CCADB and in the
>> CAs report.
>>
>> I agree it would be nice to have something more standard, but we have
>> what we have right now.
>>
>> Gerv
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Alex Gaynor via dev-security-policy]

Luckily we have tools like certlint, which can be run on certificates to
catch this stuff!

I'd feel very differently if CAs were starting these threads because they'd
caught issues with certlint, than the fact that independent researchers are
noticing.

Alex

On Tue, Aug 8, 2017 at 7:52 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 08/08/2017 12:54, Nick Lamb wrote:
>
>> On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm  wrote:
>>
>>> Since the CT made it possible, I have seen an increasing obsession with
>>> enforcing every little detail of the BRs, things that would not only
>>> have gone unnoticed, but also been considered unremarkable before CT.
>>>
>>
>> Even if I had no other reason to be concerned about violations of the BRs
>> (and I do have plenty, as we saw here in this case it looks like the
>> certificate can be revoked but it effectively can't) the Brown M&M Rider
>> reason is enough,
>>
>> The rider (hospitality and technical requirements for a performing
>> artist) can be pretty detailed, some venues may glance at it and agree to
>> whatever is inside without knowing the details. This is a _huge_ problem,
>> and Van Halen is famous for a clause in their rider (requiring a bowl of
>> M&Ms but with the brown ones removed) which they say existed not out of
>> spite but precisely to check that the venue had actually read the rider in
>> full and not just skimmed it, so that they would have early warning if a
>> particular venue were sloppy and might cause surprise problems with
>> technical implementation.
>>
>> We need CAs to be detail oriented. It is not enough to "kinda, mostly"
>> get this job right. If you can't do _exactly_ what it says in the BRs,
>> don't bother doing it at all. Neither Mozilla nor any other trust store
>> compel CAs to stay in this business, if they decide they'd rather sell
>> pancakes or mow lawns, that's up to them. So long as they want to be
>> trusted public CAs, they need to obey the rules that are in place to make
>> that safe for everybody.
>>
>>
> While the Brown M&M Rider argument would be good if, like the van Halen
> clause, there was only a small number of such intentional gotcha rules,
> in this case we are dealing with a large corpus of rules, some explicit,
> some in documents referenced from other documents etc.
>
> That makes the situation much more like the situation with other large
> sets of rules for people to follow, which means that there will, in
> practice, always be rules more important than others.  And hence a
> natural expectation that those tasked with enforcing the rules actually
> know the difference and don't issue large penalties for what is
> obviously minor infractions.
>
> Now in this *specific* case, it has been found that Mozilla's NSS
> doesn't handle HTTPS OCSP URLs in a good way, and thus Mozilla has a
> specific need to prevent their public use until NSS gains the ability to
> handle them safely (because there is a benefit to it).  Discussing that
> benefit and planning appropriate transition plans is an issue for
> another thread, possibly in another forum.
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Alex Gaynor via dev-security-policy]

This methodology of "letting everyone decide which parts of the spec/BRs
aren't important" doesn't make sense. If there's something wrong with the
spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of
the "fetch" specification). Giving each CA unilateral authority to ignore
what they want is not how we get to a cleaner, better, more secure, spec or
PKI. BTW, the reason you know they were unilaterally ignoring things is
that this thread was started by an independent security researcher, and not
by the CAs in question!

If the CAs had noticed themselves, they could have sent an email to
m.d.s.p, "Hey, we noticed some of our certs were triggering warnings on
crt.sh, we looked into and it's because of an encoding issue with large
serials. We're revoking those certs, and looking into the bug in our
issuance code, but we're pretty sure this happened because the text in RFC
5280 is a bit vague, can we do something to make this more clear?"

Alex

On Mon, Aug 7, 2017 at 9:25 PM, Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan Sleevi via dev-security-policy 
> writes:
>
> >>Pragmatically, does anything known break on the extra byte there?
> >
> >Yes. NSS does. Because NSS properly implements 5280.
>
> I would say that's probably more a flaw in NSS then.  Does anyone's
> implementation seriously expect things to work, and by extension break if
> they
> don't, as 5280 says it should?  What happens to NSS if it sees a policy
> explicitText longer than 200 bytes?  If it sees a CRL with an unknown
> critical
> extension?  If it sees a CRL with one of the extensions where you ignore
> the
> actual contents of the CRL and instead use revocation information hidden
> in a
> sub-extension (sorry, can't remember the name of that one at the moment).
>
> That's just the first few things that came to mind, there are a million
> (well,
> thousands.  OK, maybe hundreds.  At least a dozen) bizarre, arbitrary, and
> often illogical requirements (for example with the critical extension thing
> the only sensible action is to do the opposite of what the RFC says) in
> 5280
> that I'm pretty sure NSS, and probably most other implementations as well,
> don't conform to, or are even aware of.  So saying "it happens to break our
> code" is a perfectly valid response, but claiming better standards
> conformance
> than everyone else is venturing onto thin ice.
>
> More generally, I don't think there's any PKI implementation that can
> claim to
> "properly implement 5280" because there's just too much weird stuff in
> there
> for anyone to fully comprehend and be conformant to.  As a corollary, since
> there are also things in there that are illogical, a hypothetical
> implementation that really was fully conformant could be regarded as broken
> when it does things that the spec requires but that no-one would expect an
> implementation to do.
>
> Peter.
> ___
> 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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jakob Bohm via dev-security-policy]

On 08/08/2017 12:54, Nick Lamb wrote:

On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm  wrote:

Since the CT made it possible, I have seen an increasing obsession with
enforcing every little detail of the BRs, things that would not only
have gone unnoticed, but also been considered unremarkable before CT.


Even if I had no other reason to be concerned about violations of the BRs (and I do 
have plenty, as we saw here in this case it looks like the certificate can be 
revoked but it effectively can't) the Brown M&M Rider reason is enough,

The rider (hospitality and technical requirements for a performing artist) can be 
pretty detailed, some venues may glance at it and agree to whatever is inside 
without knowing the details. This is a _huge_ problem, and Van Halen is famous for 
a clause in their rider (requiring a bowl of M&Ms but with the brown ones 
removed) which they say existed not out of spite but precisely to check that the 
venue had actually read the rider in full and not just skimmed it, so that they 
would have early warning if a particular venue were sloppy and might cause surprise 
problems with technical implementation.

We need CAs to be detail oriented. It is not enough to "kinda, mostly" get this 
job right. If you can't do _exactly_ what it says in the BRs, don't bother doing it at 
all. Neither Mozilla nor any other trust store compel CAs to stay in this business, if 
they decide they'd rather sell pancakes or mow lawns, that's up to them. So long as they 
want to be trusted public CAs, they need to obey the rules that are in place to make that 
safe for everybody.



While the Brown M&M Rider argument would be good if, like the van Halen
clause, there was only a small number of such intentional gotcha rules,
in this case we are dealing with a large corpus of rules, some explicit,
some in documents referenced from other documents etc.

That makes the situation much more like the situation with other large
sets of rules for people to follow, which means that there will, in
practice, always be rules more important than others.  And hence a
natural expectation that those tasked with enforcing the rules actually
know the difference and don't issue large penalties for what is
obviously minor infractions.

Now in this *specific* case, it has been found that Mozilla's NSS
doesn't handle HTTPS OCSP URLs in a good way, and thus Mozilla has a
specific need to prevent their public use until NSS gains the ability to
handle them safely (because there is a benefit to it).  Discussing that
benefit and planning appropriate transition plans is an issue for
another thread, possibly in another forum.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Nick Lamb via dev-security-policy]

On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm  wrote:
> Since the CT made it possible, I have seen an increasing obsession with
> enforcing every little detail of the BRs, things that would not only
> have gone unnoticed, but also been considered unremarkable before CT.

Even if I had no other reason to be concerned about violations of the BRs (and 
I do have plenty, as we saw here in this case it looks like the certificate can 
be revoked but it effectively can't) the Brown M&M Rider reason is enough,

The rider (hospitality and technical requirements for a performing artist) can 
be pretty detailed, some venues may glance at it and agree to whatever is 
inside without knowing the details. This is a _huge_ problem, and Van Halen is 
famous for a clause in their rider (requiring a bowl of M&Ms but with the brown 
ones removed) which they say existed not out of spite but precisely to check 
that the venue had actually read the rider in full and not just skimmed it, so 
that they would have early warning if a particular venue were sloppy and might 
cause surprise problems with technical implementation.

We need CAs to be detail oriented. It is not enough to "kinda, mostly" get this 
job right. If you can't do _exactly_ what it says in the BRs, don't bother 
doing it at all. Neither Mozilla nor any other trust store compel CAs to stay 
in this business, if they decide they'd rather sell pancakes or mow lawns, 
that's up to them. So long as they want to be trusted public CAs, they need to 
obey the rules that are in place to make that safe for everybody.
___
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

[Inigo Barreira via dev-security-policy]

Hi Percy,

StartCom Spain exists since september last year. And it was included in the
remediation plan set in October last year, but at the time Gerv wrote that
email it didn´t exist officially, it took a while to be registered
officially in the "equivalent" spanish companies house.
The process started in august, it´s typically a holiday month, and it took
longer than expected because there were some organizations closed or with
few people working.


Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Percy via dev-security-policy
Sent: martes, 8 de agosto de 2017 2:39
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On Monday, August 7, 2017 at 2:36:10 PM UTC-7, Itzhak Daniel wrote:
> On Monday, August 7, 2017 at 11:03:27 PM UTC+3, Jakob Bohm wrote: 
> > 7. At Quihoo: Actually get rid of Richard Wang, not just change his
> >title from CEO to COO.
> 
> I didn't map the new hierarchy of the "Spanish" StartCom CA ("StartCom CA
Spain Sociedad Limitada"), having trouble registering to the Spanish company
house and pull documents (I pulled from 3rd party, but they're garbage [1]
[2]). I did mange to see that Mr. Barreira is the Directory but nothing on
the share holders or parent company.
> 
> I took a quick look at StartCom UK (as the information there is free) and
noticed Mr. Wang became a director again [3]... I wonder who is "StartCom CA
Spain Sociedad Limitada" parent/share holder, maybe a disclosure?
> 
> Links:
> 1. https://www.letsphish.org/files/StartCom-CA-SPA-Appointment.pdf
> 2. https://www.letsphish.org/files/StartCom-CA-SPA-Profile.pdf
> 3. https://beta.companieshouse.gov.uk/company/09744347

StartCom CA Spain Sociedad Limitada was not in the original hierarchy [1] or
the proposed hierarchy [2] . I request that StartCom makes a full disclosure
of the ownership information. 

In addition, in the WoSign remediation plan, WoSign Stated[3] that 

Due to the severity of issues noted within, the decision has been made to
address the above three areas as they fall under the areas of 1)
leadership/authority in WoSign and StartCom, 2) operational/business process
and 3) technology. 

If WoSign/Startcom has determined leadership/authority is the No.1 cause of
issues, why is Richard Wang appointed as a director of StartCom merely 6
month after his removal? This doesn't even mention his COO role at WoSign. 

[1]
https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/start
com%7Csort:relevance/mozilla.dev.security.policy/0pqpLJ_lCJQ/z69lmZ88DwAJ
[2]https://en.wikipedia.org/wiki/StartCom#cite_note-structure201612-9
[3]https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Inigo Barreira via dev-security-policy]

Hi,

In the remediation plan that was published in October there was a chart in
which was indicate how the group was going to change, from WoSign management
to be under 360 management. I can provide the information again if you wish.

StartCom Spain is 100% owned by Startcom UK, which is also 100% owned by the
Startcom HK which is the head of the group. Over this, there´s 360 managing
it all. I don´t think I have to share here the notary papers but this is how
it´s structured now.
About the incorporation of Richard, I already explained the reason, it´s
just a bank issue and it´s just temporary until we can change the signatory.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Itzhak Daniel via dev-security-policy
Sent: lunes, 7 de agosto de 2017 23:36
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On Monday, August 7, 2017 at 11:03:27 PM UTC+3, Jakob Bohm wrote: 
> 7. At Quihoo: Actually get rid of Richard Wang, not just change his
>title from CEO to COO.

I didn't map the new hierarchy of the "Spanish" StartCom CA ("StartCom CA
Spain Sociedad Limitada"), having trouble registering to the Spanish company
house and pull documents (I pulled from 3rd party, but they're garbage [1]
[2]). I did mange to see that Mr. Barreira is the Directory but nothing on
the share holders or parent company.

I took a quick look at StartCom UK (as the information there is free) and
noticed Mr. Wang became a director again [3]... I wonder who is "StartCom CA
Spain Sociedad Limitada" parent/share holder, maybe a disclosure?

Links:
1. https://www.letsphish.org/files/StartCom-CA-SPA-Appointment.pdf
2. https://www.letsphish.org/files/StartCom-CA-SPA-Profile.pdf
3. https://beta.companieshouse.gov.uk/company/09744347
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Inigo Barreira via dev-security-policy]

Hi, 

1.- yes, I said many times that it was not a good decission and of course not 
the best way to start, but at all times these test certs were under control, 
lived only for some minutes. Everything was explained in bugzilla #1369359 

2.- Those pre-certificates were related to these test certificates for the CT 
testing, and yes, technically they didn´t exist for EJBCA, so we were dealing 
with them on how to revoke them without issuing them wrongly and finally got a 
solution, and then inmediately revoked them.

So, these two issues were related to the same generic problem, the CT testing, 
which was only for Chrome compliance, but that were all the time controlled by 
us. It was a bad practice that it´s not happening again with the 
countermeasures set as explained. 

3.- No, there´s nothing related to Wosign nor Richard Wang. As indicated in our 
remediation plan, 360 owns 100% of StartCom and we´ve performed all the changes 
proposed there to have nothing related to Wosign nor Richard. This is indicated 
in bugzilla #1311832 and also in the remediation plan delivered last year.
Also in our remediation plan, there was a chart in which was indicated how the 
Company is structured, and in the case of StartCom Spain, this is 100% owned by 
the StartCom UK, and I´m director in both offices.

And the reason why Richard Wang is director again in StartCom UK is due to some 
bank issues. Richard was removed as director of the StartCom UK at that time, 
but didn´t realize about his signatory rights in the UK bank account. We 
thought we could change that easily but was not possible. We´ve been dealing 
with our lawyers, Alliotts, and finally agreed that signing again Richard was 
going to be quicker and easier. I had planned to go to London for changing it 
end of july, beginning of august but due to some personal matters, it was 
imposible and have had to delay until September. Once we finish this bank 
issue, Richard will be removed again.
In any case these are internal issues that don´t affect the PKI itself, these 
are administrative tasks, but the fact that Richard is again director in 
StartCom UK is just for this matter and has no other responsibility or function 
within StartCom.


Let me know if you need more clarification or have some other doubts or 
questions

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of Jakob Bohm via dev-security-policy
Sent: lunes, 7 de agosto de 2017 22:03
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On 07/08/2017 11:21, Franck Leroy wrote:
> Hello
> I see many reactions that are not in line with the reality because you don’t 
> have all the history on the subject.
> I’ll try to summarize.
> Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque Country) 
> and he left this company in order to join StartCom.
> Not long after he arrives at StartCom (days? Weeks? I don’t know) we discover 
> the deal that has been made by the previous CEO (Eddy Nigg) with the 
> Chinese’s guys and the relations with WoSign.
> Inigo could have resign in regard to the trap the hiring was, but he decided 
> to face, and to setup the remediation plan defined by Mozilla community.
> As said Jon Snow in S07E01: “I will not punish a son for this father’s sins”.
> So instead of denigrate Inigo’s work, as a community we should encourage and 
> support him.
> Setting up a new company, with a new datacentre, new pki software, NO 
> client, NO revenue, with Chinese employees far away speaking not fluent 
> English and with the pressure of the market, it is definitely not an easy 
> task! Personally I would not have tried this, so bravo for Inigo’s bravery… 
> One of the major thing to solve in addition of the remediation plan was to be 
> back in the business as soon as possible, because without any incomes a 
> company cannot survive.
> So Inigo contacted me to know if Certinomis could help him to be back in the 
> business. As you can imagine we did not said yes immediately.
> But Inigo is not an anonymous guy coming from a strange area of Spain. He has 
> been for many years an active CABForum member. He is also an active expert at 
> ESTI, where he was editing the CA policy for web authentication certificates. 
> Inigo is known for his expertise, trustworthiness, honesty and not the least 
> his sympathy. So when he said that he will build a new StartCom and engage 
> the remediation plan, we could trust him.
> We are a community, not only in order to do the “police” but also to support 
> each other’s. So my answer was “yes, we will see how we can help you in 
> respect with community expectations”.
> There was different possibilities to be back in the business while waiting 
> for a brand new CA root included in the browsers; reselling Certinomis 
> certificates, becoming