Re: StartCom & Qihoo Incidents

2016-10-14 Thread Eddy Nigg

On 10/14/2016 01:00 PM, Gervase Markham wrote:

K) StartCom impersonating mozilla.com.
https://bugzilla.mozilla.org/show_bug.cgi?id=471702 StartCom's
(former) CEO Eddy Nigg obtained a key and certificate for
www.mozilla.com and placed it on an Internet-facing server.

I do consider it a significant error of judgement for Eddy to have
chosen www.mozilla.com, rather than a site owned and controlled by him
or by a third party with whom he had an agreement, for his demonstration.


Well, at time I didn't think that much - I noticed it when requesting a 
certificate for startcom.org in order to investigate a completely 
different issue and later got one for mozilla.org (note it wasn't .com). 
Initially I thought about some really high-profile name, but then I 
tried with mozilla.org since I assumed that A) Mozilla will forgive me 
and B) I was frequently involved here at that time. :-)


Surprisingly it worked and I got my certificate for mozilla.org


On the other hand, this happened 8 years ago. I'd be interested in your
comments, Ryan, on whether you think it's appropriate for us to have
some sort of informal "statute of limitations". That is to say, in
earlier messages you were worried about favouring incumbents. But if
there is no such statute, doesn't that disadvantage incumbents? No code
is bug-free, and so a large CA with many products is going to have
occasional troubles over the years. If they then have a larger issue, is
it reasonable to go trawling back 10 years through the archives and pull
out every problem there's ever been? This is a genuine question, not a
rhetorical one.


I believe there is also something called "reasonability " - I believe 
during my tenure StartCom tried to reduce risks first and foremost 
through its policies, honestly and earnest. And then unintentional 
mistakes and issues can happen


Of course every CA wants to issue hundreds of thousands of certificates, 
but it usually doesn't start like this. I admit that some of the issues 
were due to growth pain, scalability or simply doesn't happen below a 
certain number of users/certificates. Any programmer working on larger 
scale projects and long enough in the profession can tell some stories 
about bugs that happen only every 50K or 50M time.


I don't want to offer cheap excuses, but reality has it that things do 
happen and this is also part of that "reasonability". CAs must however 
have policies and procedures in order to evaluate issues that do happen, 
make the correct assessment and deliver a reasonable solution based 
thereof. This is the logic of a correctly functioning CA (or other 
businesses for that matter), this is what auditors verify and what 
software vendors should expect.


There is no business, no software and no certificate authority without 
fault - realistically and reasonably.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: StartCom & Qihoo Incidents

2016-10-13 Thread Eddy Nigg

On 10/12/2016 10:11 PM, Ryan Sleevi wrote:

As Gerv suggested this was the official call for incidents with respect to 
StartCom, it seems appropriate to start a new thread.


Ryan, it was probably easy to dig up any possible claimed or proven 
issue ever surrounding StartCom during its ~ 10 years of operation. But 
if this is your level of measurement for remaining in a root store, than 
you have probably some other and larger CAs that would require your 
immediate attention more urgently



Incidents with StartCom:


As most issues have been discussed and explained at that time, I'm not 
sure about it's usefulness to repeat the same arguments and explanations 
again. Most issues you are listing were mostly minor (but makes your 
list longer of course) and have been effectively and properly dealt with.



K) StartCom impersonating mozilla.com. 
https://bugzilla.mozilla.org/show_bug.cgi?id=471702
StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
www.mozilla.com and placed it on an Internet-facing server.


You make this appear as if StartCom used its capacity as a certificate 
authority to somehow abuse somebody or something, but for the wider 
audience:


I was able to obtain a certificate for mozilla.org from Comodo without 
having the authority to validate said domain name - in fact I could have 
obtained also wild cards and many more certificates for any domain name 
would I have been willing to pay for it. I installed the certificate at 
a local server as a proof in the same fashion millions of web sites 
install theirs. The private key has never published to any third party 
and was eventually destroyed.


Interesting that you are using it to shoot the messenger from back then 
and list this as an item against StartCom :-)



I hope the above show that the odds are if the original StartCom systems are 
restored, we're likely to continue to have significant BR violations - a 
pattern StartCom has repeatedly demonstrated over several years.


There is no plan to use software that doesn't comply to the various 
requirements and it has never been. I'm not claiming that there have 
been zero issues during the last ten years, but StartCom has had always 
clear policies and practices in place about how to deal with an issue 
reasonably according to its significance, seriousness and importance.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: WoSign: updated report and discussion

2016-10-13 Thread Eddy Nigg

On 10/11/2016 11:57 AM, Gervase Markham wrote:


There is also the case of StartEncrypt. While no known
cert-to-wrong-person misissuance occurred because the researchers in
question used domains they already controlled to prove their point, but
there seemed to be multiple holes by which this might be possible.


I haven't forgotten it and mentioned that Inigo has several tasks at hand:

"/... he'll have to review also other areas and implement controls in 
case they were lacking or insufficient, something he's doing as we speak/"


This includes obviously development cycles and other areas, even if no 
issues have been detected or reported.



Of course, people can reasonably disagree on the seriousness of the
issue (standalone, and by comparison with e.g. WoSign issue N), and it
is true that StartCom took this codebase wholesale from WoSign, but it
seems incomplete to leave this out entirely.


It wasn't my intention to ignore it, but I understand that this issue 
has been quickly contained at that time.




Eddy: does StartCom currently have any fully-automated certificate
issuance mechanisms, or does every certificate request pass by human
eyes before issuance?


Generally speaking it's semi-automated with a flagging system that 
forces about 20% of all lower level certificates for a manual review and 
approval by the verification team. Of course EV and code signing 
certificates are issued only manually. The rest is issued automatically.


--
Regards
Signer:     Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: WoSign: updated report and discussion

2016-10-11 Thread Eddy Nigg

Hi Kathleen,

On 10/10/2016 09:39 PM, Kathleen Wilson wrote:

I would like to remind everyone that when making decisions about what to do 
about CA mis-issuance, it is expressly *not* a goal for me to mete out 
punishment. Rather, my primary goal is to help keep end-users safe, based on 
the information that is available.


Allow me to add some of my thoughts into the discussion. I've read most 
of the comments and arguments made here so far and assume that most 
participants have the relevant information so that I don't have to 
repeat them again


I was directly responsible for StartCom for many years and gained some 
experience in running a certificate authority, writing policies and 
implementations thereof. I've helped to draft important guidelines and 
requirements for CAs and in general learned about the mesh of software 
vendors, certificate authorities and (web) PKI. I'm probably one of the 
faces of this industry and would offer my two cents in this capacity 
hereby


The problematic issue in relation to StartCom is obviously the _two 
backdated SHA1 certificates_ - however from the strictly technical point 
of view I don't think that the user-base of Mozilla in general and the 
relying parties in particular were much more at risk than relying on any 
other SHA1 certificate that was obtained legitimately before the 1st of 
January 2016. The risks were probably minimal since the certificate 
properties besides that were validated correctly.


However, a completely different matter must be considered here - that of 
compliance to the requirements set forth by the relevant bodies and 
software vendors. Besides the _loss of trust_ in this particular case, 
non-compliance happens many times due to _insufficient controls_. Being 
it either that the requirements weren't correctly understood (not the 
case here), or insufficient controls to prevent such non-compliance and 
wrongful certificate issuance.


The remediation and corrections StartCom proposed are significant in 
this respect - basically Mr. Richard Wang has been removed from his 
position and unfortunately for him is paying a high price for 
overstepping his authority. The parent company (WoSign) too has been 
released of all its responsibilities and a full separation has been set 
into motion.


The choice of Inigo Barreira as the new CEO of StartCom is probably a 
good one and we all assume that he wouldn't approve the backdating of 
certificates judging from his long-time recordhowever one of the 
immediate tasks of Inigo will be to implement controls that will make 
such abuse impossible - not by him and not by anybody else. I believe 
this is the _core issue and remediation_ here, which was the failure in 
first place.


(Obviously he'll have to review also other areas and implement controls 
in case they were lacking or insufficient, something he's doing as we 
speak).


But by looking at StartCom's performance besides that, I believe that 
some of the voices and arguments haven't been reasonable during this 
discussion! Was there a CA certificate compromise? Has StartCom lost 
control of its issuance processes? Has StartCom in general failed to 
validate certificate properties correctly? Has StartCom lost its ability 
to abide and comply to the policies and requirements set forth? Has and 
does StartCom present an undue risk to the user-base of Mozilla (and 
relying parties in general)?


I believe that none of the above applies which would warrant such 
dramatic steps on part of the software vendors and StartCom is generally 
operating correctly. The particular failure that did happen can be dealt 
with properly, firmly and professionally as proposed; _without knocking 
StartCom out of business_. I believe StartCom is still an important part 
of today's SSL landscape and it shouldn't be in anybody's interest to 
remove it as a viable alternative to current mix of the established 
certificate authorities - except if somebody is looking for revenge or 
other personal matters


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: WoSign and StartCom: next steps

2016-10-09 Thread Eddy Nigg

On 10/07/2016 12:38 PM, Gervase Markham wrote:

I am a little surprised it hasn't appeared by now. We did not agree a
specific deadline, but my impression was that it would appear in a few
days, which I mentally interpreted as "by the end of the week". Today is
Friday, so there is still time for my vague expectations to be met :-)

I'm sure Edward, Tan and Inigo are working on it furiously. Perhaps they
can give a status update and an estimated time of publication?


Hi Gerv,

I'm sorry for the somewhat late reply due to holidays/weekends and 
flight connections of the participants of the meeting. First thanks for 
hosting the meeting and I'm sorry that I personally couldn't attend.


WoSign already provided its incident report which includes basically 
most information regarding the various issues and failures. There were 
parts of the proposed steps mentioned already, hereby I'm trying to 
summarize it. Next week we'll add sub sections and dates to it:



1)  Legal Structure - Separation of StartCom and Wosign's legal 
structure - StartCom reports directly to Qihoo 360.


2)  Management / Board - Mr. Tan is appointed Chairman of StartCom, 
Inigo Barreira appointed CEO/Director of StartCom.


3)  Team / Operations - Tan and Inigo work to separate StartCom and 
Wosign verification, development and management teams. Basically any 
previously shared functions (where they existed) will be separated.


4)  System / Software - Any shared infrastructure will be separated 
from WoSign, current code base will be reviewed by Qihoo 360 and audited 
internally. StartCom makes the systems available for an external 
security audit as necessary.


5)  All certificates past, present and future will be logged with CT 
compliant log servers.


6)  Public Documentation - StartCom will present its near-term plan 
and update as it progresses.



Item 6 is currently the outlined steps above, plus most specifications, 
sub steps, specific dates in particular for items 3 and 4. I assume that 
steps and promises StartCom commits to will be audible and/or easy to be 
confirmed.


I assume that Inigo will report to the mailing list sometimes directly 
too in order to update on the progress.


--
Regards
Signer:     Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: WoSign and StartCom audit reports

2016-09-26 Thread Eddy Nigg

On 09/23/2016 10:11 PM, Peter Bowen wrote:

On Fri, Sep 23, 2016 at 10:46 AM, Eddy Nigg <eddy_n...@startcom.org> wrote:

Speaking only for StartCom here, as far as I know and as per auditing
standards, all intermediate CAs are audited (no external intermediates
existed).

As to network security, I believe this is part of the Baseline Requirements
audit. But if necessary I can ask our auditors and also WebTrust directly if
there is really missing something. I assume that all is included, covered
and implied, but should a mistake have happened in the statements made by
the auditors I'm sure we can get a corrected statement or explanation.

I'm super happy that this was all checked.  I know other auditors have
re-issued opinion letters when they missed things unintentionally.
Maybe you could ask EY to reissue to include the list of SubCAs and
the full coverage.


Traditionally the intermediate CA certificates were never listed 
explicit, at least in our audit reports. Intermediate CA certificates 
can change more frequently and I assume that's the reason for it.


I don't like to bother them unnecessarily, but should Mozilla come to 
the conclusion that something was indeed missing, I'll go and get it 
from them.



One other question on your report:  It says the services were provided
at Eilat, Israel during the period Jan 1, 2015 to Dec 31, 2015.
Richard said in an email a few hours ago that the StartCom validation
team was also in the UK.  Did that team not spin up until January 2016
or later?


The UK team was trained and started to work much later in 2016. Besides 
that some of the Israeli personnel is until this very date still in the 
UK overseeing the operation there.


But what the audit concerns, this is not part of the 2015 report, that's 
correct.


--
Regards
Signer:     Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: WoSign and StartCom audit reports

2016-09-23 Thread Eddy Nigg

On 09/23/2016 05:53 AM, Peter Bowen wrote:

Review of StartCom audit reports
for the period 1 January 2015 to 31 December 2015

Good:
- Uses AICPA standards
- Uses current criteria versions

Bad:
- Only covers two roots, not subordinate CAs (true for all three
reports: CA, BR, and EV)
- Does not provide assurance that subordinate CA certificate requests
are accurate, authenticated, and approved
- Does not provide assurance that it meets the Network and Certificate
System Security Requirements as set forth by the CA/Browser Forum



Speaking only for StartCom here, as far as I know and as per auditing 
standards, all intermediate CAs are audited (no external intermediates 
existed).


As to network security, I believe this is part of the Baseline 
Requirements audit. But if necessary I can ask our auditors and also 
WebTrust directly if there is really missing something. I assume that 
all is included, covered and implied, but should a mistake have happened 
in the statements made by the auditors I'm sure we can get a corrected 
statement or explanation.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: Incidents involving the CA WoSign

2016-09-06 Thread Eddy Nigg

On 09/05/2016 10:54 AM, Gervase Markham wrote:

Hi Eddy,

On 04/09/16 09:51, Eddy Nigg wrote:

I don't want to extend this discussion unnecessarily, but as a side note
you don't know which agreements this employee has signed with StartCom
and/or WoSign and hence you can't make a judgement on it either. Lets
leave this to the professionals dealing with it.

If he has signed an agreement with StartCom and/or WoSign which prevents
him from pointing out, after leaving employment, facts which are in the
public domain, then I suggest that those clauses in the agreement are an
unconscionable[0] restriction on his freedoms and you should not be
enforcing them.


Again, I don't think we can and will solve this in public, however I 
believe it's the complete right of a company (and employer) to decide 
how and when it wants to make an official public announcement about its 
business (and being just in order to complete a currently ongoing 
transaction first).


Not every employee is authorized to represent the company and inform 
third parties (at his/her convenient timing and consideration) even if 
he/she knows about it and/or some information has been placed into 
(partly) public domain as part of a business process.


I hope my explanation makes it clear that this ex-employee was not 
authorized to provide any information about StartCom or WoSign.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: [FORGED] Re: Incidents involving the CA WoSign

2016-09-05 Thread Eddy Nigg

On 09/04/2016 09:20 AM, Peter Gutmann wrote:

Peter Bowen <pzbo...@gmail.com> writes:


It was brought to my attention that there is another incident.

This is great stuff, it's like watching a rerun of Diginotar


.says the audience on the backbenches gleefully

but no, what are you talking about?? Even though some nasty and 
undesired errors happened here, its in no comparison to what happened at 
Diginotar which basically lost control over the CA.



--
Regards
Signer:     Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: Reuse of serial numbers by StartCom

2016-09-04 Thread Eddy Nigg

On 09/02/2016 07:02 PM, Nick Lamb wrote:

On Friday, 2 September 2016 08:50:02 UTC+1, Eddy Nigg  wrote:

Lets speak about relying parties - how does this bug affect you?

As a relying party I am entitled to assume that there is no more than one 
certificate signed by a particular issuer with a certain serial number. If I 
have seen this certificate and verified by whatever means I choose that it's 
OK, then I can safely assume that any time I see a certificate in the future 
signed by that issuer with that same serial number it's the same one, and skip 
the verification process.


Well, according to the CA policies and relying party terms, you should 
always check with the CRL or OCSP responders if a certificate is 
considered valid or not. So the verification process shouldn't be 
skipped beyond the advertised refresh time (in CRLs/OCSP).


Of course if you do some sort of certificate pinning based on serial and 
issuer, than this wouldn't work. But I'm not aware of any common 
software that doesn't use the certificate's public key for pinning and 
relies just on a serial numbers.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: Incidents involving the CA WoSign

2016-09-04 Thread Eddy Nigg

On 09/03/2016 11:02 PM, Percy wrote:

I agree completely that we shouldn't imply fundamental guilt by
association. However, WoSign threatened legal actions against Itzhak
Daniel's disclosure compiled purely from public sources. I just want to
make sure the disclosure was not buried after the content was taken down.


I don't want to extend this discussion unnecessarily, but as a side note 
you don't know which agreements this employee has signed with StartCom 
and/or WoSign and hence you can't make a judgement on it either. Lets 
leave this to the professionals dealing with it.


(Of course your copying and distributing of the content originally 
published by him can be also used against him, just some food for thought)


As such, there can be many more things you don't really know regarding 
this or other business transactions. And probably this is the wrong 
forum for such matters in any case.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: Reuse of serial numbers by StartCom

2016-09-02 Thread Eddy Nigg

On 09/02/2016 09:38 AM, Jakob Bohm wrote:

4. Violations that are purely technical but cannot actually endanger
relying parties (such as issuing non-unique certificates to the correct
entities, or issuing certificates with too early expiry dates). This
would be the case with the StartCom serial number assignment bug.

The way Eddy Nigg describes the issue, it appears there is some kind of
low level race condition in the code or hardware that increments and
uses the serial number counter deep inside the CA, perhaps in a heavily
locked down HSM that prevents fixing the issue without generating a new
CA key.


You are pretty close



If this is the case, and they correctly store the actually issued
certificates with the wrong serial numbers, the main problem would be
the inability to revoke one certificate without revoking the others,
while a secondary problem could be relying parties rejecting the
certificates if they actually see more than one of a set of conflicting
ones within their local cache lifetime.  Since both of those problems
would be limited to the certificates not being trusted when the facts
that should get them trusted are in place, there is no real danger.


You nailed it - I just asked the question about how it affects relying 
parties in an other reply to the list, you answered already.




StartCom is of cause one of those high speed DV CAs, that promise cheap
DV issuance within minutes of the request being submitted.  So
preventing occasional non-dangerous (but obviously non-compliant)
serial number collisions would require more than average skill by
hardware, firmware and software engineers.


True - and this was planned AND implemented.



That said, they really, really should have set up an automated test
script that scans issued certificates for the problem and raises an
alarm so such certificates would be reissued (with distinct serial
numbers) and revoked within a few days of each failure.



True that we could have done what you suggested. I don't really recall 
why we didn't, though I think things got easier with CT today for 
similar issues.
The fact is that it didn't had really an effect on the certificate 
holder or relying parties (except in case of a revocation in which case 
both certificates would have been revoked and probably issued again 
depending on the circumstances of the revocation).


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: Reuse of serial numbers

2016-09-02 Thread Eddy Nigg

On 09/01/2016 01:29 PM, Peter Gutmann wrote:

I also get the feeling that a lot of PKI software won't handle the revocation
properly, because they're expecting to revoke *the* certificate, not the
certificate, and the other certificate, and that other one there too, and that
one in the corner, and ... .  In other words I'm assuming most code will treat
serial numbers as unique and assume the revocation acted on when the first
cert has been marked as invalid.



From my experience, once one of the certificates has been revoked, it's 
basically for all of them with the same serial and issuer. At the PKI 
all certificates with the same serial must be revoked however to get a 
unique serial order.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: Reuse of serial numbers by StartCom

2016-09-02 Thread Eddy Nigg

On 09/01/2016 11:52 AM, Nick Lamb wrote:

On Thursday, 1 September 2016 08:54:16 UTC+1, Eddy Nigg  wrote:

Not so, rather according to my assessment, the cost and everything it
entailed (including other risks) to fix that particular issue outweighed
the benefits for having it fixed within a time-frame shorter than that.

It seems to me that was not your decision to make. The relying parties trust StartCom on 
the basis that it will do what it said it would do, not just whatever "in your 
assessment" offers most benefits to you. The only option that was permissible 
without seeking some exception was to cease issuance until the problem was repaired.


First of all the issue can have been considered fixed due to machine 
test - evidence for some occurrences took month to resurface and at such 
low numbers that couldn't be reproduced (something almost required to 
fix a bug). I'm not sure if you or others here are programers, but 
knowing how things work and once we had evidence that there was still a 
very low occurrence, a plan was set up which included a different 
hardware and infrastructure.



To StartCom, ceasing issuance feels like a really big risk, that is understood. 
But for the relying parties it's not.


Lets speak about relying parties - how does this bug affect you?

--
Regards
Signer:     Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: Reuse of serial numbers by StartCom

2016-09-01 Thread Eddy Nigg

On 09/01/2016 04:20 AM, Matt Palmer wrote:
That sounds an awful lot like "we can't fix our own systems", which is 
a... terrifying thought. 


Not so, rather according to my assessment, the cost and everything it 
entailed (including other risks) to fix that particular issue outweighed 
the benefits for having it fixed within a time-frame shorter than that.


"Some time" being about a year longer than you stated it would take in 
the bug. That's quite some time. 


If hardware changes and other infrastructural changes are involved than 
this time-frame can reasonable perhaps. CA infrastructures are usually 
not fast-moving ones according to my experience. This wasn't about 
changing a line or two in some software component.


You were knowingly violating a MUST provision of RFC5280. 


From experience there have been many RFC violations, sometimes even 
knowingly and intentionally by software vendors (browsers), certificate 
authorities and even policy writers such as CAB Forum.


Mozilla, Microsoft, Google and others are sometimes violating or not 
conforming to RFCs for this reason or the other. The implication and 
severity of such a violation matters probably.



The audit letter included an attestation from Management that, during the
time of the audit, management believed that the CA complied with the
Baseline Requirements.


True, we could demonstrate steps performed, plans produced, 
implementations performed etc. on this particular issue.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: Reuse of serial numbers by StartCom

2016-08-31 Thread Eddy Nigg

On 08/31/2016 05:56 AM, Peter Bowen wrote:

In reviewing the Certificate Transparency logs, I noticed the StartCom
has issued multiple certificates with identical serial numbers and
identical issuer names.

https://crt.sh/?serial=14DCA8 (2014-12-07)
https://crt.sh/?serial=04FF5D653668DB (2015-01-05)
https://crt.sh/?serial=052D14BA553ED0 (2015-02-07)
https://crt.sh/?serial=05B42A4FE11129 (2015-05-17)
https://crt.sh/?serial=0615C666E8C56E (2015-08-05)
https://crt.sh/?serial=0693A7FCC84DD3 (2015-11-10)

Each of these serial numbers has two distinct certificates with no
apparent relation between the subject entities.


There were a couple of certificates which resulted in duplicate serials 
- this could happen under certain circumstances, a bug that has been 
fixed by now. We'll look into revoking and reissuing them.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>

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


Re: StartEncrypt considered harmful today

2016-07-02 Thread Eddy Nigg

On 07/01/2016 05:54 PM, Patrick Figel wrote:


Can you comment on how your backend checks would have prevented any
misissuance? My understanding of the report is that this was not so much
an issue with the client software, but rather an oversight in the
protocol that allows Domain Validation checks that are not sufficient in
assuring domain ownership, thus the issue was very much a backend issue.
I assume there are reasonable controls in place to prevent misissuance
for high-risk domains, but what about other domains? Would they have
been affected by this?


Hi Patrick,

Depending on the flagging parameters and the attending certificate 
officer, the (some) certificate might or might have not been issued - 
I'm careful with this statement as suspicion can arise for this or the 
other reason, but it's not 100%. High-profile names would have been 
flagged and not issued though.



I would also be curious about why the certificate has not been logged to
CT, given StartCom's prior statements with regards to CT adoption.


We are checking it, it might have been logged at the wrong place. I'll 
try to provide an answer on this too when possible.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>
Blog:   Join the Revolution! <http://blog.startcom.org>
Twitter:Follow Me <http://twitter.com/eddy_nigg>

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


Re: StartEncrypt considered harmful today

2016-07-01 Thread Eddy Nigg

On 06/30/2016 06:30 PM, Rob Stradling wrote:

https://www.computest.nl/blog/startencrypt-considered-harmful-today/

Eddy, is this report correct?  Are you planning to post a public 
incident report?


Hi Rob and all,

There were indeed a couple of issues with the client software - known 
bugs have been fixed by our developers (hope there wont be anything more 
significant than that :-) ).


So far less than three hundred certificates have been issued using this 
method, none should have been effectively issue wrongfully due to our 
backend checks.


At the moment I don't believe that a public incident report is 
necessary, but should anything change in our current assessment we will 
obviously act accordingly. I instructed additional verifications and 
confirmations to assert that assessment.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. <http://www.startcom.org>
XMPP:   start...@startcom.org <xmpp:start...@startcom.org>
Blog:   Join the Revolution! <http://blog.startcom.org>
Twitter:Follow Me <http://twitter.com/eddy_nigg>

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


Re: Only accepting 2048 bit or better certificates

2014-06-25 Thread Eddy Nigg

On 06/21/2014 07:15 PM, Kurt Roeckx wrote:

But I would like to start enforcing the 2048 bit as soon as
possible.  Do we have some criteria for at which point we're
willing to break compatibility?



I'm in favor of enforcing it which will help reduce even mistakenly 
issued certificates with smaller keys to be detected quickly and there 
will be no incentive to use such keys for web sites (there are other 
use-cases for non-browsers and those should be still permitted I guess).


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. http://www.startcom.org
XMPP:   start...@startcom.org xmpp:start...@startcom.org
Blog:   Join the Revolution! http://blog.startcom.org
Twitter:Follow Me http://twitter.com/eddy_nigg

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


Re: Revocation Policy

2014-04-27 Thread Eddy Nigg

On 04/26/2014 06:45 PM, Zack Weinberg wrote:

If a business chooses to give some or even all of its services away
free, those who benefit from those services are still customers and
still in the same ethical relationship with the business as people who
paid for services (perhaps the same service, perhaps not).


We call all of them subscribers and we make no difference between a 
paying subscriber and non-paying - the difference is only the 
verification level and respective certificates according to that level. 
Some of the services carry a fee and some don't - for example no 
validated subscriber pays actually for the certificates, he/she pays for 
the validations performed which entitles them for certain type of 
certificates.



In particular, the business may *not* duck out of ethical obligations
incurred by circumstances beyond any customer's control (e.g.
catastrophic bugs in software everyone relies on ;-) just because some
of its customers are not *paying* customers.


Nobody ducks here - such a bug is not under the control of the 
subscriber and not of the issuer of the certificates, nor can the 
issuing instance control with which software the certificates are being 
used, how the keys are handled and so forth.


This is not a one-way street and it takes at least two to tango. The 
subscriber has to comply to the terms and conditions (Subscriber 
Obligations) the issuer set forth. And the subscriber has to pay certain 
fees when they apply.



CAs should be carrying insurance to cover exactly this sort of
low-probability-but-still-foreseeable, high-cost event.


Interestingly CAs can insure themselves for mistakes made at their end 
(errors and omission, but not for mistakes of others. That's exactly the 
reason why those costs can't be turned onto the insurer (otherwise we'd 
have done exactly that).


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. http://www.startcom.org
XMPP:   start...@startcom.org xmpp:start...@startcom.org
Blog:   Join the Revolution! http://blog.startcom.org
Twitter:Follow Me http://twitter.com/eddy_nigg

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


Re: Revocation Policy

2014-04-27 Thread Eddy Nigg

On 04/25/2014 08:50 PM, Jan Lühr wrote:

What's your argument here? Is crying foul Unjustified, because
nobody cried foul the moment you published your policies?


It's unjustified if as a subscriber you are not willing to accept the 
terms and conditions of that service, e.g. you want to accept the 
convenient part of it but not commit to your obligations.



Please consider: Heartbleed-scale problems have hardly happened before.


True - the closest would be probably the Debian weak keys.


I'ven't considered any mass-key-compromise scenarios before


I did - I learned from the Debian weak keys a lot.


Personally, I am crying foul because I'm re-thinking your policies
having heartbleed in mind.


You can't really rethink our policies, this is something we might have 
to do at some point. You can either agree or disagree with them though.



Personally, I vote no. StartSSL is not revoking certificates assumed to
be compromised, if a subscriber doesn't pay.


You are expecting to receive all benefits without taking responsibility 
for your part? Or lets put it like this:


As you stated before, how likely is it that such an event like this one 
occurs? It might have never happened and in fact some 83% are not 
affected (world-wide), which means that they will happily keep obtaining 
certificates without ever paying a dime. Would you have used a different 
software, you could be easily one of those 83% too.


Now, exactly because of this and other scenarios, where revocation of a 
certificate is necessary or is requested for any other reason by the 
subscriber and it's not due to a failure of the CA we decided to charge 
a fee in order to protect us from losses. Otherwise the current business 
model would probably not work...and I'm not even talking about easy 
abuse that's possible with the current model without raising a fee.



-  You say it is small / low by describing the circumstances under which
it happens and causes an impact.


Currently the facts show that StartCom's revocation numbers are not 
lower, in fact a bit above average. And here some more interesting 
facts: 
http://news.netcraft.com/archives/2014/04/25/heartbleed-why-arent-certificates-being-revoked.html



--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. http://www.startcom.org
XMPP:   start...@startcom.org xmpp:start...@startcom.org
Blog:   Join the Revolution! http://blog.startcom.org
Twitter:Follow Me http://twitter.com/eddy_nigg

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


Re: Revocation Policy

2014-04-24 Thread Eddy Nigg

On 04/24/2014 05:04 AM, Radu Hociung wrote:

On Wednesday, April 23, 2014 6:00:41 PM UTC-4, Eddy Nigg wrote:


I do have a few questions to you! How can you know that a site using a
certificate from ANY CA isn't or wasn't affected by the Heartbleed bug?

I'm planning on a more thorough answer that cross references the SSL 
observatory data from 2010 with a fresh update, and with published CRLs. One 
would expect that each CA would have about 17% of their issued certificates be 
revoked and re-keyed due to heartbleed. In a day or two I should have some 
stats.


Don't waste your time, I'll help you: https://isc.sans.edu/crls.html

Now, using current data from Netcraft which I'm not really allowed to 
publish shows StartCom with slightly above 100,000 certificates. Without 
leaking any more data from Netcraft I can tell you that the revocation 
rate of StartSSL is in fact higher than any other CA except GlobalSign, 
but their situation is unique (and maybe also problematic due to the CRL 
size).


Assuming that 17% of all certificates were affected by teh bug you can 
see easily that about 1.5% of all certificates were revoked in average 
excluding GlobalSign. StartCom's revocations is currently slightly short 
of 2%, above average.


It also means that in average there are still 15.5% of certificates that 
might be affected and still not revoked, assuming none of them expired. 
Not that I believe that those keys in fact have been compromised, but 
applying your logic there are a bunch of CAs you probably should disable 
now.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. http://www.startcom.org
XMPP:   start...@startcom.org xmpp:start...@startcom.org
Blog:   Join the Revolution! http://blog.startcom.org
Twitter:Follow Me http://twitter.com/eddy_nigg

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


Re: Revocation Policy

2014-04-24 Thread Eddy Nigg

On 04/24/2014 08:15 PM, Eddy Nigg wrote:
Without leaking any more data from Netcraft I can tell you that the 
revocation rate of StartSSL is in fact higher than any other CA except 
GlobalSign


Sorry, this statement should have said higher than the average and not 
every CA.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. http://www.startcom.org
XMPP:   start...@startcom.org xmpp:start...@startcom.org
Blog:   Join the Revolution! http://blog.startcom.org
Twitter:Follow Me http://twitter.com/eddy_nigg

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


Re: Revocation Policy

2014-04-23 Thread Eddy Nigg

On 04/10/2014 07:05 PM, Eddy Nigg wrote:

I agree - I've saw the tweets bug reports and this posting. I'll be glad
to join the discussion and we intend to take a public stance as soon as
things calm down a bit.

Currently all hell is lose, but I promise to get back to you all in due
time and will explain our position, policy and practices and also refute
some of the claims that were made.

In the meantime please be patient, thanks.




Alright - things have calmed down luckily by now. As my first input to 
the discussion please read carefully my explanation, thoughts and 
comments I've written down in my blog at https://blog.startcom.org/?p=230


--
Regards

Signer: Eddy Nigg, COO/CTO
StartCom Ltd. http://www.startcom.org
XMPP:   start...@startcom.org xmpp:start...@startcom.org
Blog:   Join the Revolution! http://blog.startcom.org
Twitter:Follow Me http://twitter.com/eddy_nigg


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


Re: Revocation Policy

2014-04-23 Thread Eddy Nigg

On 04/23/2014 10:32 PM, Radu Hociung wrote:

What will you do do avoid this? Check what's behind the (now meaningless) green 
lock? what if the site replaced its certificate with a new one, non-startcom ? 
You can still be MITM'd using the existing, valid cert, so you can't even be 
certain that you're safe.


I do have a few questions to you! How can you know that a site using a 
certificate from ANY CA isn't or wasn't affected by the Heartbleed bug? 
Do you know how many certificates from CAs other than StartCom have NOT 
been revoked? And can you tell me which of the currently installed 
certificates no matter who the issuer is were issued after a revocation 
of a previous certificate?


Once you can answer me these questions I have an interesting surprise 
for you



Consider also that the presence of Startcom in this market is a barrier to 
entry to other, honest and potentially inexpensive CAs.


No, it's not, otherwise StartCom would own 100% of the market share 
which it doesn't. The offerings of StartCom suite certain users and 
others not.



How can they compete with the perceived free certificates that Startcom 
floods the SSL space with?


They are free of charge no matter what - and under normal circumstances 
will not cost anything. Approximately 17% might be affected by this bug, 
another 87% are not. This means users are getting year after year a free 
service for 0.00 US$ from StartCom and keep getting it now and in the 
future, the rare exception which isn't even under our control are 
revocations. And if it wouldn't be necessary to raise a fee for that we 
wouldn't either.


--
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. http://www.startcom.org
XMPP:   start...@startcom.org xmpp:start...@startcom.org
Blog:   Join the Revolution! http://blog.startcom.org
Twitter:Follow Me http://twitter.com/eddy_nigg

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


Re: Seeking guidance on proceeding with KISA root inclusion request

2014-03-10 Thread Eddy Nigg

On 03/07/2014 07:10 AM, From spark0...@gmail.com:
According to Mozilla's definition of independent party, KISA is 
independent organization from Sub-CAs(not employees nor director)


The minute a CA signs a certificate of/for another CA, it's not 
independent at all. In fact a tight relationship exists between the two 
parties and a CA can't audit another CA. For this the BR sets forth a 
requirement for an independent audit by a (different) auditing firm than 
the CA signer/issuer, in order to avoid any conflict of interests.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

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


Re: Seeking guidance on proceeding with KISA root inclusion request

2014-03-04 Thread Eddy Nigg

On 03/04/2014 09:38 PM, From Kathleen Wilson:
My personal preference is to proceed with the process to 
approve/include the KISA root under the condition that Mozilla would 
constrain the CA hierarchy to *.kr. However, KISA does not want to 
constrain their CA hierarchy to *.kr. I have also suggested that KISA 
have each subCA apply for inclusion as separate trust anchors, but 
KISA does not want to take that approach either.


I think the BR and Mozilla's own policy has set the proper requirements 
defined for any CA operating under another CA (root). This should apply 
here too which excludes the CA performing a (self) audit for the sub 
ordinate CAs for example.


In respect to limiting issuance to a TLD, Mozilla might have to set a 
criteria for it first. Being a national (local) CA could be such a criteria.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

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


Re: DigiCert Request to Include Renewed Roots

2014-01-29 Thread Eddy Nigg

On 01/29/2014 08:50 PM, From Jeremy Rowley:

1) These root certificates are used in many different systems, not just
Mozilla.  If Mozilla doesn't embed all of them, the ones not embedded will
essentially be untrusted.  The roots proposed are simply replacements for
our existing root certificates, and our plan is to phase out the current
DigiCert root certificates once there is sufficient ubiquity in the new
roots.


Jeremy, not that I overly care, but are  you saying that all these roots 
plus the existing roots were accepted in the Microsoft roots program? I 
thought there is a hard limit of three roots these days and if correct 
and enforced by Microsoft your argument doesn't hold.


I'd say that you probably should have not more than three roots, maybe 
each with a particular algo and hash. From those you can and should 
issue intermediate CA certificates according to the various purposes you 
outlined in your mail.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

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


Re: Exceptions to 1024-bit cert revocation requirement

2013-12-11 Thread Eddy Nigg

On 12/12/2013 12:31 AM, From Kathleen Wilson:
I understand that this is not fair to the CAs who have done a great 
job of transitioning off of 1024-bit certs.


Right - potential customers knock at various doors in respect to such 
certificates and I believe to have given the right answers to them that 
it's not possible to obtain such certificates anymore when approached. 
Indeed if this isn't something applied equally it might be very 
difficult to enforce other requirements in the future if at the first 
opportunity there is yet another exception to the previous exception 
etc...if experience shows that it doesn't pay out to comply to 
requirements, than why care next time?


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

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


Re: New problematic practice

2013-12-02 Thread Eddy Nigg

On 12/02/2013 08:38 PM, From Brian Smith:
Why? Could you please explain what problem would be created if the 
renewed certificates had a different (later) notBefore time?



Traditionally we kept same or similar start date/time when extending an 
existing CA certificate with a new signature and new expiration date. 
Like this previously issued certificates can be still verified with the 
new one, in particular S/MIME but not only.


An end-user certificate that has been issued before the new/extended 
certificate has been, can't have a earlier before-date than the issuer 
(or at least shouldn't). But it can still correctly chain to the new one 
which is usually the whole idea of such PKI acrobatics. :-)


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

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


Re: Mozilla not compliant with RFC 5280

2013-11-11 Thread Eddy Nigg

On 11/08/2013 09:02 PM, From Jeremy Rowley:

What does this mean for CAs who, relying on Mozilla’s checking of OCSP and 
support of the baseline requirements, established an expensive and 
geographically diverse infrastructure?


Probably get a smaller bill at the end of the month ;-)


Mozilla’s main argument is that revocation checking without hard-fail provides 
little security.  Although I disagree with the premises, if the lack of 
hard-fail is really the issue, the obvious solution is to turn it on. Most of 
the CAs would be happy about that.


+1

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg


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


Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

2013-11-01 Thread Eddy Nigg

On 11/02/2013 01:00 AM, From fhw...@gmail.com:
Or to put it another way, everyone could stop issuing CRLs immediately 
and have n‎o appreciable impact on Internet security. I think that 
would surprise many people. 


Obviously it would have an impact on other browsers and systems. But 
true, it wouldn't affect Firefox and friends (this time in the negative 
way). It's however nothing new, it would be news to me that it checks 
any CRL at all.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg


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


Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

2013-10-24 Thread Eddy Nigg

On 10/24/2013 08:01 PM, From Kathleen Wilson:
For EV certs Firefox has always checked the CRL when the OCSP AIA URI 
was not provided. EV treatment would not be given if current 
revocation information was not obtained.




If Firefox really uses the CRLDP, then I suggest to keep that option 
still open  meaning if no stapled OCSP response, use the normal 
pointers and if that fails use CRL. Remove EV (and the secure UI 
indicators if you want from any other certificate) when certificate 
status can't be verified.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

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