Hi Oliver--
Sorry it's taken me a while to process this message -- i've been very
bad at dealing with a large backlog :(
I haven't thought through the bigger picture of whether this mixture of
WebID and OpenPGP is a good idea or not, but let me address the
technical angle first.
On 08/28/2013 05
Hi Daniel.
I've been slowly trying to play with OpenPGP and WebID, in the context
of its use in the Debian project, and wanted to investigate the possible
solutions to bind an OpenPGP key to a WebID.
Maybe your expertise on OpenPGP specs can help here.
Basically, in the same way as a X590 cert p
Russ Allbery writes:
> So, again, it comes down to what problem we're trying to solve. If the
> problem is just how do we authenticate Debian contributors to Debian
> systems, then we're actually in the institutional case and we don't have
> to trust anyone outside the project: we can deploy our
On 16-05-13 18:37, Russ Allbery wrote:
> Wouter Verhelst writes:
>> On 16-05-13 17:42, Russ Allbery wrote:
>
>>> You could, in theory, switch to DNSSEC, but now you're just replacing
>>> one CA cartel with another.
>
>> Except that with DNSSEC (and DANE), the number of people you have to
>> trus
On 2013-05-17 at 10:08:20, Olivier Berger wrote:
> AFAIU, I guess that, at least from the user-friendliness POV, the main
> perceptible difference, is :
> - OpenID uses a URL as a person's identifier : may or not be easily
>copied/remembered/dictated
> - WebID uses a URL too, same problems (t
On 2013-05-16 at 14:12:33, Daniel Kahn Gillmor wrote:
> It looks to me like BrowserID/Persona will only work in web browsers
> with a functional javascript stack (and eventually, with a functional
> javascript crypto stack). The client authentication happens inside the
> TLS layer, over the HTTP p
Stéphane Glondu writes:
> Le 16/05/2013 18:37, Russ Allbery a écrit :
>> Right, it depends on what your risk model is. If you're defending
>> against incompetence and/or commercial greed overriding security
>> practices, DNSSEC looks a lot more appealing than the CA cartel, since
>> there isn't
Hi again.
Just in case it helps a bit more, let me forward you this message from
Andrei Sambra, a Debian user and WebID working group member (who's also
the developer of MyProfile, a "killer demo" service of WebID at [1]
- project/code at [0]).
Andrei read the thread an wanted to provide some fee
Quoting Russ Allbery (2013-05-16 22:24:34)
> Jonas Smedegaard writes:
> > Quoting Russ Allbery (2013-05-16 19:57:59)
>
> >> Sure, but if you have control over the server certificate and are
> >> tying the server certificate to the user certificate via some
> >> mechanism like Monkeysphere, why
Hi again.
Russ Allbery writes:
> Jonas Smedegaard writes:
>> Quoting Russ Allbery (2013-05-16 19:57:59)
>
>>> Sure, but if you have control over the server certificate and are tying
>>> the server certificate to the user certificate via some mechanism like
>>> Monkeysphere, why do the whole ind
Hi again.
Russ Allbery writes:
> I can understand why you may want to externalize the metadata if you have
> no control over the certificate creation process and therefore can't put
> metadata directly in it. I don't understand what you gain (other than
> complexity) by externalizing the metada
Russ Allbery writes:
> Jonas Smedegaard writes:
>> Quoting Russ Allbery (2013-05-16 18:37:06)
>
>>> but it's not clear to me why we'd bother as opposed to just issuing
>>> client X.509 certificates with the metadata already included.
>
>> Because the very separation of identifiers from the ident
Quoting Stéphane Glondu (2013-05-17 08:14:13)
> Le 16/05/2013 18:37, Russ Allbery a écrit :
> >>> You could, in theory, switch to DNSSEC, but now you're just
> >>> replacing one CA cartel with another.
> >
> >> Except that with DNSSEC (and DANE), the number of people you have
> >> to trust is mu
Hi.
Philip Hands writes:
>
> Do you have any thoughts on how that compares with using
> BrowserID/Persona? I'd got the impression that BrowserID has been put
> together learning from mistakes of OpenID & WebID, but perhaps I'm just
> swallowing their marketing.
>
AFAIU, I guess that, at least
Le 16/05/2013 20:40, Russ Allbery a écrit :
> What am I missing?
>
> I suppose one thing that I could be missing is that, with a certificate,
> you have no privacy controls over what metadata you release. Whatever you
> put in the certificate is visible to anyone who looks at the certificate.
> (
Le 16/05/2013 18:37, Russ Allbery a écrit :
>>> You could, in theory, switch to DNSSEC, but now you're just replacing
>>> one CA cartel with another.
>
>> Except that with DNSSEC (and DANE), the number of people you have to
>> trust is much smaller.
>
> Right, it depends on what your risk model i
On May 16, Russ Allbery wrote:
> DNSSEC isn't going to help. I think it's best to assume that both the US
> and Chinese governments, at least, can make DNSSEC say what they want it
> to if they ever needed to.
Maybe, but I think it's also safe to assume that the USG has no way of
interfering wi
On 05/16/2013 03:52 PM, Jonas Smedegaard wrote:
> I think you are missing the potential for third-parties to make use of
> identifiers without needing authentication.
well, they still need to do authentication. For example, consider three
(not necessarily incompatible) channels to tie authentic
Jonas Smedegaard writes:
> Quoting Russ Allbery (2013-05-16 19:57:59)
>> Sure, but if you have control over the server certificate and are tying
>> the server certificate to the user certificate via some mechanism like
>> Monkeysphere, why do the whole indirection dance through a URI at all?
> B
Quoting Russ Allbery (2013-05-16 20:40:24)
> Jonas Smedegaard writes:
> > Quoting Russ Allbery (2013-05-16 18:37:06)
>
> >> but it's not clear to me why we'd bother as opposed to just issuing
> >> client X.509 certificates with the metadata already included.
>
> > Because the very separation of
Quoting Daniel Kahn Gillmor (2013-05-16 20:38:41)
> On 05/16/2013 01:57 PM, Russ Allbery wrote:
> > If introduce Monkeysphere to do the URI endpoint verification, it
> > seems to me like you could just as easily introduce Monkeysphere to
> > do the user certificate verification directly, thus rem
Quoting Russ Allbery (2013-05-16 19:57:59)
> Jonas Smedegaard writes:
> > Quoting Russ Allbery (2013-05-16 17:42:20)
> >> Jonas Smedegaard writes:
>
> >>> This seems similar as WebID: In principle ties to HTTPS - and
> >>> therefore the CA cartel - is only optional (other URIs than http
> >>>
Jonas Smedegaard writes:
> Quoting Russ Allbery (2013-05-16 18:37:06)
>> but it's not clear to me why we'd bother as opposed to just issuing
>> client X.509 certificates with the metadata already included.
> Because the very separation of identifiers from the identified makes the
> identifiers u
On 05/16/2013 01:57 PM, Russ Allbery wrote:
> If introduce Monkeysphere to do the URI endpoint verification, it seems to
> me like you could just as easily introduce Monkeysphere to do the user
> certificate verification directly, thus removing the need to introduce a
> third party metadata provide
On 05/15/2013 11:04 PM, Philip Hands wrote:
> Do you have any thoughts on how that compares with using
> BrowserID/Persona? I'd got the impression that BrowserID has been put
> together learning from mistakes of OpenID & WebID, but perhaps I'm just
> swallowing their marketing.
It looks to me li
Quoting Russ Allbery (2013-05-16 18:37:06)
> So, again, it comes down to what problem we're trying to solve. If
> the problem is just how do we authenticate Debian contributors to
> Debian systems, then we're actually in the institutional case and we
> don't have to trust anyone outside the pro
Jonas Smedegaard writes:
> Quoting Russ Allbery (2013-05-16 17:42:20)
>> Jonas Smedegaard writes:
>>> This seems similar as WebID: In principle ties to HTTPS - and
>>> therefore the CA cartel - is only optional (other URIs than http ones
>>> suffice). In reality alternatives to HTTP(S) is work
[ Cc'ing Daniel to help kill my misconceptions, as need be ]
Quoting Russ Allbery (2013-05-16 17:42:20)
> Jonas Smedegaard writes:
>
> > This seems similar as WebID: In principle ties to HTTPS - and
> > therefore the CA cartel - is only optional (other URIs than http
> > ones suffice). In rea
Wouter Verhelst writes:
> On 16-05-13 17:42, Russ Allbery wrote:
>> You could, in theory, switch to DNSSEC, but now you're just replacing
>> one CA cartel with another.
> Except that with DNSSEC (and DANE), the number of people you have to
> trust is much smaller.
Right, it depends on what your
On 16-05-13 17:42, Russ Allbery wrote:
> You could, in theory, switch to DNSSEC, but now you're just replacing one
> CA cartel with another.
Except that with DNSSEC (and DANE), the number of people you have to
trust is much smaller.
--
This end should point toward the ground if you want to go to
On 16/05/13 16:42, Russ Allbery wrote:
> In essence, [WebID]
> moves the authentication problem from user authentication to
> URI endpoint authentication, under the theory that we already know how to
> validate URI endpoints and that such validation is an easier problem.
... or to look at it anoth
Jonas Smedegaard writes:
> This seems similar as WebID: In principle ties to HTTPS - and therefore
> the CA cartel - is only optional (other URIs than http ones suffice).
> In reality alternatives to HTTP(S) is work in progress.
Changing the protocol doesn't help you get away from the CA depe
Quoting Stéphane Glondu (2013-05-16 10:57:19)
> Le 16/05/2013 05:04, Philip Hands a écrit :
> > Do you have any thoughts on how that compares with using
> > BrowserID/Persona? I'd got the impression that BrowserID has been
> > put together learning from mistakes of OpenID & WebID, but perhaps
>
Le 16/05/2013 05:04, Philip Hands a écrit :
> Do you have any thoughts on how that compares with using
> BrowserID/Persona? I'd got the impression that BrowserID has been put
> together learning from mistakes of OpenID & WebID, but perhaps I'm just
> swallowing their marketing.
IIUC, there is no
Daniel Kahn Gillmor writes:
> On 05/14/2013 10:03 AM, Jonas Smedegaard wrote:
>
>> I have also thought WebID would be a perfect match for things like this.
> [...]
>> Daniel has raised concerns about WebID:
>> http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/001030.html
>>
On 05/14/2013 10:03 AM, Jonas Smedegaard wrote:
> I have also thought WebID would be a perfect match for things like this.
[...]
> Daniel has raised concerns about WebID:
> http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/001030.html
>
> Quite frustrating, because I trust D
36 matches
Mail list logo
