Re: [Bug 22214] How long do permissions persist?

On 06/16/2014 12:23 AM, cowwoc wrote:
> On 14/06/2014 1:03 AM, Eric Rescorla wrote:
>> On Fri, Jun 13, 2014 at 5:10 PM, cowwoc <cowwoc@bbs.darktech.org 
>> <mailto:cowwoc@bbs.darktech.org>> wrote:
>>
>>     On 13/06/2014 12:47 PM, Martin Thomson wrote:
>>
>>         On 13 June 2014 07:08, cowwoc <cowwoc@bbs.darktech.org
>>         <mailto:cowwoc@bbs.darktech.org>> wrote:
>>
>>             I asked before but don't recall getting an answer: is the
>>             permission scope
>>             (for HTTPS) the same as the HTTPS certificate? Meaning,
>>             does it span
>>             multiple domains if the certificate does? Or is it for a
>>             single domain? Or
>>             is it unspecified?
>>
>>
>>         The grant is for the origin to which permission was granted.  The
>>         details of the certificate do not matter at this level.
>>
>>         If you have a wildcard for *.example.com
>>         <http://example.com>, that doesn't allow you to
>>         have https://foo.example.com use persistent permissions for
>>         https://www.example.com.  Nor would it allow
>>         https://www.example.com:9000 to use the same permissions.
>>
>>
>>     Okay. Are there any objections to granting permissions to a
>>     certificate instead of to a single domain? Meaning, instead of
>>     granting permission to google.com <http://google.com>, I'd grant
>>     permission to Google the company and implicitly to all domains
>>     and sub-domains covered by their certificate.
>>
>>     From a trust point of view, if I don't trust Google I wouldn't
>>     grant google.com <http://google.com> permission and on the flip
>>     side if I trust google.com <http://google.com> I don't see a
>>     reason not to trust google.ca <http://google.ca>.
>>
>>
>> Yes, I object to this. The origin is the basic concept in security here,
>> not the certificate and there are cases where distinct origins operated
>> by different people share a certificate.
>>
>> -Ekr
>
> I almost agree with you (given that same-origin policy is widespread) 
> but still:
>
> You are asking me to trust a certificate in order to grant permission 
> to an origin. If someone hijacks the certificate, isn't it trivial to 
> circumvent the same-origin policy? Meaning, what is the practical 
> benefit of trusting origin A but not B if both are operating under the 
> trust of certificate C? True, origin B could become malicious 
> independently of origin A, but the opposite could be just a likely.

C can speak truth or lie about the identity of A and B. So you 
implicitly trust C when you decide to trust A or B.

But under the theory of same-origin, A can't make you trust B, or the 
other way around.


>
> Is a user really in a better position to judge whether individual 
> origins are trustworthy than the certificate owner?

If we were to put in the standard that permission is granted to C and 
everyone he signs for, instead of to either A or B, we deny operators 
the ability to host two services with different levels of trust under 
the same certificate.

I don't think that's a good move.