On Fri, Jun 19, 2015 at 1:38 PM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:
> On Fri, June 19, 2015 11:10 am, Brian Smith wrote:
> > The current set of roots is already too big for small devices to
> > reasonably
> > manage, and that problem will get worse as more roots are added. Th
On Fri, June 19, 2015 11:10 am, Brian Smith wrote:
> The current set of roots is already too big for small devices to
> reasonably
> manage, and that problem will get worse as more roots are added. Thus,
> small devices have to take a subset of Mozilla's/Microsoft's/Apple's
> roots.
Without w
On Fri, Jun 19, 2015 at 7:24 AM, Gervase Markham wrote:
> On 17/06/15 22:50, Brian Smith wrote:
> > By "small scope," I'm referring to CAs who limit their scope to a certain
> > geographical region, language, or type of institution.
>
> I'm not sure how that neuters my objection. CAs who do more
On 17/06/15 22:50, Brian Smith wrote:
> By "small scope," I'm referring to CAs who limit their scope to a certain
> geographical region, language, or type of institution.
I'm not sure how that neuters my objection. CAs who do more than DV will
need to have local infrastructure in place for identit
On 18/6/2015 12:50 πμ, Brian Smith wrote:
I did, in my original message. HARICA's constraint includes *.org, which is
much broader in scope than they intend to issue certificates for. dNSName
constraints can't describe HARICA's scope.
Cheers,
Brian
Hi Brian,
It is very common for projects, re
Gervase Markham wrote:
> On 06/06/15 02:12, Brian Smith wrote:
> > Richard Barnes wrote:
> >
> >> Small CAs are a bad risk/reward trade-off.
> >
> > Why do CAs with small scope even get added to Mozilla's root program in
> the
> > first place? Why not just say "your scope is too limited to be wo
On 06/06/15 02:12, Brian Smith wrote:
> Richard Barnes wrote:
>
>> Small CAs are a bad risk/reward trade-off.
>
> Why do CAs with small scope even get added to Mozilla's root program in the
> first place? Why not just say "your scope is too limited to be worthwhile
> for us to include"?
There's
On Wednesday 10 June 2015 07:28:06 Rick Andrews wrote:
> I don't understand. The domain owner/admin is not a third party.
the third party in question was an entity running the CT service
and since they can produce a certificate signed by a trusted CA as a proof of
misissuance, the data itself i
I don't understand. The domain owner/admin is not a third party.
-Rick
> On Jun 10, 2015, at 4:01 AM, Hubert Kario wrote:
>
>> On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote:
>>> On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote:
>>> True, OTOH, if a third party says that t
On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote:
> On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote:
> > True, OTOH, if a third party says that there was a misissuance, that means
> > there was one.
>
> I disagree. Only the domain owner knows for sure what is a misissuance, and
On Wed, Jun 10, 2015 at 10:53:30AM +0100, Rob Stradling wrote:
> On 10/06/15 01:54, Matt Palmer wrote:
> >A log has a single well-defined purpose, and I don't think that adding
> >independent
> >functionality to the purpose of the log itself is a winning strategy.
>
> Indeed. A log and a monitor
On 10/06/15 01:54, Matt Palmer wrote:
On Tue, Jun 09, 2015 at 10:44:58AM +0100, Rob Stradling wrote:
On 09/06/15 04:05, Clint Wilson wrote:
To further support your claims here, Chris, there are already tools coming out
which actively monitor domains in CT logs and can be set up with notificati
On 10/06/15 01:46, Matt Palmer wrote:
On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote:
On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
On 2015-06-09 15:26, Peter Kurrasch wrote:
3) How frequently might such tools run? Or to put it differently, how much time
do I
On Tue, Jun 09, 2015 at 10:44:58AM +0100, Rob Stradling wrote:
> On 09/06/15 04:05, Clint Wilson wrote:
> >To further support your claims here, Chris, there are already tools coming
> >out which actively monitor domains in CT logs and can be set up with
> >notifications of misissuance:
> >https:/
On Tue, Jun 09, 2015 at 08:26:55AM -0500, Peter Kurrasch wrote:
> 1) How to exclude domains from the search? For example I want to find
> gmail certs but exclude something like "eggmail" which could be a false
> positive.
Constrain your search to "domains which have a name part which is exactly
'g
On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote:
> On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
> > On 2015-06-09 15:26, Peter Kurrasch wrote:
> > > 3) How frequently might such tools run? Or to put it differently, how
> > > much time do I probably have between whe
On Tuesday, June 9, 2015 at 12:23:57 PM UTC-7, Kurt Roeckx wrote:
> On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote:
> > On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
> > > On 2015-06-09 15:26, Peter Kurrasch wrote:
> > > > 3) How frequently might such tools run? Or
On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote:
> On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
> > On 2015-06-09 15:26, Peter Kurrasch wrote:
> > > 3) How frequently might such tools run? Or to put it differently, how
> > > much time do I probably have between whe
On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
> On 2015-06-09 15:26, Peter Kurrasch wrote:
> > 3) How frequently might such tools run? Or to put it differently, how much
> > time do I probably have between when I issue a gmail cert and when someone
> > figures it out (and of co
On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote:
> True, OTOH, if a third party says that there was a misissuance, that means
> there was one.
I disagree. Only the domain owner knows for sure what is a misissuance, and
what isn't. It seems likely that I might turn over all known
On 2015-06-09 15:26, Peter Kurrasch wrote:
3) How frequently might such tools run? Or to put it differently, how much time
do I probably have between when I issue a gmail cert and when someone figures
it out (and of course how much longer before my illegitimate cert is no longer
valid)? I need
I'm glad to see discussions of tools. Some points to consider:
1) How to exclude domains from the search? For example I want to find gmail
certs but exclude something like "eggmail" which could be a false positive.
2) How to address wild cards? For example can I bypass these detection tools
by
On Tuesday 09 June 2015 10:44:58 Rob Stradling wrote:
> On 09/06/15 04:05, Clint Wilson wrote:
> > To further support your claims here, Chris, there are already tools coming
> > out which actively monitor domains in CT logs and can be set up with
> > notifications of misissuance:
> > https://www.di
On 09/06/15 04:05, Clint Wilson wrote:
To further support your claims here, Chris, there are already tools coming out
which actively monitor domains in CT logs and can be set up with notifications
of misissuance:
https://www.digicert.com/certificate-monitoring/
https://groups.google.com/forum/#
To further support your claims here, Chris, there are already tools coming out
which actively monitor domains in CT logs and can be set up with notifications
of misissuance:
https://www.digicert.com/certificate-monitoring/
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/EPv_u
My point is that you cannot say CT "effectively destroys the attack value of
mis-issuance" and then as justification say that you are assuming someone will
notice. This is the gap I'm talking about: the space between when a
mis-issuance takes place and when someone notices.
For the sake of argu
On Fri, Jun 5, 2015 at 8:04 AM, Peter Kurrasch wrote:
>> Certificate Transparency gets us what we want, I think. CT works
>> globally, and is safer, and significantly changes the trust equation:
>>
>> * Reduces to marginal/effectively destroys the attack value of mis-issuance
>
> Please clarify
Richard Barnes wrote:
> Small CAs are a bad risk/reward trade-off.
>
Why do CAs with small scope even get added to Mozilla's root program in the
first place? Why not just say "your scope is too limited to be worthwhile
for us to include"?
> One way to balance this equation better is to scope t
On Thu, Jun 4, 2015 at 9:18 PM, Chris Palmer wrote:
> Certificate Transparency gets us what we want, I think. CT works
> globally, and is safer, and significantly changes the trust equation:
>
> * Reduces to marginal/effectively destroys the attack value of mis-issuance
> * Makes it possible for
You have a lot of ideas in here, Richard!
Asking the question "what is the increased risk we face by introducing new CA's
and new roots into the trust store?" is a good idea. How we go about answering
that gets tricky. It might be helpful to articulate some threat models facing
CA's, both gover
...snip...
> Certificate Transparency gets us what we want, I think. CT works
> globally, and is safer, and significantly changes the trust equation:
>
> * Reduces to marginal/effectively destroys the attack value of mis-issuance
Please clarify this statement because, as written, this is plain
Hi Richard,
On Thu, Jun 04, 2015 at 02:44:00PM -0400, Richard Barnes wrote:
> The thing that was driving my earlier proposal with regard to name
> constraints was a feeling of imbalance. With every CA we add to our
> program we add risk for every site on the web. That cost is supposed to be
> of
I'd like to try to up-level some of the discussions we're having about name
constraints, to see if we can find some higher-level consensus.
The thing that was driving my earlier proposal with regard to name
constraints was a feeling of imbalance. With every CA we add to our
program we add risk fo
33 matches
Mail list logo
