Re: WoSign and StartCom

> This fixing of the notAfter date in this style of certificate may > have been a sensible move to avoid accidentally issuing SHA-1 > certificates whose validity extends into 2017, which would also be a > BR violation. This contradicts the "Issue D" section at

Re: WoSign and StartCom

On 26/09/16 18:10, Andrew Ayer wrote: > This contradicts the "Issue D" section at > https://wiki.mozilla.org/CA:WoSign_Issues which says that this > issue was not a BR violation. You are quite right, thank you - fixed :-) > The two *.zlbaba.com certificates (https://crt.sh/?id=30773543 and >

Re: WoSign and StartCom

On Monday, September 26, 2016 at 7:21:13 AM UTC-7, Gervase Markham wrote: > Today, Mozilla is publishing an additional document containing further > research into the back-dating of SHA-1 certificates, in violation of the > CAB Forum Baseline Requirements, to avoid browser blocks. It also >

Re: Updating Production Common CA Database

On Monday, September 26, 2016 at 2:06:22 AM UTC-7, Gervase Markham wrote: > Hi Kathleen, > > This generally all looks excellent, but: > > On 25/09/16 00:02, Kathleen Wilson wrote: > > - 'CRl URl(s)' will be populated by urls ending with .crl only > > There is no standard, AFAIK, which requires

Re: Updating Production Common CA Database

> Summary of changes: > > - 'Signature Hash Algorithm' will have new drop down list: > md2WithRSAEncryption, md5WithRSAEncryption, sha1WithRSAEncryption, > sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption, > ecdsaWithSHA256, ecdsaWithSHA384. ecdsaWithSHA521 > - 'Public

Re: Comodo issued a certificate for an extension

On Saturday, September 24, 2016 at 7:07:39 AM UTC+8, Showfom wrote: > First, let me introduce myself, I'm a famous investor of ccTLD domains from > China. > > Recently we get an easy-remember domain www.sb, please note the extension is > .sb > > I ordered a Comodo Positive SSL for this domain,

Re: Comodo issued a certificate for an extension

On Sunday, September 25, 2016 at 6:24:11 AM UTC+8, Percy wrote: > Ha! @Showfom perhaps you should try getting a widecard cert from them and > consequently obtain a cert for all *.sb domains. I tried to get cert from StartSSL, they will only issue www.sb or www.www.sb, that's good.

Re: Updating Production Common CA Database

Hi Kathleen, This generally all looks excellent, but: On 25/09/16 00:02, Kathleen Wilson wrote: > - 'CRl URl(s)' will be populated by urls ending with .crl only There is no standard, AFAIK, which requires CRL URLs to end in ".crl". File extensions indicating the file type were originally a

Re: Time to distrust

On 23/09/16 17:15, Jakob Bohm wrote: > Mechanisms such as OneCRL tend to be horribly incomplete. Just in the > past few months there has been repeated mention on this list of revoked > certificates that were not on OneCRL, only on the CA CRLs. OneCRL is not intended to be a comprehensive list of

Re: Updating Production Common CA Database

On 26/09/2016 11:05, Gervase Markham wrote: Hi Kathleen, This generally all looks excellent, but: On 25/09/16 00:02, Kathleen Wilson wrote: - 'CRl URl(s)' will be populated by urls ending with .crl only There is no standard, AFAIK, which requires CRL URLs to end in ".crl". File extensions

Re: Sanctions short of distrust

On 26/09/16 12:25, Rob Stradling wrote: > Who determines whether or not the PSL is accurate? Does common sense > ever override the explicitly stated will of the TLD operator? Normally no, not for the explicitly-stated will (e.g. an email to us). It might perhaps override a random policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道： > Hello, > > I have completed a read through of the English translations of the CP > (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if there > were any more recent translations? It looks like the local language > versions are

Re: Sanctions short of distrust

On 26/09/16 11:14, Rob Stradling wrote: > ICANN: kuzbass.ru There are several .ru in your list; we should check whether the PSL is actually accurate. I think they opened up a lot of previously-reserved domains a while back, but it's hard to find the right records. These are the non-RU entries:

Re: Sanctions short of distrust

On 26/09/16 10:07, Gervase Markham wrote: > Hi Rob, > > On 23/09/16 16:18, Rob Stradling wrote: >> BTW, I also found certs containing the following ICANN suffixes (i.e., >> PSL+0), some of which may be of interest: > > Are these in the PUBLIC or PRIVATE section of the PSL? (s/PUBLIC/ICANN) A

Re: Sanctions short of distrust

Who determines whether or not the PSL is accurate? Does common sense ever override the explicitly stated will of the TLD operator? (BTW, just to be clear: I wasn't alleging, or even speculating, that the certs containing dNSNames for these public suffices were necessarily misissued. I only

WoSign and duplicate serial numbers

Hi, In their report and the audit statement they talk about 392 duplicate serial numbers, with links to the crt.sh page for those serial numbers. But they in fact actually point to 393, the first group has 314 and not 313 duplicates in it. This was already the case before they published their

Re: Time to distrust

On 23/09/2016 18:46, Ryan Sleevi wrote: On Friday, September 23, 2016 at 9:15:48 AM UTC-7, Jakob Bohm wrote: they are nowhere as bad as proponents of extreme centralization schemes claim. Citation needed. It would seem that you're not familiar with the somewhat well-accepted industry state

Re: Updating Production Common CA Database

> "Certificate ID" seems like entirely the wrong name for this field, > given that it [SHA-256(der(subject) + der(spki))] doesn't actually > identify a unique certificate! > Indeed, the whole point of having this > field seems to be to identify _multiple_ related certificates. Correct > Why

Re: WoSign and StartCom

"However, many eyes are on the Web PKI and if such additional back-dating is discovered (by any means), Mozilla will immediately and permanently revoke trust in all WoSign and StartCom roots." Could you elaborate a bit on concrete ways of discovering such backdating? As WoSign itself

Re: WoSign and StartCom

在 2016年9月26日星期一 UTC+8下午10:21:13，Gervase Markham写道： > Today, Mozilla is publishing an additional document containing further > research into the back-dating of SHA-1 certificates, in violation of the > CAB Forum Baseline Requirements, to avoid browser blocks. It also > contains some conclusions we

Re: Updating Production Common CA Database

How about CA ID? On Sep 26, 2016 16:26, "Kathleen Wilson" wrote: > > "Certificate ID" seems like entirely the wrong name for this field, > > given that it [SHA-256(der(subject) + der(spki))] doesn't actually > > identify a unique certificate! > > Indeed, the whole point of

Re: Time to distrust

The actual revocation model I had in mind was a more friendly one where the cert holder wants it revoked for some reason. This was based on your research which showed that many ‎WoSign clients were not using their WoSign-issued certs. (I don't remember if you indicated they had switched to a

Re: Updating Production Common CA Database

> > - Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' will > > show the new fields instead. > > - CSV Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' > > will show the new fields instead. > > > The reports are still being updated. Some additional changes

WoSign and StartCom

Today, Mozilla is publishing an additional document containing further research into the back-dating of SHA-1 certificates, in violation of the CAB Forum Baseline Requirements, to avoid browser blocks. It also contains some conclusions we have drawn from the recent investigations, and a proposal