RE: .tg Certificates Issued by Let's Encrypt

2017-11-16 Thread Robin Alden via dev-security-policy
Hi Kathleen,
Comodo issued a number of certificates to .tg domains during the
period of interest.

We see a history of applications for .gouv.tg certificates which
we had been previously been rejecting and suddenly in the period of interest
we issued them - which might support the notion of the .tg registry  being
compromised.
It could, of course, also indicate a sudden burst of activity by the Togo
government in setting up websites.  It is hard to tell.

We issued certificates including around 170 names matching
.gouv.tg.
Issued  names   certificates
19/06/2017  2   1
01/08/2017  1   1
25/10/2017  31  7
26/10/2017  46  15
27/10/2017  7   3
28/10/2017  8   4
30/10/2017  19  8
31/10/2017  20  4
01/11/2017  12  2
02/11/2017  9   3
03/11/2017  8   4
04/11/2017  5   2

and that's when we blocked .tg.

When we first got a heads-up about this we looked at the data and I said
that it looked to me like 25th October was the transition to chaos, since
that is when we issued the first of many gouv.tg certificates.

I hope that helps a little.

Regards
Robin Alden
Comodo CA Ltd

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+robin=comodo@lists.mozilla.org] On Behalf Of Kathleen Wilson
> via dev-security-policy
> Sent: 14 November 2017 16:31
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: .tg Certificates Issued by Let's Encrypt
> 
> On 11/14/17 4:34 AM, douglas.beat...@gmail.com wrote:
> >
> > Do we believe that this issue has been resolved by the Registry and
issuance
> an resume as normal, or are there ongoing concerns which CAs should be
> aware of when issuing certificates to .tg domains?
> >
> 
> 
> Based on information from folks that are monitoring their NS Records, we
> believe that the .tg Registry problems were fixed on November 1, and
> have remained fixed since then.
> 
> I have not looked into how Registries are operated and maintained, so
> here is my personal (uneducated) opinion: I think it is possible that
> the .tg Registry could be compromised again. I have no idea if all of
> the newer Registries are using good network and security protocols,
> infrastructure, etc.
> 
> I think that we will need to have much deeper investigation and
> discussions about Registries, so I have added this to my to-do list, but
> I will not be able to get to it until January.
> 
> Thanks,
> Kathleen
> 
> 
> 
> ___
> 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: Francisco Partners acquires Comodo certificate authority business

2017-11-01 Thread Robin Alden via dev-security-policy
Peter,
As you noted in your post to the cryptography list, Francisco
Partners' website states that they exited from their investment in Blue
Coat.
https://www.franciscopartners.com/investments/blue-coat?sector=Comms-Securit
y=1200

Regards
Robin Alden
Comodo

> -Original Message-
> From: Peter Gutmann
> via dev-security-policy
> Sent: 01 November 2017 04:08
> To: mozilla-dev-security-pol...@lists.mozilla.org; m...@flanga.io
> Subject: Re: Francisco Partners acquires Comodo certificate authority
business
> 
> mw--- via dev-security-policy <dev-security-policy@lists.mozilla.org>
writes:
> 
> >So they sell multiple roots over to a company that is "the leader in Deep
> >Packet Inspection (DPI) and we've got a lot going on in that space" and
> >enable them to issue trusted certificates and mitm all encrypted
connections
> >with that? That is a good halloween joke!
> 
> Francisco Partners is more a general investment company, but in that
regard
> they also have a stake in firms like Blue Coat, whose products have been
used
> by repressive regimes against their citizens.
> 
> Still, it's amusing that a perfect mechanism for performing MITM attacks
is
> now controlled by a company who has other arms that actively perform MITM
> attacks.
> 
> Peter.
> ___
> 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: Francisco Partners acquires Comodo certificate authority business

2017-11-01 Thread Robin Alden via dev-security-policy
> -Original Message-
> From: Gerv
> Subject: Re: Francisco Partners acquires Comodo certificate authority
business
> 
> On 31/10/17 13:21, Kyle Hamilton wrote:
> > http://www.eweek.com/security/francisco-partners-acquires-comodo-s-
> certificate-authority-business
> 
> Comodo notified Mozilla of this impending acquisition privately in
> advance, and requested confidentiality, which we granted. Now that the
> acquisition is public, it is reasonable for the community to have a
> discussion about the implications for Mozilla's trust of Comodo, if any.

http://www.businesswire.com/news/home/20171031005584/en/Francisco-Partners-A
nnounces-Acquisition-Comodo%E2%80%99s-Certificate-Authority

We can confirm that a majority stake in Comodo CA Ltd. has been acquired by
Francisco Partners.

The deal has closed, i.e. the transaction is complete.

We are conscious of the requirements of section 8 of the Mozilla Root Store
Policy.

As you have seen from the announcement, we have a new CEO and new Chairman
who have prior experience in managing a trusted CA organization.

There are to be no resultant changes to our CPS, our operations, our
business policies or procedures, or the secure locations from which we
operate our CA infrastructure.

The operational personnel in Comodo CA Limited will not change.  The
certificate validation teams will remain unchanged.

Regards
Robin Alden & Rob Stradling
Comodo CA Ltd.

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


Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

2017-06-19 Thread Robin Alden via dev-security-policy
Nick,
   We do exactly that for some device producers already.

Robin Alden, Comodo.  (Sent from my phone)

 Nick Lamb via dev-security-policy   wrote 

>On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com  wrote:
>>The compromised certificate for drmlocal.cisco.com serial number 
>> 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked.  A new certificate 
>> is being reissued to drmlocal.cisco.com and we will work with the developers 
>> of the YES video player to ensure that the issue does not happen again.  
>
>Troy, the name makes me suspicious, what - other than this trick which isn't a 
>permissible use - was the drmlocal.cisco.com name ever for in the first place? 
>If it doesn't have any legitimate use, there was no purpose in seeking a 
>re-issue of the certificate.
>
>The right way to approach this problem will be to issue unique keys and 
>certificates to individual instances of the system, this both satisfies the 
>BRs and (which is why) achieves the actual security goal of partitioning each 
>customer so that they can't MitM each other.
>
>It is a little surprising to me that (at least so far as I know) no 
>manufacturer has an arrangement with a CA to issue them large volumes of 
>per-device certificates in this way. I expect that Comodo (to name one which 
>definitely has business issuing very large volumes) would be able to 
>accommodate a deal to issue say, a million certificates per year with an 
>agreed suffix (say, .nowtv.cisco.com) for a fixed fee. The first time it's 
>attempted there would be some engineering work to be done in production and 
>software for the system, but nothing truly novel and that work is re-usable 
>for future products.
>___
>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: Compliance with 7.1.4.2.1 (internal names revocation)

2017-01-09 Thread Robin Alden
Hi Nick,

I expect that our auditors would have noticed and reported if we had not
tried to comply with 7.1.4.2.1.
Our next WebTrust audit starts shortly and I anticipate that the criteria
used will be
"WebTrust Principles and Criteria for Certification Authorities - SSL
Baseline with Network Security - Version 2.1"
http://www.webtrust.org/principles-and-criteria/item83666.pdf
Those criteria specifically call out 7.1.4.2.1 and the 1 October 2016 date.

Regards
Robin Alden
Comodo

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+robin=comodo@lists.mozilla.org] On Behalf Of Nick Lamb
> Sent: 09 January 2017 16:41
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Compliance with 7.1.4.2.1 (internal names revocation)
> 
> On Monday, 9 January 2017 14:05:25 UTC, Robin Alden  wrote:
> > Nick,
> > Thanks for the heads-up.
> > We agree that the certificates you found should have been revoked.
> 
> Thank you Robin for investigating this, for your explanation of what
> happened and for the sensible response of CT logging and revoking the
> affected certificates. Please pass on my thanks to any additional people
at
> Comodo who made that happen.
> 
> It would also be good to know (if you have relevant insight) whether you
> would expect your auditors to
> 
> a) Notice and report if Comodo had not even tried to comply with this
> element of 7.1.4.2.1
> OR
> b) Notice and report the type of mistake made here, in which a process was
> followed to attempt compliance but it missed a proportion of affected
> certificates.
> ___
> 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: Compliance with 7.1.4.2.1 (internal names revocation)

2017-01-09 Thread Robin Alden
Nick,
Thanks for the heads-up.
We agree that the certificates you found should have been revoked.

We revoked a body of certificates on 1st October 2016 in accordance with
7.1.4.2.1.
Regrettably a mistake was made when we created the list of certificates to
be revoked.

As a word of background we track replacement certificates within the
lifetime of a particular certificate order, in part to avoid unnecessary
certificate revocations and associated CRL bloat.
E.g. If a customer requests (and we issue) a certificate C1 for key k1 with
domains d1.dom, d2.com, and subsequently requests (and has issued) a
replacement certificate for C2 {k1, d1.com, d2.com, d3.com} we do not
automatically revoke the prior certificate - although we reserve the right
to do so. 
Our error in creating the list of certificates to be revoked was in not
including in that list certificates for which a replacement certificate had
been requested.

We had two people independently, using different methods, produce the list
of certificates to be revoked today to increase confidence in the result. 

This has led us to revoke 28 further certificates, including the 2 that you
brought to our attention.

Here are links to the certificates we have revoked today.  All but 3 are
newly published today to CT.

https://crt.sh/?id=1246507
https://crt.sh/?id=1825806
https://crt.sh/?id=39425459
https://crt.sh/?id=74893260
https://crt.sh/?id=74893262
https://crt.sh/?id=74893264
https://crt.sh/?id=74893267
https://crt.sh/?id=74893270
https://crt.sh/?id=74893273
https://crt.sh/?id=74893275
https://crt.sh/?id=74893278
https://crt.sh/?id=74893281
https://crt.sh/?id=74893284
https://crt.sh/?id=74893286
https://crt.sh/?id=74893289
https://crt.sh/?id=74893292
https://crt.sh/?id=74893295
https://crt.sh/?id=74893297
https://crt.sh/?id=74893299
https://crt.sh/?id=74893301
https://crt.sh/?id=74893303
https://crt.sh/?id=74893305
https://crt.sh/?id=74893307
https://crt.sh/?id=74893308
https://crt.sh/?id=74893310
https://crt.sh/?id=74893312
https://crt.sh/?id=74893314
https://crt.sh/?id=74893317

Thank you for your diligence.

Regards
Robin Alden
Comodo


> -Original Message-
> From: dev-security-policy On Behalf Of Nick Lamb
> Sent: 06 January 2017 09:52
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Compliance with 7.1.4.2.1 (internal names revocation)
> 
> Work continues. After the initial good news, to my surprise the second
> million or so certificates processed threw up some deviations from major
> public CAs
> 
> Comodo
> https://crt.sh/?id=1246507
> https://crt.sh/?id=1825806
> 
> Verisign / Symantec
> https://crt.sh/?id=1450883
> 
> I would appreciate feedback, generally from m.d.s.policy participants
about
> whether they believe that for some reason these certificates did not need
to
> be revoked to achieve compliance with 7.1.4.2.1 and specifically from
> Comodo and Symantec on why the certificates weren't in fact revoked.
> 
> I would also be interested in learning whether auditors would be expected
to
> identify and report this deviation.
> ___
> 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: Comodo issued a certificate for an extension

2016-11-10 Thread Robin Alden
Nick Lamb, on 02 October 2016 17:50, said..
> The first thing that jumps out at me from their report is that they
mistake .sb
> for a gTLD when it is actually a ccTLD.

That was a mistake in writing the report.
The point is that it is a TLD.

> The second thing obviously is that they do have exactly the "rule" Richard
> Wang described, and they believe this was justified under the BRs old
3.2.2.4
> method 7 (which isn't a method at all, it's basically a catch-all).
> 
> I examined the Comodo CPS and wasn't able to find any mention of this
rule.
> Indeed based on the CPS I would have assumed that control over a website
> www.example.com would under no circumstances be sufficient to get a
> certificate for the name example.com from Comodo and I would be grateful
> if anyone can point me to where they have written that it is.
> 

I can't speak to your assumptions, but I concede that it is not explicit in
the CPS.

It is now documented at
https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf
and in the knowledgebase article at:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/16/alte
rnative-methods-of-domain-control-validation-dcv

Regards
Robin Alden
Comodo

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


RE: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-11-10 Thread Robin Alden
Hi Hanno,

Hanno Böck, on 04 October 2016 13:34, said..
> There seem to be more certificates of that kind that weren't mentioned
> in the incident report. Here's a .re / www.re certificate (expired
> 2015):
> https://crt.sh/?id=4467456
> 
> Has comodo checked its systems for other certificates of that kind? Can
> you provide a full list of all such certificates?
> 

Yes, we have.

The initial check was for certificates issued on or after Nov 1st 2015, that 
being the date when internal server names were finally outlawed.  
In certificates issued before that date dNSName=sb could arguably be considered 
an internal server name (given that https://sb/ isn't supposed to
resolve on the public Internet).  At any rate, in the interests of getting the 
incident report out, it was simpler to only go back as far as Nov 1st 2015 so 
that we didn't have to consider internal server names at all.

We took another pass through the data looking for all server authentication 
certificates where we included DOMAIN, and for which DOMAIN is also included in 
the PSL or is a TLD, but where we validated (something).DOMAIN instead of 
DOMAIN.  This should produce a superset of all certificates that exhibit this 
problem.
In each case, the (something) was 'www'.

Going back to 2011, which was when we started checking the PSL in addition to a 
(then) fixed list of TLDs, we find the following certificates:
Issued  PSL section State
25/07/2011  k12.wa.us   ICANN   expired
25/07/2011  k12.wa.us   ICANN   expired
12/11/2011  re  ICANN   expired
10/12/2012  gov.uk  ICANN   expired
02/05/2013  fredrikstad.no  ICANN   expired
10/06/2013  k12.wa.us   ICANN   expired
02/08/2013  ks.ua   ICANN   expired
30/06/2014  re  ICANN   expired
28/08/2014  iki.fi  PRIVATE Valid (still live on https://iki.fi)
17/06/2015  gov.lk  ICANN   expired
20/09/2015  net.kg  ICANN   expired

Plus these ones which were already discussed:
26/11/2015  rivne.uaICANN
03/08/2016  tc  ICANN
03/08/2016  tc  ICANN
03/08/2016  tc  ICANN
21/09/2016  sb  ICANN

Plus three more certificates which turned out to be on the private section of 
the PSL now, but were not in the PSL when we issued the certificates.

> 
> Also my understanding is that the error here was that control over the
> www.[domain] subdomain would indicate control over [domain]. Does that
> mean that this bug could've been used to also get wildcard certificates
> in the form of *.[tld]?

No.  Regardless of other controls, the nature of this bug was that it only 
affected cases where a customer requested www.DOMAIN, because that was the case 
in which we also added DOMAIN into the SAN.

No certificates were issued for *.[tld]

Regards
Robin Alden
Comodo

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


RE: Comodo issued a certificate for an extension

2016-11-10 Thread Robin Alden
Eric Mill, on 03 October 2016 03:14, said..
> On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb <tialara...@gmail.com> wrote:
> > On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen  wrote:
> > > There is some good news.  The CA/Browser Forum has already addressed
> > > this, even prior to the current discussions. Ballot 169
> > > (https://cabforum.org/2016/08/05/ballot-169-revised-
> > validation-requirements/)
> > > revises 3.2.2.4 considerably.
> >
> > I'm aware of Ballot 169
> >
> > > Under the new rules, which should be in
> > > effect as of 1 March 2017, validating www. will not be a valid
> > > method of showing control of .  The name is true for any valid
> > > hostname under .  The only note is that names in the form
> > > _. (that is starting with an underscore) can be
> > > used to validate .
> >
> > I wish I shared your confidence. My expectation is that if we leave this
> > as it is, in April 2017 subscribers will still be able to get a
certificate
> > issued using this lackadaisical validation, and the issuing CA will say
> > they feel it's not "really" disobeying the rules, that it's just a
> > "technicality" and anyway what's the harm, it's so much more convenient
> for
> > their customers this way?
> >
> > Comodo's document never actually says that they're abolishing this
"rule"
> > as a result of Ballot 169. It lets you choose to draw that implication,
by
> > specifying that their current practices pre-date Ballot 169's changes,
but
> > it never says as much. Hence I think Mozilla's rep should take this to
> > CA/B, or it should go in one of the bulk CA communications, to find out
at
> > least how widespread the crazy is and whether it's even consistent in
how
> > it works from one CA to the next.
> >
> 
> It would be nice for Comodo to make it explicit that this practice will
> cease when Ballot 169 takes effect, and the lack of an explicit update
> jumped out at me immediately when I read it. But the BRs post-169 seem
> crystal clear on this, and I don't think CAs would be able to write off
> this practice as a technicality or misinterpretation.
> 
> -- Eric

I'm happy to state definitively that this practice will cease when Ballot
169 takes effect.

To avoid suggestions of weasel-words around the CA/B forum's struggle with
their IP policy my understanding is that at least Microsoft, and I hope
other browsers too, will incorporate the Ballot 169 wording into their
policy regardless of whether the CA/B has ratified it by then.

Comodo will have implemented some or all of the new validation methods
described in Ballot 169 before 1 March 2017.
Comodo will be withdrawing any and all validation methods which do not
conform with Ballot 169, and/or which rely on the pre-Ballot 169 3.2.2.4.7
'any-other-equivalent method' rule before 1 March 2017.

Regards
Robin Alden
Comodo

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


RE: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-11-10 Thread Robin Alden
Gervase Markham, on 04 October 2016 07:10, said..
> Thank you for this report.
> 
> On 27/09/16 02:07, Robin Alden wrote:
> > When we use an 'agreed-upon change to website' method to prove
> domain
> > control, we consider proof of control of 'www.' as also
> > proving control of '' (except where '' is a
> > public suffix).
> > We don't give any other sub-domain this treatment, only 'www'.
> > We believe that the currently enforced and audited (pre-ballot 169) BRs
> > permit us to do this under section 3.2.2.4 method 7.
> 
> 3.2.2.4 section 7 says:
> 
> "Using any other method of confirmation, provided that the CA maintains
> documented evidence that the method of confirmation establishes that the
> Applicant is the Domain Name Registrant or has control over the FQDN to
> at least the same level of assurance as those methods previously
described."
> 
> Where does Comodo's documentation of this methodological equivalence
> reside? Is it in your CP/CPS or elsewhere? Could you share it with us
> please?

It previously existed only in unpublished documentation, so far as I am
aware.
Our auditors were aware of it.
Our validation and support staff have freely offered this information to
assist customers in getting certificates validated and issued.

It is now publicly documented at
https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf
and in the knowledgebase article at:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/16/alte
rnative-methods-of-domain-control-validation-dcv

Regards
Robin Alden
Comodo

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


RE: Incident Report - OCR

2016-10-21 Thread Robin Alden
> -Original Message-
> From: Ryan Sleevi
> Sent: 21 October 2016 16:06
> 
> As pointed out in https://bugzilla.mozilla.org/show_bug.cgi?id=1311713 ,
it
> does seem like there's a rather large gap here between notification and
report
> - from 23 Sept to Oct 19.
> 
> While it's entirely reasonable that Comodo wanted to ensure that, before
> disclosing any incident, that systems were properly protected - and,
indeed,
> it's fairly typical in other disclosure circles to ensure vendors have
time to
> remediate - could you explain a bit more about how that time was spent?
> ___

Hi Ryan,
The security researchers contacted us on 23rd September and
intimated that they had a disclosure to make.

There were some negotiations over the terms on which the information would
be shared and released and we obtained the report from them on the 28th
September.  

We stopped using the OCR system on 28th September. 

On 4th October we received a draft article from the security researchers
which there were planning to send to heise.de.
On 15th October we had the first complete draft of our own report and it was
approved and published on 19th October.

I apologize for the tardy production and release of our report.

Referring to the release of our report rather than our internal response to
the report we received, there were too many fingers in this particular pie
and that made for a slow release of information.

Regards
Robin Alden
Comodo



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


Incident Report - OCR

2016-10-19 Thread Robin Alden
SUMMARY:

Comodo was informed by security researchers Florian Heinz and Martin Kluge
that on 23rd September 2016 they had been able to obtain a server
authentication certificate [1] from Comodo for a domain which they did not
own or control.

The researchers shared their discovery with Comodo and this assisted Comodo
to ensure that no further such certificates were issued.

 

DOMAIN CONTROL VALIDATION

One of the methods that Comodo uses to validate that a certificate applicant
owns or controls a domain to be included in the subjectAlternativeName of a
server authentication certificate is set out in the CA/B Forum's Baseline
Requirements document [2] at section 3.2.2.4.2.  

That method may be summarized as the sending of an email to an email address
(and obtaining a confirming response) where the email is identified as
belonging to the Domain Name Registrant, technical contact, or
administrative contract as listed in the WHOIS record of the domain.

 

For the TLDs .eu and .be the registries offer only a redacted port 43 WHOIS
service which does not include the contact email addresses.  

They also offer a web-based WHOIS service which presents the contact email
addresses, but which does so in the form of a graphical image in a page
instead of text.  

For these TLDs (.eu and .be) we were using an OCR system to read the contact
email addresses.

 

The researchers disclosed to Comodo that, while obtaining a certificate from
Comodo for a domain that they did control, Comodo's certificate application
process presented them with an email address which was not the same as they
had registered in WHOIS but which was substantially similar.  They inferred
from the nature of the difference between the email addresses that the
difference was due to an error in reading the email address, most likely by
OCR (Optical Character Recognition).

They verified that the error in transcribing the email address led to a
vulnerability in the certificate application process by identifying a domain
name which was also subject to the OCR transcription error and, by
registering a domain with the name produced by the transcription error, were
able to obtain a certificate from Comodo for the domain name which was
subject to the transcription error despite them not controlling it.

 

The domain that they used for their proof of concept was 

a1-telekom.eu

The registrant email address in the WHOIS entry was

domain.bill...@a1telekom.at <mailto:domain.bill...@a1telekom.at> 

which was misread by OCR as

  domain.bill...@altelekom.at
<mailto:domain.bill...@altelekom.at>  (the "1" in a1telekom.at was detected
as a lower case 'L')

 

IMMEDIATE RESPONSE

Comodo's immediate response to the disclosure was to revoke the identified
certificate and to disable the use of OCR in the interpretation of WHOIS
responses for the validation new certificate requests.

 

INVESTIGATION OF SCOPE

Comodo used an OCR system to interpret WHOIS information from 2 TLDs.  The
TLDs were .be and .eu .

Comodo used OCR for the WHOIS on these two domains between 27-JUL-2016 and
28-SEP-2016.

Comodo is performing a thorough review of all server certificates issued by
Comodo between those dates for domains on the .be and .eu TLDs which used
the domain control validation method described in 3.2.2.4.2 of the BRs.

The review is ongoing but no other examples have been found of certificates
issued as a consequence of OCR mis-reads.

 

WHOIS

Comodo notes that the port 43 WHOIS service provided by most registries is a
valuable source of information for CAs and for other parties who have a
legitimate need to contact domain name registrants.

Some domain registrars provide registrants with a means to effectively
opt-out of having their contact details made public through the port 43
WHOIS server, or otherwise, by providing a 'privacy' or 'anonymization'
service whose details appear in the WHOIS results for the domain instead of
those of the registrant.

Comodo understands that some registrants will not want to be identified and
supports their right to a choice as to whether they should be identified in
WHOIS.

Comodo understands that some registries do not offer a port 43 WHOIS service
because they are not able to do so.  There are some registries for small or
poor regions where we cannot expect technical excellence.

Comodo finds it regrettable that some registries choose to offer a port 43
WHOIS service which redacts information for all registrants which even the
registry themselves would normally consider to be public.  We find it even
more regrettable that a sub-set of those registries refuse to consider
offering unredacted access to that information even when contractual and/or
commercial terms (including binding restrictions on the use of that
information) are offered.  

 

Robin Alden

Comodo CA Ltd.

 

[1] https://crt.sh/?id=47045653

[2] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

[3]
http://w

Incident Report - certificate with 'sb' as a SAN:dnsName

2016-09-26 Thread Robin Alden
SUMMARY:
Comodo was alerted at September 24 2016 07:11 BST to a report [1] of the
issuance by Comodo of a Server Authentication certificate [2] that
includes 'sb' as a SAN:dNSName.  sb is a gTLD.

OUR CURRENT (PRE-BALLOT 169) POLICY REGARDING 'www':
To establish context, first we will explain our policy with regard to
the 'www' sub-domain, for which the common link to the base domain is
well known [3].
When we use an 'agreed-upon change to website' method to prove domain
control, we consider proof of control of 'www.' as also
proving control of '' (except where '' is a
public suffix).
We don't give any other sub-domain this treatment, only 'www'.
We believe that the currently enforced and audited (pre-ballot 169) BRs
permit us to do this under section 3.2.2.4 method 7.

ADDITIONAL FQDN FOR DOMAIN NAME MISMATCH REDUCTION:
When an applicant requests a certificate for the FQDN '',
we also add the FQDN 'www.' into the certificate, and
vice-versa.  This has been a fairly common practice amongst CAs for
several years.

ROOT CAUSE:
The applicant requested a certificate for 'www.sb'.  Although our code
correctly identified that the base domain ('sb') was a public suffix,
there was an error of logic that failed to prevent the certificate from
being issued in this case.

REMEDIATION:
We investigated the matter promptly, identified the root cause, and
within a few hours we had deployed a bugfix to correct the error of
logic, so that issuance of a certificate where the Additional FQDN is a
public suffix is now blocked as intended.

TRANSPARENCY:
The bugfix we deployed on September 24 had actually been prepared
several weeks earlier, after we'd been alerted (by [4]) to a similar
occurrence: we had issued 3 certificates [5] for 'www.tc' (a valid
registered domain) that also included 'tc' (a public suffix) as a dNSName.
Since 'www.tc' and 'tc' both belong to the same entity, we took the view
that the cert had not been misissued and that an incident report was not
warranted.  We also took the view that this flaw did not require an
urgent hotfix.  Unfortunately, scheduled deployment of the bugfix did
not occur before the 'sb' certificate [2] was issued.
Today we performed an exhaustive search of all the server authentication
certificates we've issued since November 1 2015, and as a result we
found just one further certificate [6] in which we'd included a public
suffix (rivne.ua) due to this bug.

[1]
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04233.
html

[2] https://crt.sh/?id=34242572

[3] https://en.wikipedia.org/wiki/World_Wide_Web#WWW_prefix

[4] https://crt.sh/?cablint=1+week

[5] https://crt.sh/?dNSName=tc

[6] https://crt.sh/?id=11091687

-- 
Rob Stradling
Robin Alden
Comodo CA Ltd.


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: Comodo issued a certificate for an extension

2016-09-25 Thread Robin Alden
Hi All,
We did receive a direct report of the problem yesterday (24th 
September) from a Mozilla rep., thanks, and we undertook an investigation and 
remediation exercise yesterday.

The software problem which caused or allowed this certificate to be issued has 
been corrected.

That certificate (https://crt.sh/?id=34242572) was revoked yesterday morning.

We will issue a report tomorrow (26th September).

Regards
Robin Alden
Comodo



> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+robin=comodo@lists.mozilla.org] On Behalf Of Peter Bowen
> Sent: 25 September 2016 17:37
> To: Nick Lamb <tialara...@gmail.com>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Comodo issued a certificate for an extension
> 
> On Sun, Sep 25, 2016 at 9:19 AM, Nick Lamb <tialara...@gmail.com> wrote:
> > On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com
> wrote:
> >> am I the only one who a) thinks this is slightly problematic and b) is
> surprised that the cert still isn't revoked?
> >
> > I don't know enough about the .sb ccTLD to be clear how problematic the
> described scenario is. I would certainly like to know more. Wikipedia tells me
> that .sb is operated like .uk used to be, with registrant domains appearing
> only as 3LDs e.g. you used to able to buy example.co.uk but not example.uk,
> so that having control of example.sb is itself exceptional, let alone www.sb
> 
> According to https://nic.net.sb/, which is linked from
> http://www.iana.org/domains/root/db/sb.html:
> 
> "Starting from February 12, 2016 Solomon Telekom Company Limited is
> pleased to announce the extending of .sb domain space place by
> allowing registrations directly at the ‘second-level’."
> 
> So it appears that the scenario is that someone (presumably the
> reporter of this issue) registered www.sb., a second level domain
> name, which would be in accordance with the described change.
> 
> > It is important to me - as a relying party - to know if there is a problem 
> > in
> Comodo's domain validation which allows people to obtain certificates for
> names which they do not (or perhaps, depending how .sb is run, even
> cannot) control. It is not terribly important to me in principle which names 
> are
> affected, but in practice the extent of the risk might influence Mozilla's
> decision as to what if anything should be done, by them or by Comodo.
> >
> > However right now it's the weekend, people who do this stuff as their day
> job, rather than an outside interest, may not have responded because
> they're busy watching televised sports or baking cakes. I will grow more
> concerned if there's no follow-up from anybody next week.
> 
> It is unclear if this has been reported to the CA (Comodo).  While
> some CA operators do read this Mozilla forum, it is not an official
> communication channel for any CA, as far as I know.  Any request to
> revoke a certificate needs to be sent to the address specified by the
> CA in their CPS.
> 
> Thanks,
> Peter
> ___
> 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: Server certificate domain validation bug

2016-08-11 Thread Robin Alden
Hi Nick,
Sorry for the slow reply.  

> -Original Message-
> From: Nick Lamb
> Sent: 30 July 2016 00:04
> To: mozilla-dev-security-pol...@lists.mozilla.org
> 
> Hi Robin,
> 
> On Friday, 29 July 2016 18:54:56 UTC+1, Robin Alden  wrote:
> > We received a report of bugs in the construction of the emails we send
out
> > in order to confirm authorization by the domain name registrant prior to
> > issuing a server certificate.
> >
> > Colloquially these are known as Domain-Control Validation Emails.
> 
> Indeed. A few questions arise. First about this specific occurrence, all
> questions are about the state prior to the incident. It's interesting to
hear
> about things which have changed, but my focus at first is on how things
were
> _before_ you knew about this specific problem.
> 
> 1. Did Comodo grasp that these emails were a critical element of their CA
> systems? e.g. do you have a document that calls them out as being
important
> in this way and distinguishes them from marketing communications and
> other "fluff" that, though it may be important to your business, is not
vital to
> the web PKI ?
> 

Hmm, that's one of those 'When did you stop beating your wife?' type
questions. 

Yes, Comodo grasps that these emails are a critical element of the CA
system.
We treat the sending of these emails differently from marketing
communications, although that is not hard since marketing communications
come from different systems.
We treat the sending of these emails differently from the sending of other
emails concerning the certificate lifecycle, precisely because we are aware
that they are a critical piece of the validation and issuance process.  

> 2. Was it impressed upon the software engineers responsible for Comodo's
> software which sends these emails how critical this content was ? Were
they
> given suitable training e.g. based on OWASP in how to make the software
> secure against well-known risks like this ?
> 

Yes, the development team that maintains the CA software use a development
process that includes review of all code by staff with experience and
training in secure coding techniques.

> 3. Had Comodo engaged a third party to conduct penetration testing of
their
> web site  https://secure.comodo.com/ ? How often was this testing
> done ?

Yes.  We are required to have this done at least annually.

> If so, did that engagement include
> these emails as part of the system to be tested ?

These emails were generated, sent, received by, and interacted with by the
pen testers as part of the pen test.

Could we have drawn more attention to these emails for the pen testers as a
special area of interest, and will we do so in the future? - yes.

> 
> 4. How long had this bug been present in your production systems, and to
> what certainty do you know this answer ?
> 

Since Jan 23rd, 2015.  The date is tracked as part of the change control
system.

> > https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-
> ssl-
> > certificates-from-comodo-via-dangling-markup-injection/index.html
> 
> Thanks for the link.
> 
> > We are pleased to report that no certificates were issued contrary to
the
> > terms of our CPS.
> 
> Two more, this time from the point of view of Comodo after the problem
> was reported:
> 
> 5. What methods were actually used to determine whether any certificates
> had been issued contrary to the terms? Were those methods independent
> of the specific technique used in this incident, or did they assume that
this
> method was the only possible means by which certificates might be mis-
> issued by Comodo at this time ?
> 

Our investigation covered the effects of markup injection into the DCV
emails.
We retain all details associated with a certificate request in a database.  
This data is not changed or deleted once a certificate is generated from the
request.

> 6. Given the timeline established in question 4, were you able to perform
> such checks for the whole period affected, or only some of it ?
> 

For the whole period.

> > We will be further engaging with external security consultants to ensure
> > that our systems remain secure so that we may continue to meet our
policy
> > obligations.
> 
> Now a final question from the point of view of the incident having
happened,
> but independent of Comodo itself:
> 
> 7. In your view what new requirements should be imposed on CAs by CA/B
> or by the individual trust stores in order to reduce the risk of this sort
of
> incident in future, whether at Comodo or another CA ?

I'm going to decline to suggest what anyone should impose.

I would say that having more eyes on the code is always a good thing.
Specifying a white-box pen test woul

RE: Server certificate domain validation bug

2016-08-11 Thread Robin Alden
Hi Hanno,
Simplicity is certainly a powerful aid to security.
I like the text-only idea for the DCV emails.

Not containing any user controlled content is a harder sell, I think, because 
we really want to give the domain owner all the information we can about the 
certificate request that has been submitted.

We anticipate that in the Enterprise case it is of significant value to the 
applicant if the DCV email contains some information to assist the recipient 
of the DCV email to relate the certificate request to his organization's 
operation.  A message such as this could save them a lot of time:
"Required for https://svn.bambleweeny.net/trac/Project57/ticket/123, please 
phone Bob Kahn on extension #2719 if questions arise."

Although I can see that this message looks pretty similar
"Required for https://phishingsport.darknet/we_have_cookies, please phone Pete 
McNasty on +963-444-4 if questions arise."
and expecting the recipient to tell the difference between the two approaches 
pre-supposes a non-knuckle-dragging domain administrator.

If we pass no user controlled content at all, the problem is that in the 
Enterprise case the domain administrator doesn't know who (within his 
organization) originated the certificate request.
The domain administrator needs some out-of-band communication with the 
applicant to be certain that the certificate request originated within his 
organization.
I suppose the problem there is really one of the Enterprise's policy in regard 
to the approval of issuance of certificates for its domains being up to 
scratch.

Regards
Robin Alden
Comodo


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


Server certificate domain validation bug

2016-07-29 Thread Robin Alden
We received a report of bugs in the construction of the emails we send out
in order to confirm authorization by the domain name registrant prior to
issuing a server certificate.

Colloquially these are known as Domain-Control Validation Emails.

 

The security researcher, Matthew Bryant, followed a responsible disclosure
process and we were afforded the opportunity to resolve this bug before he
published his blog post at 

https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-
certificates-from-comodo-via-dangling-markup-injection/index.html

 

We are pleased to report that no certificates were issued contrary to the
terms of our CPS.

 

We have informed our external WebTrust auditors of the report and of its
resolution.

 

We will be further engaging with external security consultants to ensure
that our systems remain secure so that we may continue to meet our policy
obligations.

 

Regards

Robin Alden

Comodo

 

This email has also been posted to pub...@cabforum.org
<mailto:pub...@cabforum.org> 

 

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


RE: Name issues in public certificates

2015-11-19 Thread Robin Alden
Peter said..
> While I realize that it is not clear cut in many contexts, RFC 5280 is
> rather clear cut.  The authors clearly wanted to avoid stumbling and
> being eaten by a grue, so they wrote:
> 
>When the subjectAltName extension contains a domain name system
>label, the domain name MUST be stored in the 
>dNSName (an IA5String).
>The name MUST be in the "preferred name syntax", as specified by
>Section 3.5 of [RFC1034] and as modified by Section 2.1 of
>[RFC1123].  
> 
> This makes it clear that the "preferred name syntax" is not a
> recommendation when it comes to certificates.  It is mandatory.

Ah, but the lead-in there is 
"When the subjectAltName extension 
contains a domain name system label,"

weird_place.example.com is not a domain name system label.  It is not
expected to (and likely does not, and maybe could not) resolve to an IP
address on the public internet.

In practice, the people to whom weird_place.example.com is a useful name
will be running Microsoft kit which is very happy with an underscore in
a name.  All that matters to them is that weird_place.example.com
resolves within their environment.
The CAB Forum BRs can be met in the validation of such a certificate
providing that ownership or control of example.com is shown in the
approved methods.  The BRs place no requirement on the full name
weird_place.example.com appearing on the internet or being accessible by
the CA.

Regards
Robin



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: Policy about root cert transfers

2015-06-23 Thread Robin Alden

Brian Howson said..
  . I'm not sure if this should be additions to the
 original inclusion request or a new request, that might depend on whether
it is
 wholesale (like today's Digicert acquisition of Verizon) or piecemeal
(like the
 one root Amazon acquired from Comodo).  

Amazon have not acquired a root from Comodo.

Regards
Robin Alden
Comodo

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


RE: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Robin Alden
Peter Gutmann said..
 I was using IT news stories as the source, e.g. IDG's 'Secure'
advertising
 tool PrivDog compromises HTTPS security:
 
   Instead, the problem was tracked down to another advertising-related
   application called PrivDog, which was built with the involvement of
 Comodo's
   CEO, Melih Abdulhayoglu. New PrivDog releases are announced on the
 Comodo
   community forum by people tagged as Comodo staff.
 
 That does sound like there's Comodo involvement.
 

It does sound that way, and we have shipped some versions of 
PrivDog with some of our products.
You may even find an IT news story that says it in your exact 
words, but that doesn't make 
'Comodo provided the PrivDog MITM software' 
a correct statement.

Regards
Robin


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


RE: Consequences of mis-issuance under CNNIC

2015-03-31 Thread Robin Alden
Peter Gutmann said..
 Daniel Micay danielmi...@gmail.com writes:
 
 CNNIC is known to have produced and distributed malware 
  for the purpose of mass surveillance and censorship.
 
 TeliaSonera aided totalitarian governments, Comodo provided 
 the PrivDog MITM software, and that's just the first two off 
 the top of my head.
 
  If you have solid evidence that other CAs do this, feel 
  free to present and I'll be a loud supporter of ripping 
  out their certificates too.
 
 We'll start with Comodo then, shall we? 

Hi Peter,
Your assertion about Comodo is wrong and that blunts your point
instead of helping you make it.

I refer you to my previous statement on Privdog.
https://cabforum.org/pipermail/public/2015-February/005095.html
and Hanno's post to this list
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg01
544.html

Robin

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


RE: address prefixes allowed for domain control validation

2015-03-23 Thread Robin Alden
 I wonder if the current publicity will lead all webmail providers to
do a
 review, and then we won't see any further problems...
That would be nice!

Pertaining to Peter Bowen's suggestion that some CAs who use email
authentication could provide statistics on what percent of customers
choose each option., Comodo finds that those 5 options are very popular
with applicants for SSL certificates.
Of all email-based domain control validation we perform those email
addresses (on the same domain being applied for) are used as follows:

admin@  33.9%
hostmaster@ 7.8%
webmaster@  7.6%
administrator@  7.5%
postmaster@ 4.5%

Regards
Robin Alden
Comodo


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: address prefixes allowed for domain control validation

2015-03-23 Thread Robin Alden
 Robin said..
  Of all email-based domain control validation we perform those email
  addresses (on the same domain being applied for) are used as
follows:
 
  admin@  33.9%
  hostmaster@ 7.8%
  webmaster@  7.6%
  administrator@  7.5%
  postmaster@ 4.5%
 
Gerv said..
 I'm sure there's an obvious reason, but why doesn't this add up to
100%?
 Is it because the other validations use an email address sourced from
 WHOIS?
Yes, exactly so.

Of all email-based DCV we do, 69.4% use an email address on the same
domain as the certificate is being purchased for (allowing for pruning,
too).
Of those 69.4%, most use one of those 5 email addresses mentioned in the
BRs as detailed above which add up to 61.3% of the total.
The difference, being (69.4% - 61.3% =) 8.1% of the total use an email
address on the same domain as the certificate but not one of the above
5.  This is only permitted when that email address is sourced from
WHOIS.
#6 on the list is info@ with ~0.5%

The rest, being (100% - 69.4% =) 30.6% use email addresses on a
different domain, and these are only permitted when that email address
is sourced from WHOIS.

 
 Do the above percentages include some where the email is sourced from
 WHOIS but happens to match the permitted five?
I think they must include some, yes.
I'll see if we have some data to give a ballpark figure as to how often
that is the case.

Robin


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: KIR S.A. Root Inclusion Request

2014-09-25 Thread Robin Alden
Hi Przemyslaw,

1) Suspension
I can see that it's no problem for a certificate's status as shown in
OCSP or in a CRL (as viewed from outside your organization) to
transition from valid to 'Revoked' as a result of a 'suspension' within
your system.
The problem comes when you try to 'unsuspend'.  You can't transition
back from 'revoked' to valid.

http://www.ietf.org/rfc/rfc5280.txt
3.3.  Revocation
...
An entry MUST NOT be removed
   from the CRL until it appears on one regularly scheduled CRL issued
   beyond the revoked certificate's validity period.

Regards
Robin Alden


 -Original Message-
 From: dev-security-policy [mailto:dev-security-policy-
 bounces+robin=comodo@lists.mozilla.org] On Behalf Of Certificates
 Sent: 25 September 2014 14:03
 To: dev-security-policy@lists.mozilla.org
 Subject: Re: KIR S.A. Root Inclusion Request
 
 Answers for Jeremy Rowley questions:
 
 A couple of notes:
 1) Under Section 3.4 and 4.9, suspension is not permitted for SSL
certs
 under the BRs.
 
 Where the BR forbids certificates suspension? The Repository gives an
 answer revoke for suspended certificate, so it's consistent withe BR
 s13.2.7.
 
 2) Section 3.3 should specify when re-verification is required (at
least
 every 39 months).  Although the CPS does say the original issuance
 process is followed, I didn't this specified at the certificate
lifecycle is 5
 years.  Also, be aware that five year certs are only permitted until
April 1,
 2015. After that, the maximum lifecycle is 39 months
 
 Yes, we know about this requirement. Presently, we do not issue
 certificates above 2 years validity period, although we mentioned such
 possibility in CPS. We do verification both for first certificate and
renewal,
 in particular we verify rights to domain for SSL certificates.
 Our internal procedures describe this process in details.
 
 3) See section 13.1.5 of the BRs for the reasons a CA must revoke a
 certificate.  Section 4.9 of your CPS doesn't really match these.
 
 The reasons for revoking subscriber certificate pointed in CSP
 corresponds to the reasons pointed in BR. But if the connection isn't
clear
 we can clarified it more in CSP by introducing some changes.
 
 
 4) Archiving is required for 7 years under the BRs (5.4.3 and 5.5).
 
 That's a mistake in CPS. We will change it.
 
 5) 6.28 should require at least two individuals acting together to
activate
 the private key
 
 It is done by two persons. It is mentioned in CPS s.6.2.2 that the
secrets
 are distributed among 5 persons.
 CSP s6.2.6. Uploading a private key to cryptographic modules is done
in
 the following situations:
 1)  launch of the certification authority during the system
start-up;
 2)  recovery of the key of the certification authority in the
back-up
 location;
 3)  replacement of the cryptographic module.
 The key is uploaded to the module with the presence of the holders of
 co-shared secrets. To upload the key it is necessary to have the
presence
 of the number of secrets described in Clause 6.2.2. Uploading is done
 within a closed security environment. A private key is made up of
 elements. Parts of the secret key from the cards are provided in
 sequence, enciphered files are uploaded into the module's memory and
 then deciphered. A private key is ready to use. Uploading of the key
into
 the module is recorded in the register of events.
 CSP s.6.2.8 Once uploaded into the module, the key shall be active.
 
 6) Some of your EKU extensions are not permitted in the same
 certificate.
 
 We are aware of it. In the SSL certificates we use only
 clientAuthentication and serverAuthentication.
 
 7) Note the recently announced SHA-2 requirement. SHA-1 is the only
 hash specified in the CPS. 5 year certificates will not be possible.
 
 We are aware of it and we will start issuing certificates with SHA 256
 before this date and also  supplement our CSP accordingly.
 
 8) What is your OCSP response for a not issued cert?
 
 The answer is unknown - CSP s4.9.9.
 
 
 
 
 
 
 
 
 
 
 
 Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781
 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy,
 XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS
 113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i
 wpłacony 5.445.000 zł.
 
 Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby
lub
 jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i
 poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie
 można kopiować, rozpowszechniać lub podejmować żadnych czynności
 w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę,
 proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę
 transmisję (wraz z załącznikami) z Państwa systemu.
 
 
 The information contained in this transmission is intended only for
the
 individual or entity to whom it is addressed. It may contain
privileged and
 confidential information and if you

RE: Client certs

2014-09-25 Thread Robin Alden
Hi Gerv,
I can send out a million client certificates for negligible
cost.  
That is especially attractive cost-wise for an existing system that I
have to increase the security of (say over username and password), but
which has not been identified as needing 2 factor authentication.  
Sending out a million anythings by snail-mail is spendy.

If you could rely on the user already having the number-sequence widget,
or of having a virtual widget on their smartphone (like Google
Authenticator) then the cost argument is irrelevant.

Regards
Robin


 -Original Message-
 From: dev-security-policy [mailto:dev-security-policy-
 bounces+robin=comodo@lists.mozilla.org] On Behalf Of Gervase
 Markham
 Sent: 25 September 2014 13:29
 To: mozilla-dev-security-pol...@lists.mozilla.org
 Subject: Client certs
 
 A question which occurred to me, and I thought I'd put before an
 audience of the wise:
 
 * What advantages, if any, do client certs have over number-sequence
   widgets such as e.g. the HSBC Secure Key, used with SSL?
 
 http://www.hsbc.co.uk/1/2/customer-support/online-banking-
 security/secure-key
 
 It seems like they have numerous disadvantages (some subjective):
 
 * Client certs can be invisibly stolen if a machine is compromised
 * Client certs are harder to manage and reason about for an average
   person
 * Client certs generally expire and need replacing, with no warning
 * Client certs are either single-machine, or need a probably-complex
   copying process
 
 What are the advantages?
 
 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


Mail list playing up?

2014-07-31 Thread Robin Alden
Hi,

There seems to be some problem with emails getting
through the list, for some participants, on some occasions.

 

In the recent thread on this list, entitled

Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy
Identifiers) made mandatory 
Gerv pointed out to me that an email I had sent had not appeared in the
Google Groups view of the list.

 

I went through the thread to see what was missing, and recorded which
were missing in this spreadsheet:

https://docs.google.com/spreadsheets/d/1nRpDJEZqSskdCujL5RdO9kM8caZXrUCm
KOSEp0j9Ffk/edit?usp=sharing

 

The posts to this thread by Robin Alden (me), Moudrick Dadashov, and
Kyle Hamilton didn't make it to the Google Groups view.

 

This isn't a complaint so much as a heads-up, that the google groups
view of the list is broken and if you rely on the Google Groups view you
are missing out on parts of the conversation!

 

Perhaps Google Groups throws away posts from people who aren't members
of the Google Group.

I've joined the google group, to see if the behaviour changes for me.

 

Regards
Robin Alden

Comodo



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: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

2014-07-23 Thread Robin Alden
+1

Robin


 -Original Message-
 From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
 Sent: 23 July 2014 16:05
 To: 'Moudrick M. Dadashov'; 'Robin Alden'; 'Gervase Markham';
 nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org
 Subject: RE: Proposal: Advocate to get Section 9.3.1 (Reserved
Certificate
 Policy Identifiers) made mandatory.
 
 I agree he was in favor of requiring the BR OIDs, as I think most CAs
are.
 
 Jeremy
 
 -Original Message-
 From: Moudrick M. Dadashov [mailto:m...@ssc.lt]
 Sent: Wednesday, July 23, 2014 9:02 AM
 To: Jeremy Rowley; 'Robin Alden'; 'Gervase Markham';
 nick.l...@lugatech.com; mozilla-dev-security-pol...@lists.mozilla.org
 Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved
Certificate
 Policy Identifiers) made mandatory.
 
 Having these identifiers takes us a long way towards our goal of
 deterministic evaluation of certificate issuance policy - that said
not all
 CAs have adopted them which is technically alright since the Baseline
 Requirements do allow them to use their own Policy Identifiers. This
is
 what Ryan said about Policy OID based
 (Deterministic) approach, I read this as in favor of Policy OIDs.
 
 Any other criticism why CAs should not support the Deterministic
 approach?
 
 Thanks,
 M.D.
 
 On 7/23/2014 5:34 PM, Jeremy Rowley wrote:
  Ryan Hurst wrote a blog post on this very topic not too long ago.
His
 conclusion was that determining, programmatically, the difference was
 difficult.  See http://unmitigatedrisk.com/?p=203.
 
  This is mostly because there are some certs that still include a
domain
 in the org field.  Requiring a BR OID serves two purposes - 1) the OID
is a
 positive assertion to the browser by the CA that the cert was issued
 under the BRs and intended for SSL and 2) the OID identifies the
sections
 relied on for validation.  The OID assists in auditing whether a CA is
aware
 of its practices and how it is choosing to comply with the BRs.
 
  Jeremy
 
  -Original Message-
  From: dev-security-policy
  [mailto:dev-security-policy-
 bounces+jeremy.rowley=digicert.com@lists.m
  ozilla.org] On Behalf Of Robin Alden
  Sent: Wednesday, July 23, 2014 8:02 AM
  To: 'Gervase Markham'; nick.l...@lugatech.com;
  mozilla-dev-security-pol...@lists.mozilla.org
  Subject: RE: [SPAM] Re: Proposal: Advocate to get Section 9.3.1
 (Reserved Certificate Policy Identifiers) made mandatory.
 
  On 23/07/14 10:06, nick.l...@lugatech.com wrote:
  The status quo today means that it is not possible to discriminate
  programatically between a DV and OV certificate in a standardized,
  reliable way.
  Gerv said..
  This is because Mozilla's position is that, in security terms,
there
  is no
  relevant difference.
 
  That is not the reason.
  That may be a contributory reason to Mozilla not proposing or
 supporting the proposition of language to change the BR's 9.3.1 which
 result in it not being compulsory to include a mandated policy OID in
a
 certificate which would identify it unequivocally as being a DV or an
OV
 certificate, but it is not the definitive reason why the BRs do not
mandate
 it.
 
  If the BRs already mandated it I would not expect your opinion or
your
 UI to change, but the OP's question would not have arisen as he would
 have easily programmatically been able to tell whether a certificate
was
 OV or DV.
 
  This is unreasonable as the validation and assurance on such
  certificates are very different.
  They are different, but not in a way that is reasonably measurable
  and auditable.
 
  snip
  If a cert does not meet the EV standards for information
validation,
  we
  feel you cannot sufficiently trust the O field, and therefore from
a
  security perspective there is no difference between that
certificate
  and
  one where the O field is absent. Hence we make no UI distinction
  between OV and DV.
 
  Whilst I disagree with your sentiment, in your UI (browser,
certificate
 viewer, mail client, etc.) it's your game, so it's your rules.
  The compulsory inclusion of a Policy Identifier OID in the
certificate
 definitively stating DV or OV need not offend you, since you will
probably
 continue to ignore it.
 
  As to the issue which presumably ignited the thread in the first
place, I
 think that for a non-EV BR compliant certificate you probably can
 distinguish programmatically between OV and DV.
  According to section 9.2.4 of the BRs, if the certificate subject
  contains an organizationName field and also contains one or both of
 (stateOrProvinceName and localityName) then it is an OV certificate.
  If the certificate subject does not contain an organizationName
field
 then it is an OV certificate.
  This begs the question of whether the certificate is claiming to be
an EV
 certificate or claiming to be BR compliant.
 
  Regards
  Robin Alden
  Comodo
  ___
  dev-security-policy mailing list
  dev-security-policy@lists.mozilla.org
  https