Re: FIDO versus X.509 (was <keygen>)

Thanks Anders,

  My reading of the situation is very close to yours. Of course WebID would allow 0$ certificate issuance, but we have not been able to get the message through, partly because it involves LinkedData which is not widely known, but also partly because there has been a campaing of misinformation about what we are doing by at least one member of W3C staff who should have been helping dialog but has instead been blocking it, and partly because of lack of knowledge, misconceptions, etc, etc... as shown by security specialists misunderstaning of how MD5 is used in <keygen> as you can see here:

 https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/OpZiSvqXBAAJ

and which I went into much greater length in 

 https://github.com/whatwg/html/issues/102

( It turns out that WebID-TLS is perhaps the few places where <keygen> is explained in full )

Perhaps the recent debate is going to help fix that.

At present we don't have anything against FIDO, it probably brings a lot of interesting
things to the table. What I am nearly sure about is that it does not bring is the ability to authenticate across sites with one certificate since they argue for SOP.

Does anyone know where FIDO makes the SOP case most clearly? This would help show that
<keygen> and client certs brings something to the table that FIDO does not, and therefore
that they can live happily together.

> On 6 Sep 2015, at 10:20, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> The FIDO advocates (which nowadays includes the W3C staff), claim that FIDO alliance
> schemes preserve privacy by building on "The Only True Web Security Model" (SOP) which
> indeed isolate domains from each other.  HTTPS client-certificates OTOH do not support
> this concept [1] and can thus be shared with any number of independent domains.
> 
> The latter is considered as privacy-impeding (supports tracking) which is the primary
> reason to why it is deprecated (but still working).
> 
> A thing the FIDO folks tend to not talk about is the fact that most people are
> moderately fond of having to register at each new site they visit.  And if they do,
> they typically need a verified e-mail address.  However, after this step, the privacy
> advantage with FIDO is more or less gone since an e-mail address is nothing but a static
> Globally Unique ID which can be searched for as well.

yes, This is the point I have been making for years, including at the IETF SAAG
https://mailarchive.ietf.org/arch/msg/saag/SnNCh-8cJqdwozSyyx2mgr-Ml3M 
in 2012.

This was before Snowden and I think since then the way you summarise the problem
above has been accepted much more widely ( but not everywhere, witeness FIDO  ).

> 
> But there's more this.  Having to verify e-mail address raises the bar to customer
> acceptance for web-sites so it makes sense to use an IdP instead, right?  Now we
> have built a system where a single party not only provides unified identities to any
> number of independent sites, but also knows where we've been.
> 
> Note: This should NOT be considered as "dissing" FIDO (only setting the record straight),
> because the FIDO alliance have succeeded creating a standard for low-cost browser-compatible
> security-tokens while the traditionalists (x.509) have been focusing on $200+ per seat card-
> solutions for governments.  This is also a reason why x.509 authentication on the Web haven't
> gotten any attention worth mentioning - Governments do neither care about costs nor convenience
> and if it works for other people is also a non-issue.  NIST have now joined FIDO...

> 
> Cheers,
> Anders Rundgren
> 
> 1] Although the CA filtering capability is useful it addresses another issue, credential selection.
>

Received on Sunday, 6 September 2015 09:59:06 UTC