On Mon, Jan 18, 2016 at 11:24 PM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:
>
> > There isn't in Chrome, and here's the bug thread where the
> > Chrome team denied fervent requests by someone behind an enterprise
> > firewall to add MD5 support in behind a command line flag:
>
> That
On Mon, January 18, 2016 7:20 pm, Eric Mill wrote:
> I was suggesting not deciding a year ahead of time that enterprise apathy
> will be too overwhelmingly powerful to even try pushing on, in the
> specific
> case of SHA-1 deprecation.
Chrome has already decided this, as has (in effect) Micros
Correct. Sorry, I meant to say "on the Symantec-issued certs".
~reed
On Mon, Jan 18, 2016 at 10:55 PM, Eric Mill wrote:
> On Mon, Jan 18, 2016 at 10:45 PM, Reed Loden wrote:
>>
>> https://cabforum.org/pipermail/public/2016-January/006519.html has
>> more information on these certs.
>
>
> I don'
On Mon, Jan 18, 2016 at 10:45 PM, Reed Loden wrote:
> https://cabforum.org/pipermail/public/2016-January/006519.html has
> more information on these certs.
>
I don't think that includes the Digicert one, though?
>
> ~reed
>
> On Mon, Jan 18, 2016 at 10:23 PM, Kurt Roeckx wrote:
> > On Tue, Ja
https://cabforum.org/pipermail/public/2016-January/006519.html has
more information on these certs.
~reed
On Mon, Jan 18, 2016 at 10:23 PM, Kurt Roeckx wrote:
> On Tue, Jan 19, 2016 at 01:49:21AM +, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from
On 01/19/16 03:37, Charles Reiss wrote:
> On 01/19/16 03:23, Kurt Roeckx wrote:
>> On Tue, Jan 19, 2016 at 01:49:21AM +, Charles Reiss wrote:
>>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this
>>> year
>>> which chain to root CAs in Mozilla's program:
>>
>> I also h
On 01/19/16 03:23, Kurt Roeckx wrote:
> On Tue, Jan 19, 2016 at 01:49:21AM +, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this
>> year
>> which chain to root CAs in Mozilla's program:
>
> I also have some from C=US,O=VeriSign\, Inc.,OU=VeriSig
On Tue, Jan 19, 2016 at 01:49:21AM +, Charles Reiss wrote:
> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this
> year
> which chain to root CAs in Mozilla's program:
I also have some from C=US,O=VeriSign\, Inc.,OU=VeriSign Trust
Network,OU=Terms of use at https://www.
On Mon, Jan 18, 2016 at 8:46 PM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:
Because of this, anyone who has ever supported enterprise software is
> aware of the all too present necessity for enterprise flags. That is,
> off-by-default configuration flags that can change or alter behavio
Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
which chain to root CAs in Mozilla's program:
- https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root [DigiCert]
via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"
Also, the OCSP responder
On Mon, January 18, 2016 12:26 pm, Eric Mill wrote:
> On Mon, Jan 18, 2016 at 10:19 AM, Richard Barnes
> wrote:
>
> > ...
> >
> > One thing that has been proposed is to have an exception for local
> > roots,
> > i.e., to let non-default trust anchors continue to use SHA-1 for some
> > more
> > t
On Mon, January 18, 2016 3:01 pm, Jakob Bohm wrote:
> I was attempting to avoid the even-harder-to-debug error where behavior
> depends on how a root cert was added to the configuration.
I think you underestimate the challenges to debugging your solution proposes.
It's fairly easy to understand
On 18/01/2016 22:18, Richard Barnes wrote:
On Mon, Jan 18, 2016 at 11:07 AM, Jakob Bohm wrote:
On 18/01/2016 16:19, Richard Barnes wrote:
"Failed" might be a bit strong :) We had a temporary setback.
Like the blog post says, we're working on more precisely characterizing
how
widespread an
On Mon, Jan 18, 2016 at 3:26 PM, Eric Mill wrote:
> On Mon, Jan 18, 2016 at 10:19 AM, Richard Barnes
> wrote:
>
>> ...
>>
>> One thing that has been proposed is to have an exception for local roots,
>> i.e., to let non-default trust anchors continue to use SHA-1 for some more
>> time. What do f
On Mon, Jan 18, 2016 at 11:07 AM, Jakob Bohm wrote:
> On 18/01/2016 16:19, Richard Barnes wrote:
>
>> "Failed" might be a bit strong :) We had a temporary setback.
>>
>> Like the blog post says, we're working on more precisely characterizing
>> how
>> widespread and how broken these middleboxes
On Mon, Jan 18, 2016 at 10:19 AM, Richard Barnes
wrote:
> ...
>
> One thing that has been proposed is to have an exception for local roots,
> i.e., to let non-default trust anchors continue to use SHA-1 for some more
> time. What do folks here think about that idea?
>
That seems like a choice t
On 18/01/2016 16:19, Richard Barnes wrote:
"Failed" might be a bit strong :) We had a temporary setback.
Like the blog post says, we're working on more precisely characterizing how
widespread and how broken these middleboxes are, before taking steps to
re-enable the SHA-1 restrictions. I stil
"Failed" might be a bit strong :) We had a temporary setback.
Like the blog post says, we're working on more precisely characterizing how
widespread and how broken these middleboxes are, before taking steps to
re-enable the SHA-1 restrictions. I still think we're on track for turning
off SHA-1
18 matches
Mail list logo