"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 suggested,
在 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 h
在 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 1
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 p
> > - 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 to
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 in
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 having this
> > field
> "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 not
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 of
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 dif
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 new
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 1.4 and 4.3 respectively.
Many thanks,
Andrew
On Wed, Aug 3, 2
Hi Kathleen.
"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.
Why not call it
On 26/09/16 19:13, Andrew Ayer wrote:
> Fair enough. You should revise the following wording which says
> that the serial numbers and public keys are the same:
Updated again.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.
On Mon, 26 Sep 2016 18:54:09 +0100
Gervase Markham wrote:
> > The two *.zlbaba.com certificates (https://crt.sh/?id=30773543 and
> > https://crt.sh/?id=31103218) do not appear to be matching to me:
> > their public keys and serial numbers are different.
>
> The serial numbers of all the pairs ar
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
> http
> 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
https://wiki.mozilla.org/CA:WoSign_Is
> Summary of changes:
>
> - 'Signature Hash Algorithm' will have new drop down list:
> md2WithRSAEncryption, md5WithRSAEncryption, sha1WithRSAEncryption,
> sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption,
> ecdsaWithSHA256, ecdsaWithSHA384. ecdsaWithSHA521
> - 'Public
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 C
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
> contain
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 document,
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 fo
On Mon, Sep 26, 2016 at 1:14 PM, Gervase Markham wrote:
> 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.
>
.RU entries need a cleanup.
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 wante
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:
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 m
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
On 09/23/2016 10:11 PM, Peter Bowen wrote:
On Fri, Sep 23, 2016 at 10:46 AM, Eddy Nigg 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
Hi Rob,
On 23/09/16 16:18, Rob Stradling wrote:
> BTW, I also found certs containing the following public suffixes (i.e.,
> PSL+0), some of which may be of interest:
Are these in the PUBLIC or PRIVATE section of the PSL? CAs are, with
appropriate caution, not constrained from issuing certificates
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 Windo
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,
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.
__
32 matches
Mail list logo
