W3C

Web Security Context Working Group Teleconference
02 Apr 2008

See also: IRC log

Attendees

Present

Regrets

Luis, B

Chair

Mary Ellen Zurko

Scribe

hal

Contents

· Topics

1.      approving minutes

2.      put out heartbeat of xit

3.      5.1.5 Self-signed Certificates and Untrusted Root Certificates

4.      5.4.1 TLS errors

· Summary of Action Items


 

 

<trackbot-ng> Date: 02 April 2008

<tlr> ScribeNick: hal

 

approving minutes

<Mez> http://www.w3.org/2008/03/26-wsc-minutes.html

resolution: minutes from March 26 approved

put out heartbeat of xit

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0193.html

<stephenF> go for it

<tlr> RESOLUTION: to publish current state of wsc-xit as a working draft

resolution: publish current draft of xit as a working draft to meet heartbeat requirement

tlr: should be ready by next week

 

5.1.5 Self-signed Certificates and Untrusted Root Certificates

<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#selfsignedcerts

mez: any comments?
... <reads text>

<stephenF> maybe s/UAs may offer pinning/UAs may support pinning/

tlr: real behavior defined elsewhere in document

stephenF: petnames are not mandatory, text should be consistent with that

<stephenF> tlr: where?

<johnath> ifette: http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#selfsignedcerts

<ifette> +1 to johnath

<tlr> stephen_F, http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors

tyler: time of pinning cert is also a good time to assign petname, text should say so
... why does it say only one site for pinned cert

tlr: it means that certs are pinned for one site at a time

<tlr> improved language welcome

<johnath> stephenF: would text like "A pinned self-signed certificate SHOULD be considered sufficient identification to allow user agents to associate a Petname with the site, if supported."

<stephenF> works for me

<ifette> works for me

<Zakim> stephenF, you wanted to suggest that we think about some text restricting SSC content a bit e.g. not for CN=www.*.com ?

jonathan: site mismatch comes under SSL errors
... perhaps we need wording about wildcards

tlr: in error part it covers primarily validated certs
... text about self signed does not deal with URL mismatch

stephenF: will take action to determine wording

mez: better to settle it on this call

<Mez> "A pinned self-signed certificate SHOULD be considered sufficient identification to allow user agents to associate a Petname with the site, if supported."

mez: that replaces current last line

<ifette> im fine with it

resolution: accept text with modification

 

5.4.1 TLS errors

<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors

<johnath> ACTION: asaldahan to update section 5.1.5. Replace last sentence with: "A pinned self-signed certificate SHOULD be considered sufficient identification to allow user agents to associate a Petname with the site, if supported." [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action01]

<trackbot-ng> Sorry, couldn't find user - asaldahan

<johnath> tlr: should that be "anil"?

<tlr> yes

<Zakim> stephenF, you wanted to ask why "SHOULD" there?

<johnath> ACTION: anil to update section 5.1.5. Replace last sentence with: "A pinned self-signed certificate SHOULD be considered sufficient identification to allow user agents to associate a Petname with the site, if supported." [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action02]

<trackbot-ng> Created ACTION-410 - Update section 5.1.5. Replace last sentence with: \"A pinned self-signed certificate SHOULD be considered sufficient identification to allow user agents to associate a Petname with the site, if supported.\" [on Anil Saldhana - due 2008-04-09].

ifette: may get multiple errors in sequence
... perhaps that is why it is SHOULD
... API may not make multiple errors visible

<stephenF> suggestion is: s/the most severe signalling level SHOULD be used/the most severe signalling level currently known MUST be used/

<tlr> +1 to stephen's suggestion

yngve: clarify "most severe level"
... what if a page includes content from different servers with different errors?
... what is behavior?

<Mez> If multiple error conditions apply, the most severe signalling level currently known MUST be used, as defined in 6.4 Error handling and signalling.

<Zakim> ifette, you wanted to answer yngve

ifette: if there is an untrustworthy cert don't want to prompt twice
... if they agree once that should be sufficient

jonathan: seems like implementation detail

<stephenF> +1 to that change

resolution: apply proposed change

<tlr> ACTION: anil to apply change about multiple error conditions [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action03]

<trackbot-ng> Created ACTION-411 - Apply change about multiple error conditions [on Anil Saldhana - due 2008-04-09].

<Mez> The requirements in this section do not require user agents to store information about past interactions longer than they otherwise would. Historical TLS information stored for the purposes of evaluating security relevant changes of behavior MAY be expunged from the user agent on the same schedule as other browsing history information. Historical TLS information MUST NOT be expunged prior to other browsing history information. For purposes of this requirement, browsi

ifette: have problem with storing history of info from every SSL host

mez: addresses your issue
... text later in section addresses your concern

ifette: may require you to fire off a lot of queries

tlr: question is whether it hurts perf more than regular SSL processing

<Zakim> stephenF, you wanted to ask where's the bit about pinning only after a "while" or is that gone?

yngve: database of that type could take a lot of space

stephenF: if I pin self signed cert, does that mean somebody can easily get me to pin a new cert
... for the same site

<stephenF> editorial suggestion: maybe switch the order of 1st two bullets

<tlr> +1

<stephenF> yep, the more like pseudo code the better

<bill-d> + 1

<tlr> -1 to "the more like pseudo code the better"

<ifette> +1 to pseudocode good

also number the bullets

<ifette> pseudocode less ambiguous, and easier to test

<Zakim> stephenF, you wanted to ask a thing

resolution: make indicated changes

<tlr> ACTION: anil to number bulleted list in 5.4.1, and while doing so, swap first two bullets. [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action04]

<trackbot-ng> Created ACTION-412 - Number bulleted list in 5.4.1, and while doing so, swap first two bullets. [on Anil Saldhana - due 2008-04-09].

stephenF: add warning that this could allow spoofing

<stephenF> maybe add this: "Note that this newly pinned certificate could be the basis for a spoofing attack, or it could represent a refresh of an SSC"

stephenF: insert after new second bullet

<tlr> I'd actually like to see this one in the security considerations

<stephenF> agree

<stephenF> agree (re-iterating)

tlr: put it in both places

<tlr> ACTION: anil to add stephenF's note re newly pinned certs to 5.4.1 and re-iterate it in security considerations section [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action05]

<trackbot-ng> Created ACTION-413 - Add stephenF's note re newly pinned certs to 5.4.1 and re-iterate it in security considerations section [on Anil Saldhana - due 2008-04-09].

<Zakim> stephenF, you wanted to ask if "presented as trustworthy" is well-defined?

<Mez> When certificate information is presented in these interactions, human-readable information derived from the certificates (e.g., Common Name or Organization attributes) in question MUST NOT be presented as trustworthy.

<stephenF> how about "MUST NOT be presented in the same way as identity information from an AAC"?

<Mez> or not the same as identity information in general, as cited in the spec

<stephenF> how about "MUST be presented as rubbish"?

<Mez> hahahahaha

tlr: don't want to present stuff that is unverified at all

<Zakim> ifette, you wanted to offer suggestion

ifette: why not say don't present the info?

tlr: what about diagnostic purposes?

<tlr> fine with me

<stephenF> I like what Ian said

<stephenF> "Don't display ASN.1"

<tlr> you never want to do that. ;

what about the pinning case?

tlr: yes, nothing in the cert is verified if you don't trust the root
... you really want to know the site you are going to

<tlr> FWIW, RFC 2818 is waffling around about URL checks. MUST check, but MAY not check.

<stephenF> and 2818 has wildcard ambiguities I think

ifettte: non match between URL and cert is a distinct error

<ifette> Web user agents MUST NOT display information from a self signed or untrusted certificate in a warning or error message. Web user agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.

<tlr> +1

<stephenF> maybe s/information/identity information/ (to allow e.g. saying "1024 rsa" or something)

<stephenF> otherwise +1, and I could live without my suggested change

<Mez> When certificate information is presented in these interactions, web user agents MUST NOT display information from a self signed or untrusted certificate in a warning or error message. Web user agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.

<johnath> heh - what tlr said

<stephenF> +1 to q-

<ifette> so in that case I still like my text as written, with stephen's modification

<ifette> Web user agents MUST NOT display identity information from a self signed or untrusted certificate in a warning or error message. Web user agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.

<Mez> 04 01When certificate information is presented in these interactions, web user agents MUST NOT display identity information from a self signed or untrusted certificate in a warning or error message. Web user agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.

<stephenF> I think I like that paragraph with global scope

<stephenF> fingerprint is derived-from, not part-of the cert

<tlr> I think I'm leaning toward the global scope, moving it to the end of 5.4.1.

<Zakim> ifette, you wanted to say i like it being more broad

<stephenF> there's a use-case where the DNS changed but the SSC wasn't renewed, corner-case though I guess

ifette: UA is not precluded from reporting other errors, i.e. cn/url mismatch

johathan: trying to say you can skip full processing and pin cert
... prevented from dealing with minor errors

<Mez> nowhere do we claim "cn" is identity

<stephenF> x.509 does

cn is found in Subject

or ALt subject

<ifette> i think the issue of offering to pin when the CN= doesn't match, I don't know if that's the same issue or a separate issue

<Mez> When certificate information is presented in these interactions, web user agents MUST NOT display identity information from a self signed or untrusted certificate in a warning or error message. Web user agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.

<ifette> had fun at 24c3? :-)

<johnath> yeah, I think I'm good with Mez's text too, the more I think about it

<ifette> +1 to mez's text

<tlr> that was at hack.lu

<stephenF> +1 as well

<tlr> http://log.does-not-exist.org/archives/2007/10/20/2144_hacklu_mitming_a_room_full_of_security_people.html

<stephenF> you could click through to get that info with the above text

<stephenF> abend ?

<stephenF> FWIW I think this is good and important text, so maybe we should revisit it next time to get it right if necessary

<Mez> I agree

<Mez> and we will, it won't be dropped

<Mez> one way or the other

<johnath> gotta go!

<Mez> ta

<stephenF> +1 to PHB's point, let's be nice to cheapskates/the cash-challenged

<stephenF> I'm sure I'll forget but I wanted to talk about "If certificate status checks are performed by a user agent, and a certificate is found to be outside its validity period, then the certificate MUST be considered revoked." next time

<tlr> stephenF, please send mail about that

<stephenF> bye so

Summary of Action Items

[NEW] ACTION: anil to add stephenF's note re newly pinned certs to 5.4.1 and re-iterate it in security considerations section [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action05]
[NEW] ACTION: anil to apply change about multiple error conditions [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action03]
[NEW] ACTION: anil to number bulleted list in 5.4.1, and while doing so, swap first two bullets. [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action04]
[NEW] ACTION: anil to update section 5.1.5. Replace last sentence with: "A pinned self-signed certificate SHOULD be considered sufficient identification to allow user agents to associate a Petname with the site, if supported." [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action02]
[NEW] ACTION: asaldahan to update section 5.1.5. Replace last sentence with: "A pinned self-signed certificate SHOULD be considered sufficient identification to allow user agents to associate a Petname with the site, if supported." [recorded in http://www.w3.org/2008/04/02-wsc-minutes.html#action01]
 
[End of minutes]


Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/04/17 09:43:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]

This is scribe.perl Revision: 1.133Â  of Date: 2008/01/18 18:48:51Â  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
 
Guessing input format: RRSAgent_Text_Format (score 1.00)
 
Succeeded: s/manditory/mandatory/
Succeeded: s/error/level/
Found ScribeNick: hal
Inferring Scribes: hal
 
WARNING: No "Present: ... " found!
Possibly Present: Bill_Doyle HP Hal_Lockhart IPcaller Maritza_Johnson MaryEllen_Zurko Mozilla P21 PHB ScribeNick Thomas aaaa aacc aadd aaee asaldahan asaldhan beltzner bill-d dans hal ifette ifettte johathan johnath joined jonathan jvkrey maritzaj mez stephenF tlr trackbot-ng tyler wsc yngve
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy
 
Regrets: Luis B
 
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
 
Found Date: 02 Apr 2008
Guessing minutes URL: http://www.w3.org/2008/04/02-wsc-minutes.html
People with action items: anil asaldahan
 

[End of scribe.perl diagnostic output]