On Sat, Sep 10, 2016 at 06:33:59PM -0700, xiaoyi...@outlook.com wrote:
> But is it a OK behavior if a CDN vendor doesn't immediately revoke the old
> cert after I stop using its CDN service?
I don't think it's automatically terrible behaviour. Plenty of people let
certificates lapse rather than a
在 2016年9月13日星期二 UTC+8上午8:07:31，Matt Palmer写道：
> On Mon, Sep 12, 2016 at 08:57:29PM +0100, Rob Stradling wrote:
> > On 12/09/16 18:57, Jakob Bohm wrote:
> > > On 11/09/2016 07:49, Peter Bowen wrote:
> > >> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei wrote:
> > >>> So when I delegated the DNS servic
On 13/09/2016 05:01, Peter Bowen wrote:
On Mon, Sep 12, 2016 at 7:02 PM, Ryan Sleevi wrote:
On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote:
This would have two advantages:
1) Helps limit blast radius of whitelisting a name/domain
I'm unclear what you mean by this. I sug
On 13/09/2016 03:03, Kyle Hamilton wrote:
I would prefer not to see a securelogin-.arubanetworks.com
name, because such makes it look like Aruba Networks is operating the
captive portal. If (for whatever reason) the system is compromised, or
the login process is altered, or there's a
On Mon, Sep 12, 2016 at 7:02 PM, Ryan Sleevi wrote:
> On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote:
>> This would have two advantages:
>> 1) Helps limit blast radius of whitelisting a name/domain
>
> I'm unclear what you mean by this. I suggest there's an additional, unstat
On Monday, September 12, 2016 at 6:14:34 PM UTC-7, Richard Wang wrote:
> Please don't mix StartCom with WoSign case, StartCom is 100% independent at
> 2015.
>
> Even now, it still independent in the system, in the validation team and
> management team, we share the CRL/OCSP distribution resource
On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote:
> I'm not clear from this description, are you proposing to whitelist
> eTLD+1 or full hostnames? How large would the lists be if you
> whitelisted eTLD+1?
This is whitelisting at eTLD+1 (although with a slightly older version
Please don't mix StartCom with WoSign case, StartCom is 100% independent at
2015.
Even now, it still independent in the system, in the validation team and
management team, we share the CRL/OCSP distribution resource only.
Best Regards,
Richard
-Original Message-
From: dev-security-po
On Mon, Sep 12, 2016 at 2:46 PM, Ryan Sleevi wrote:
> To that end, I'm going to offer one more suggestion for consideration:
> G) Distrust with a Whitelist of Hosts
>
> The issue with C is that it becomes easily inflated by issuing certificates,
> even if they're not used; that is, a free certifi
I would prefer not to see a securelogin-.arubanetworks.com
name, because such makes it look like Aruba Networks is operating the
captive portal. If (for whatever reason) the system is compromised, or
the login process is altered, or there's a need to enter credit card
information [I do
On Mon, Sep 12, 2016 at 5:46 PM Ryan Sleevi wrote:
> On Wednesday, August 31, 2016 at 12:43:50 PM UTC-7, Nick Lamb wrote:
> > I have spent some time thinking about this, but I am only one person,
> and one with relatively little in-depth knowledge of the Mozilla project,
> so I think I will lay o
On 13/09/2016 01:28, Ryan Sleevi wrote:
On Monday, September 12, 2016 at 3:51:56 PM UTC-7, Jakob Bohm wrote:
Note that this is *entirely* outside CA/B and CA inclusion related
guidelines, since CloudFlare is (presumably) not a CA and thus not
subject to such guidelines.
Then isn't it also gene
Of all the possible options - G seems to be the most practical. It provides a
few key benefits, that I see as making it a clear leader:
1) It can be implemented quickly. It has been discussed that C is rather
complex because of the size of the list, with the only truly practical solution
being
On Friday, September 9, 2016 at 11:13:49 AM UTC-4, Han Yuwei wrote:
> 在 2016年9月9日星期五 UTC+8上午12:00:15，Stephen Schrauger写道：
> > Regarding the specific file verification method:
> >
> > It proves you control the web server that runs under the domain. Which is
> > more or less all that you need to pr
On Saturday, September 10, 2016 at 10:44:05 AM UTC-4, Erwann Abalea wrote:
> Bonjour,
>
> Le samedi 10 septembre 2016 14:37:40 UTC+2, Han Yuwei a écrit :
> > I am using Cloudflare's DNS service and I found that Cloudflare has issued
> > a certficate to their server including my domain. But I didn
On Monday, September 12, 2016 at 2:43:09 PM UTC+1, Peter Kurrasch wrote:
> I was thinking of more the server (cloud) side of things. I'm not familiar
> enough with Cloudflare's service, but I imagine that if I have a server set
> up I will also have access to my private key. If so, I now have acc
On Mon, Sep 12, 2016 at 08:57:29PM +0100, Rob Stradling wrote:
> On 12/09/16 18:57, Jakob Bohm wrote:
> > On 11/09/2016 07:49, Peter Bowen wrote:
> >> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei wrote:
> >>> So when I delegated the DNS service to Cloudflare, Cloudflare have
> >>> the privilege to
On Monday, September 12, 2016 at 3:51:56 PM UTC-7, Jakob Bohm wrote:
> Note that this is *entirely* outside CA/B and CA inclusion related
> guidelines, since CloudFlare is (presumably) not a CA and thus not
> subject to such guidelines.
Then isn't it also generally outside the scope of this list?
On 12/09/2016 23:48, Ryan Sleevi wrote:
On Monday, September 12, 2016 at 2:33:47 PM UTC-7, Jakob Bohm wrote:
I find fault in CloudFlare (presuming the story is actually as
reported).
Why? Apologies, but I fail to see what you believe is "wrong", given how
multiple people have pointed to you i
On Monday, September 12, 2016 at 2:33:47 PM UTC-7, Jakob Bohm wrote:
> I find fault in CloudFlare (presuming the story is actually as
> reported).
Why? Apologies, but I fail to see what you believe is "wrong", given how
multiple people have pointed to you it being well-understood and permissible,
On Wednesday, August 31, 2016 at 12:43:50 PM UTC-7, Nick Lamb wrote:
> I have spent some time thinking about this, but I am only one person, and one
> with relatively little in-depth knowledge of the Mozilla project, so I think
> I will lay out the options I've thought about and invite feedback t
On 12/09/2016 21:57, Rob Stradling wrote:
On 12/09/16 18:57, Jakob Bohm wrote:
On 11/09/2016 07:49, Peter Bowen wrote:
On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei wrote:
So when I delegated the DNS service to Cloudflare, Cloudflare have
the privilege to issue the certificate by default? Can I
On 12/09/16 18:57, Jakob Bohm wrote:
> On 11/09/2016 07:49, Peter Bowen wrote:
>> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei wrote:
>>> So when I delegated the DNS service to Cloudflare, Cloudflare have
>>> the privilege to issue the certificate by default? Can I understand
>>> like that?
>>
>> I
I agree with Jakob. This is similar to case laws vs statutory law. Even though
we can get the same understandings from various cases, I believe in this
situation, it will be clearer to codify such requirements clearly.
On Monday, September 12, 2016 at 10:38:48 AM UTC-7, Jakob Bohm wrote:
> On
On 11/09/2016 07:49, Peter Bowen wrote:
On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei wrote:
So when I delegated the DNS service to Cloudflare, Cloudflare have the
privilege to issue the certificate by default? Can I understand like that?
I would guess that they have a clause in their terms of
On 12/09/2016 09:42, Gervase Markham wrote:
On 11/09/16 23:42, Lee wrote:
A careful CA validator does DNS only by making authoritative queries, so
they're not subject to cache poisoning since they don't look at cached
answers.
Would a not careful CA be flagged on their yearly audit?
It only
On 10/09/2016 14:39, Gervase Markham wrote:
On 09/09/16 11:59, Jakob Bohm wrote:
Since a major root compromise is generally considered the worst
possible security event for a trusted CA, this wording could easily be
(mis?)understood not to require reporting of lesser security failures,
such as i
On 10/09/2016 14:45, Gervase Markham wrote:
On 09/09/16 11:53, Jakob Bohm wrote:
As I read the Wiki description of WoSign issue L: Arbitrary High port
validation, the description notes a case of port 8080 validation as an
instance of this.
If the BR and or CP/CPS indeed classify port 8080 as a
Le lundi 12 septembre 2016 15:59:14 UTC+2, Ben Laurie a écrit :
> On 10 September 2016 at 15:43, Erwann Abalea wrote:
> > Ironically, since you're not the Subscriber, you cannot request for the
> > revocation of this certificate, at least not directly to the CA. If you
> > want this certificate
On 09/12/2016 03:42 PM, Peter Kurrasch wrote:
> Hi Erwann,
>
> I was thinking of more the server (cloud) side of things. I'm not
> familiar enough with Cloudflare's service, but I imagine that if I
> have a server set up I will also have access to my private key. If
> so, I now have access to the
On Mon, Sep 12, 2016 at 6:42 AM, Peter Kurrasch wrote:
> I was thinking of more the server (cloud) side of things. I'm not familiar
> enough with Cloudflare's service, but I imagine that if I have a server set
> up I will also have access to my private key. If so, I now have access to the
> pri
Hi Erwann,
I was thinking of more the server (cloud) side of things. I'm not familiar
enough with Cloudflare's service, but I imagine that if I have a server set up
I will also have access to my private key. If so, I now have access to the
private key of the other domains. Perhaps there are pr
Bonjour,
Le lundi 12 septembre 2016 14:30:56 UTC+2, Peter Kurrasch a écrit :
> I noticed there a several other domains listed on that cert besides Han's
> (and wildcard versions for each). Unless Han is the registrar or has some
> other affiliation with those domains it seems to me there is a r
I noticed there a several other domains listed on that cert besides Han's (and
wildcard versions for each). Unless Han is the registrar or has some other
affiliation with those domains it seems to me there is a risk of some private
key compromise situation.
Also, if I want to add a new domain
On 10/09/16 15:43, Erwann Abalea wrote:
> In my opinion, the most plausible verification method in this case is the
> last one: "Having the Applicant demonstrate practical control over the FQDN
> by making an agreed-upon change to information found in the DNS containing
> the FQDN";
Correct.
On 09/09/16 18:25, Ryan Sleevi wrote:
> On Friday, September 9, 2016 at 4:42:12 AM UTC-7, Rob Stradling wrote:
>> That's a good point. So, to fix my proposal...
>>
>> For CAs that are on (borrowing Matt's wording) "quintuple secret
>> probation" due to a "history of shenanigans with notBefore date
On 11/09/16 23:42, Lee wrote:
>> A careful CA validator does DNS only by making authoritative queries, so
>> they're not subject to cache poisoning since they don't look at cached
>> answers.
>
> Would a not careful CA be flagged on their yearly audit?
It only might, if doing non-authoritative qu
37 matches
Mail list logo
