<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: About http/https: different or the same identity: </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>I think there is general agreement that we could/should make it required for an Identity Provider since they're in the business of providing identity so can do some extra work.<BR>
<BR>
This doesn't however help the delgation case. If I have davidrecordon.com hosted on GeoCities where I can't have a SSL cert, then even if my IdP is using SSL there is still that untrusted fetch in the flow.<BR>
<BR>
I think that this needs to end up in terms of we can't strive for the perfect. A draft of the OpenID Auth spec should be posted to the mailing list tonight and in part of the review/feedback cycle we should decide how it should address this issue.<BR>
<BR>
--David<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: yadis-bounces@lists.danga.com on behalf of Wieringa, Helmer (RBI-NL)<BR>
Sent: Wed 6/28/2006 6:44 AM<BR>
To: yadis@lists.danga.com<BR>
Subject: About http/https: different or the same identity:<BR>
<BR>
What is indeed against deciding to make the use of the secure protocol<BR>
just mandatory for identity management messaging? Pro: decreasing<BR>
security risks and no identity crises; we do not want complexity -<BR>
Helmer<BR>
<BR>
<BR>
-----Oorspronkelijk bericht-----<BR>
Van: yadis-bounces@lists.danga.com<BR>
[<A HREF="mailto:yadis-bounces@lists.danga.com">mailto:yadis-bounces@lists.danga.com</A>] Namens<BR>
yadis-request@lists.danga.com<BR>
Verzonden: woensdag 28 juni 2006 14:00<BR>
Aan: yadis@lists.danga.com<BR>
Onderwerp: [SPAM-BA] - yadis Digest, Vol 14, Issue 23 - Bayesian Filter<BR>
detected spam<BR>
<BR>
Send yadis mailing list submissions to<BR>
yadis@lists.danga.com<BR>
<BR>
To subscribe or unsubscribe via the World Wide Web, visit<BR>
<A HREF="http://lists.danga.com/mailman/listinfo/yadis">http://lists.danga.com/mailman/listinfo/yadis</A><BR>
or, via email, send a message with subject or body 'help' to<BR>
yadis-request@lists.danga.com<BR>
<BR>
You can reach the person managing the list at<BR>
yadis-owner@lists.danga.com<BR>
<BR>
When replying, please edit your Subject line so it is more specific<BR>
than "Re: Contents of yadis digest..."<BR>
<BR>
<BR>
Today's Topics:<BR>
<BR>
1. RE: that ess in 'https' (Recordon, David)<BR>
2. RE: that ess in 'https' (Recordon, David)<BR>
3. Re: that ess in 'https' (Dag Arneson)<BR>
4. Re: that ess in 'https' (David Strauss)<BR>
5. Re: that ess in 'https' (David Strauss)<BR>
<BR>
<BR>
----------------------------------------------------------------------<BR>
<BR>
Message: 1<BR>
Date: Tue, 27 Jun 2006 16:27:38 -0700<BR>
From: "Recordon, David" <drecordon@verisign.com><BR>
Subject: RE: that ess in 'https'<BR>
To: "David Strauss" <mailinglists@fourkitchens.com>, "Martin Atkins"<BR>
<mart@degeneration.co.uk><BR>
Cc: yadis@lists.danga.com<BR>
Message-ID:<BR>
<BR>
<8A1A6155AA70064EBE4DC370E709147B91A341@MOU1WNEXMB11.vcorp.ad.vrsn.com><BR>
<BR>
Content-Type: text/plain; charset="iso-8859-1"<BR>
<BR>
My concern with "try https first" is it adds another required fetch for<BR>
each RP.<BR>
<BR>
--David<BR>
<BR>
________________________________<BR>
<BR>
From: yadis-bounces@lists.danga.com on behalf of David Strauss<BR>
Sent: Tue 6/27/2006 3:00 PM<BR>
To: Martin Atkins<BR>
Cc: yadis@lists.danga.com<BR>
Subject: Re: that ess in 'https'<BR>
<BR>
<BR>
<BR>
Martin Atkins wrote:<BR>
> David Strauss wrote:<BR>
> I think my favourite solution right now is to require relying parties<BR>
to<BR>
> support SSL and then use the existing "canonicalization through<BR>
> redirection" feature of OpenID to solve this problem. The problem that<BR>
> doesn't address is where an identity provider starts off on cleartext<BR>
> and migrates to SSL, which admittedly I don't have a good answer to.<BR>
<BR>
I don't like the redirection system because it still makes an insecure<BR>
hop. It would be more secure to try the https scheme first. I don't see<BR>
why people are resistant to this. The only restriction is that you can't<BR>
have different identities distinguished only by scheme.<BR>
<BR>
<BR>
<BR>
-------------- next part --------------<BR>
An HTML attachment was scrubbed...<BR>
URL:<BR>
<A HREF="http://lists.danga.com/pipermail/yadis/attachments/20060627/95004fc4/att">http://lists.danga.com/pipermail/yadis/attachments/20060627/95004fc4/att</A><BR>
achment.html<BR>
<BR>
------------------------------<BR>
<BR>
Message: 2<BR>
Date: Tue, 27 Jun 2006 16:29:30 -0700<BR>
From: "Recordon, David" <drecordon@verisign.com><BR>
Subject: RE: that ess in 'https'<BR>
To: "Dag Arneson" <dag@janrain.com>, <yadis@lists.danga.com><BR>
Cc: Martin Atkins <mart@degeneration.co.uk><BR>
Message-ID:<BR>
<BR>
<8A1A6155AA70064EBE4DC370E709147B91A342@MOU1WNEXMB11.vcorp.ad.vrsn.com><BR>
<BR>
Content-Type: text/plain; charset="iso-8859-1"<BR>
<BR>
I'd imagine LiveJournal would never be a compliant IdP then :-\ We<BR>
can't raise the bar too high for either an IdP or RP. I don't mind as<BR>
much for IdPs, but still want it to be fairly simple.<BR>
<BR>
--David<BR>
<BR>
________________________________<BR>
<BR>
From: yadis-bounces@lists.danga.com on behalf of Dag Arneson<BR>
Sent: Tue 6/27/2006 4:24 PM<BR>
To: yadis@lists.danga.com<BR>
Cc: Martin Atkins<BR>
Subject: Re: that ess in 'https'<BR>
<BR>
<BR>
<BR>
How about this scheme:<BR>
<BR>
Require IDPs to support serving both http and https ID URLs, with both<BR>
required to map to the same identity. But relying parties can choose<BR>
which to support, so RPs that do sensitive things will only support<BR>
https URLs, while PhpBBs and similar applications can use the less<BR>
secure http URL.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
-------------- next part --------------<BR>
An HTML attachment was scrubbed...<BR>
URL:<BR>
<A HREF="http://lists.danga.com/pipermail/yadis/attachments/20060627/476d6f2c/att">http://lists.danga.com/pipermail/yadis/attachments/20060627/476d6f2c/att</A><BR>
achment.htm<BR>
<BR>
------------------------------<BR>
<BR>
Message: 3<BR>
Date: Tue, 27 Jun 2006 16:41:23 -0700<BR>
From: Dag Arneson <dag@janrain.com><BR>
Subject: Re: that ess in 'https'<BR>
To: "Recordon, David" <drecordon@verisign.com><BR>
Cc: yadis@lists.danga.com<BR>
Message-ID: <44A1C223.9040909@janrain.com><BR>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR>
<BR>
I guess it's not strictly necessary for IDPs to be required to serve<BR>
https if they don't mind if their users cannot use their IDs for secure<BR>
openid sites.<BR>
<BR>
Recordon, David wrote:<BR>
> I'd imagine LiveJournal would never be a compliant IdP then :-\ We<BR>
> can't raise the bar too high for either an IdP or RP. I don't mind as<BR>
<BR>
> much for IdPs, but still want it to be fairly simple.<BR>
> <BR>
> --David<BR>
><BR>
><BR>
------------------------------------------------------------------------<BR>
> *From:* yadis-bounces@lists.danga.com on behalf of Dag Arneson<BR>
> *Sent:* Tue 6/27/2006 4:24 PM<BR>
> *To:* yadis@lists.danga.com<BR>
> *Cc:* Martin Atkins<BR>
> *Subject:* Re: that ess in 'https'<BR>
><BR>
> How about this scheme:<BR>
><BR>
> Require IDPs to support serving both http and https ID URLs, with both<BR>
> required to map to the same identity. But relying parties can choose<BR>
> which to support, so RPs that do sensitive things will only support<BR>
> https URLs, while PhpBBs and similar applications can use the less<BR>
> secure http URL.<BR>
><BR>
><BR>
><BR>
><BR>
<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 4<BR>
Date: Tue, 27 Jun 2006 20:52:11 -0500<BR>
From: David Strauss <mailinglists@fourkitchens.com><BR>
Subject: Re: that ess in 'https'<BR>
To: "Recordon, David" <drecordon@verisign.com><BR>
Cc: Martin Atkins <mart@degeneration.co.uk>, yadis@lists.danga.com<BR>
Message-ID: <44A1E0CB.1060402@fourkitchens.com><BR>
Content-Type: text/plain; charset=UTF-8<BR>
<BR>
1. If the https page exists, it's only one fetch.<BR>
2. The http redirect you suggest would result in two fetches for the<BR>
https case (granted, they'd be more automated because of the redirect)<BR>
and only one for the http case. This would optimize for the http case,<BR>
which I hope isn't the common one. We should "make the common case<BR>
fast," as the CS design rule goes.<BR>
3. Fetching http first allows an easier compromise of the system: all<BR>
the attacker needs to do is forge the http page so there's no redirect.<BR>
The "fetching https first" method would require blocking the https fetch<BR>
and forging the http page to be compromised. Granted, it's not much<BR>
harder.<BR>
4. The "fetch https first" method wouldn't break existing RPs. In fact,<BR>
I'd approach the method as a recommended practice more than a<BR>
requirement.<BR>
5. A redirect to the https page would break RPs that can't fetch https<BR>
pages. This may not be a problem if we begin requiring RPs to have<BR>
https-fetching capability.<BR>
<BR>
- David<BR>
<BR>
Recordon, David wrote:<BR>
> My concern with "try https first" is it adds another required fetch<BR>
for each RP.<BR>
> <BR>
> --David<BR>
><BR>
> ________________________________<BR>
><BR>
> From: yadis-bounces@lists.danga.com on behalf of David Strauss<BR>
> Sent: Tue 6/27/2006 3:00 PM<BR>
> To: Martin Atkins<BR>
> Cc: yadis@lists.danga.com<BR>
> Subject: Re: that ess in 'https'<BR>
><BR>
><BR>
><BR>
> Martin Atkins wrote:<BR>
>> David Strauss wrote:<BR>
>> I think my favourite solution right now is to require relying parties<BR>
to<BR>
>> support SSL and then use the existing "canonicalization through<BR>
>> redirection" feature of OpenID to solve this problem. The problem<BR>
that<BR>
>> doesn't address is where an identity provider starts off on cleartext<BR>
>> and migrates to SSL, which admittedly I don't have a good answer to.<BR>
><BR>
> I don't like the redirection system because it still makes an insecure<BR>
> hop. It would be more secure to try the https scheme first. I don't<BR>
see<BR>
> why people are resistant to this. The only restriction is that you<BR>
can't<BR>
> have different identities distinguished only by scheme.<BR>
><BR>
><BR>
><BR>
><BR>
<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
Message: 5<BR>
Date: Tue, 27 Jun 2006 21:08:15 -0500<BR>
From: David Strauss <mailinglists@fourkitchens.com><BR>
Subject: Re: that ess in 'https'<BR>
To: Dag Arneson <dag@janrain.com><BR>
Cc: yadis@lists.danga.com<BR>
Message-ID: <44A1E48F.3050809@fourkitchens.com><BR>
Content-Type: text/plain; charset=UTF-8<BR>
<BR>
Agreed. IdPs need not support SSL. Allowing people to delegate from<BR>
their blogs and homepages with $1.99/mo hosting pretty much makes<BR>
required SSL for identity pages impossible. (This is not to say RPs<BR>
can't voluntarily require it.)<BR>
<BR>
Skipping up a level in the thread, the only practice I'd like to truly<BR>
standardize is that identical canonicalized URLs, scheme aside, must map<BR>
to the same identity (if they map to an identity at all). This differs<BR>
from Dag's proposal only in that URLs are also allowed to not exist or<BR>
map to no identity.<BR>
<BR>
Adding this requirement would give RPs more freedom to choose a scheme<BR>
at their required security level. As far as I know, every existing IdP<BR>
is already compliant with this restriction.<BR>
<BR>
Also, this restriction would be helpful for RPs that require https<BR>
identity pages. Because users generally enter their OpenIDs without a<BR>
scheme and there's currently no guarantee that changing the scheme keeps<BR>
the same identity, RPs that require https cannot safely prepend <A HREF="https://">https://</A><BR>
without risking a connection to a different identity.<BR>
<BR>
- David<BR>
<BR>
Dag Arneson wrote:<BR>
> I guess it's not strictly necessary for IDPs to be required to serve<BR>
> https if they don't mind if their users cannot use their IDs for<BR>
secure<BR>
> openid sites.<BR>
><BR>
> Recordon, David wrote:<BR>
>> I'd imagine LiveJournal would never be a compliant IdP then :-\ We<BR>
>> can't raise the bar too high for either an IdP or RP. I don't mind<BR>
as<BR>
>> much for IdPs, but still want it to be fairly simple.<BR>
>> <BR>
>> --David<BR>
>><BR>
>><BR>
------------------------------------------------------------------------<BR>
>> *From:* yadis-bounces@lists.danga.com on behalf of Dag Arneson<BR>
>> *Sent:* Tue 6/27/2006 4:24 PM<BR>
>> *To:* yadis@lists.danga.com<BR>
>> *Cc:* Martin Atkins<BR>
>> *Subject:* Re: that ess in 'https'<BR>
>><BR>
>> How about this scheme:<BR>
>><BR>
>> Require IDPs to support serving both http and https ID URLs, with<BR>
both<BR>
>> required to map to the same identity. But relying parties can choose<BR>
>> which to support, so RPs that do sensitive things will only support<BR>
>> https URLs, while PhpBBs and similar applications can use the less<BR>
>> secure http URL.<BR>
>><BR>
>><BR>
>><BR>
>><BR>
><BR>
<BR>
<BR>
<BR>
------------------------------<BR>
<BR>
_______________________________________________<BR>
yadis mailing list<BR>
yadis@lists.danga.com<BR>
<A HREF="http://lists.danga.com/mailman/listinfo/yadis">http://lists.danga.com/mailman/listinfo/yadis</A><BR>
<BR>
<BR>
End of yadis Digest, Vol 14, Issue 23<BR>
*************************************<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>