W3C home > Mailing lists > Public > public-bpwg@w3.org > October 2008

Re: mobile OK tests: HTTPS considerations (ACTION-841)

From: Francois Daoust <fd@w3.org>
Date: Wed, 15 Oct 2008 16:36:13 +0200
Message-ID: <48F5FFDD.6070205@w3.org>
To: Jo Rabin <jrabin@mtld.mobi>
CC: MWI BPWG Public <public-bpwg@w3.org>

+1 for this.


Jo Rabin wrote:
> 
> OK, after a little deliberation it seems that the clearest and neatest 
> answer is to create a new section to discuss HTTPS.
> 
> http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/
> 
> So the proposal is
> 
> a) remove from 2.4.3 HTTP Response
> 
> http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/#http_response
> 
> 
> Note:
> To allow for self-signature of certificates during testing the signatory
> of a certificate should not be checked.
> 
> and
> 
> If the response is an HTTPS response:
>     If the certificate is invalid, FAIL
>     If the certificate has expired, warn
> 
> b) Insert new section (before 2.4.2 HTTP Request)
> 
> 
> HTTPS
> 
> Note:
> 
> Arbitrary root certificates (including self-signed certificates) should
> be regarded as trusted.
> 
> 
> When resolving a URI, if the URI has the scheme https:
> 
>     If the certificate presented does not match the
> requested URI, FAIL.
> 
>     If the certificate has expired or is not yet valid, warn.
> 
>     If certificate validation otherwise fails, FAIL.
> 
> Jo
> 
> On 08/10/2008 16:26, Thomas Roessler wrote:
>> Hi Jo,
>>
>> sorry for the slow response. The text that you suggested sounds good. 
>> However, it appears like the dots in your proposal suggest that you 
>> want to continue expressing this piece of language in terms of the 
>> "HTTP response that results from an HTTPS Request", or some such.
>>
>> Unfortunately, the properties that you are checking here are *not* 
>> properties of any HTTP response:  They are properties of the TLS 
>> handshake that occurs before even an HTTP *request* is sent.  Please 
>> clarify this point.
>>
>> Thanks much,
>> -- 
>> Thomas Roessler, W3C  <tlr@w3.org>
>>
>>
>>
>>
>>
>>
>>
>> On 6 Oct 2008, at 12:55, Jo Rabin wrote:
>>
>>> Hello Thomas
>>>
>>> We're keen to push ahead with this edit and are wondering if the 
>>> WSC-WG has had the chance to look at the proposed change attached?
>>>
>>> Many thanks
>>> Jo
>>>
>>>
>>> On 25/09/2008 10:30, Jo Rabin wrote:
>>>> Hi Thomas
>>>> Thanks for your comment on behalf of the WSC-WG. We'd appreciate 
>>>> your further comments on our proposed text, as follows.
>>>> Many thanks
>>>> Jo
>>>> Under ACTION-841
>>>> WSC Proposal:
>>>> We propose that you update this criterion, at a minimum, as follows:
>>>> If the resource is accessed through HTTPS:
>>>>    If the certificate presented does not match the
>>>>         resource's URI, FAIL.
>>>>    If the certificate has expired or is not yet valid, warn.
>>>>    If certificate validation otherwise fails, FAIL.
>>>>        Checker SHOULD consider arbitrary root certificates (including
>>>>    self-signed certificates) as trusted for the purposes of
>>>>    mobileOK testing.
>>>> =====
>>>> Current Text:
>>>> Note:
>>>> To allow for self-signature of certificates during testing the 
>>>> signatory
>>>> of a certificate should not be checked.
>>>> ...
>>>> If the response is an HTTPS response:
>>>>    If the certificate is invalid, FAIL
>>>>    If the certificate has expired, warn
>>>> =====
>>>> Proposed replacement text:
>>>> Note:
>>>> Arbitrary root certificates (including self-signed certificates) should
>>>> be regarded as trusted.
>>>> ...
>>>> If the response is the result of a request for a URI which has the
>>>> scheme https:
>>>>    If the certificate presented does not match the
>>>>         requested URI, FAIL.
>>>>    If the certificate has expired or is not yet valid, warn.
>>>>    If certificate validation otherwise fails, FAIL.
>>>> On 29/08/2008 10:01, Thomas Roessler wrote:
>>>>> Hello,
>>>>>
>>>>> this is a post last call comment concerning the mobile OK basic
>>>>> tests 1.0, on behalf of the Web Security Context Working Group.
>>>>>
>>>>> We notice that section 2.4.3 - HTTP Response - uses the notion of an
>>>>> "HTTPS response".  There is no such thing.
>>>>>
>>>>> We also notice that the notion of an "invalid certificate" does not
>>>>> match what we understand to be the Best Practice Working Group's
>>>>> intention with this test.
>>>>>
>>>>> We propose that you update this criterion, at a minimum, as follows:
>>>>>
>>>>>  If the resource is accessed through HTTPS:          If the 
>>>>> certificate presented does not match the
>>>>>        resource's URI, FAIL.
>>>>>
>>>>>    If the certificate has expired or is not yet valid, warn.
>>>>>
>>>>>    If certificate validation otherwise fails, FAIL.
>>>>>
>>>>>    Checker SHOULD consider arbitrary root certificates (including
>>>>>    self-signed certificates) as trusted for the purposes of
>>>>>    mobileOK testing.
>>>>>
>>>>> Note that there are additional error conditions that can occur
>>>>> during TLS negotiation, including a mismatch on supported algorithms
>>>>> and protocol versions.
>>>>>
>>>>> Regards,
>>>
>>
> 
> 
Received on Wednesday, 15 October 2008 14:36:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC