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

Thanks very much Thomas. We'll review the revised wording in the light 
of your comments.

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, 8 October 2008 17:00:27 UTC