- From: Francois Daoust <fd@w3.org>
- Date: Wed, 15 Oct 2008 16:36:13 +0200
- 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