On 09/12/2012 03:55 PM, Paul Hoffman wrote:
> On Sep 11, 2012, at 9:11 AM, Stephen Farrell
> wrote:
>
>> We have a BoF chair volunteer who'll be able to
>> help start organising agenda slots etc after the
>> BoF approval call. More on that after the 24th.
>
> Delurking: that would be me.
An
On Sep 11, 2012, at 9:11 AM, Stephen Farrell wrote:
> We have a BoF chair volunteer who'll be able to
> help start organising agenda slots etc after the
> BoF approval call. More on that after the 24th.
Delurking: that would be me. I didn't want to say anything until I had caught
up on the list
On 09/12/2012 03:40 PM, Phillip Hallam-Baker wrote:
> Perhaps we need both a BOF and a Bar BOF on this.
Going straight to the bar after a BoF is a fine
plan :-)
S.
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo
Perhaps we need both a BOF and a Bar BOF on this.
On Wed, Sep 12, 2012 at 10:39 AM, Phillip Hallam-Baker wrote:
>
>
> On Wed, Sep 12, 2012 at 10:38 AM, Ben Laurie wrote:
>
>> On 12 September 2012 15:37, Phillip Hallam-Baker
>> wrote:
>> > On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie wrote:
>>
On Wed, Sep 12, 2012 at 10:38 AM, Ben Laurie wrote:
> On 12 September 2012 15:37, Phillip Hallam-Baker wrote:
> > On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie wrote:
> >>
> >> On 12 September 2012 15:33, Phillip Hallam-Baker
> wrote:
> >> > Issuing a cert on a public root for the purpose of en
Or we can use something like Omnibroker.
There are lots of ways to boil this bunny.
On Wed, Sep 12, 2012 at 10:37 AM, Ben Laurie wrote:
> On 12 September 2012 15:35, Phillip Hallam-Baker wrote:
> > I don't see why that would be the case. The requirement could be applied
> to
> > new certs goin
On 12 September 2012 15:37, Phillip Hallam-Baker wrote:
> On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie wrote:
>>
>> On 12 September 2012 15:33, Phillip Hallam-Baker wrote:
>> > Issuing a cert on a public root for the purpose of enabling transparent
>> > intercept of SSL on a Bluecoat like device
On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie wrote:
> On 12 September 2012 15:33, Phillip Hallam-Baker wrote:
> > Issuing a cert on a public root for the purpose of enabling transparent
> > intercept of SSL on a Bluecoat like device.
>
> OK. So how would one tell what the purpose was?
>
> For ex
On 12 September 2012 15:35, Phillip Hallam-Baker wrote:
> I don't see why that would be the case. The requirement could be applied to
> new certs going forward. Or the proofs could be embedded in OCSP tokens
> rather than the certs themselves.
I think I've said before that I would welcome a move
I don't see why that would be the case. The requirement could be applied to
new certs going forward. Or the proofs could be embedded in OCSP tokens
rather than the certs themselves.
On Wed, Sep 12, 2012 at 10:22 AM, Ben Laurie wrote:
> On 12 September 2012 02:37, Phillip Hallam-Baker wrote:
> >
On 12 September 2012 15:33, Phillip Hallam-Baker wrote:
> Issuing a cert on a public root for the purpose of enabling transparent
> intercept of SSL on a Bluecoat like device.
OK. So how would one tell what the purpose was?
For example: http://cdp.disney.com/
Issuing a cert on a public root for the purpose of enabling transparent
intercept of SSL on a Bluecoat like device.
Anyone doing so would be in direct contravention of the Mozilla
requirements (and probably everyone else) of course.
On Wed, Sep 12, 2012 at 10:30 AM, Ben Laurie wrote:
> On 12 S
On 12 September 2012 02:37, Phillip Hallam-Baker wrote:
> Thinking through some baby steps here. Perhaps one of the first steps might
> be to apply transparency to intermediate certs since those are the ones that
> have the highest risk associated?
>
> In particular I really hope that there is nob
On 12 September 2012 02:37, Phillip Hallam-Baker wrote:
> Thinking through some baby steps here. Perhaps one of the first steps might
> be to apply transparency to intermediate certs since those are the ones that
> have the highest risk associated?
You'd have to either re-issue them all, or upgra
Thinking through some baby steps here. Perhaps one of the first steps might
be to apply transparency to intermediate certs since those are the ones
that have the highest risk associated?
In particular I really hope that there is nobody out there issuing
intercept certs on public roots.
On Tue,
On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote:
>
> Hiya,
>
> If you want a BoF, then you need to do the required dance;-)
>
> "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area
> Directors at UTC 24:00. To request a BOF, please see instructions on
> Requesting a BOF." [1]
And the deadline's been met early:-) Thanks Ben.
I've put up some info on the BoF wiki. [1]
Note: this means that this BoF will be considered
for scheduling. It does not yet mean that it is
approved. That decision happens on Sep 24th.
If folks can post Internet-Drafts describing their
scheme(s)
etf.org [mailto:therightkey-boun...@ietf.org]
> On Behalf Of Stephen Farrell
> Sent: Tuesday, September 11, 2012 1:22 AM
> To: Ben Laurie
> Cc: therightkey@ietf.org
> Subject: [therightkey] Transparency BoF - there's a deadline...
>
>
> Hiya,
>
> If you want a BoF
om: therightkey-boun...@ietf.org [mailto:therightkey-boun...@ietf.org] On
Behalf Of Stephen Farrell
Sent: Tuesday, September 11, 2012 1:22 AM
To: Ben Laurie
Cc: therightkey@ietf.org
Subject: [therightkey] Transparency BoF - there's a deadline...
Hiya,
If you want a BoF, then you need to do the re
Hiya,
If you want a BoF, then you need to do the required dance;-)
"2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area
Directors at UTC 24:00. To request a BOF, please see instructions on
Requesting a BOF." [1]
Sean and I remain interested in folks' opinions about having this
Bo
20 matches
Mail list logo
