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

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 15:27:38 UTC