See also: IRC log
mez: nothing that needs discussion in the telecon
<Mez> http://www.w3.org/2006/WSC/track/actions/open
Mez: We will be looking at the
comments from Vijay of the IETF applications area.
... Want to do more with the Features at Risk over the next
couple of weeks.
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0019.html
Mez: Thanks to Lisa for
coordinating this feedback
... There's an RFC reference that needs to be corrected
TLR: on it!
Mez: There's an editorial comment in about the second paragraph
TLR: got that one too
<tlr> +1 to MEz
Mez: Vijay believes our
interpretation of the AA-qualified certificate fields is
incorrect
... Thought the use of the OID in the certificate was the
correct mechanism
TLR: thinks this might be an
issue with the clarity of the text
... will try to clarify
Mez: Looking at the question about the SAN field.
Yngve: There are requirements on what must be in these certificates
Mez: So we should specify that certificates that are missing required fields are not AA?
Yngve: Some close checking of the
specification is needed here
... Need to check into the exact contents of the
SubjectAltName
<tlr> ACTION: yngve to check EV expectations for subjectAltName [recorded in http://www.w3.org/2008/09/24-wsc-minutes.html#action02]
<trackbot> Created ACTION-517 - Check EV expectations for subjectAltName [on Yngve Pettersen - due 2008-10-01].
Mez: Moving on to the comment on
Section 5.1.5
... We didn't think we needed to specify a number of
visits.
... Anyone have other opinions?
... OK, so no we don't think we need to specify a number of
visits
... Moving on to section 5.1.6
TLR: Tyler has an ACTION here
tyler: Part of the response is the new petname rec text
Mez: Section 5.4.1
<Mez> http://www.w3.org/TR/wsc-ui/#sec-tlserrors
Mez: I think "these interactions"
refers to interactions resulting from a TLS error
... I think part of the confusion comes from ambiguity about
which certificates the comment is about
TLR: Yes, I think we need to
clarify the text here.
... thinking...
<Mez> When certificate information is presented in these interactions, human-readable information derived from the certificates in question (and any other certificates not trusted) MUST NOT be presented as trustworthy. Examples of such certificate information within those certificates not to be presented as trustworthy include Common Name or Organization attributes.
<tlr> ACTION: thomas to refine text above this action in the minutes [recorded in http://www.w3.org/2008/09/24-wsc-minutes.html#action03]
<trackbot> Created ACTION-518 - Refine text above this action in the minutes [on Thomas Roessler - due 2008-10-01].
Mez: Moving on to comment on Section 6.1.1
<Mez> http://www.w3.org/TR/wsc-ui/#identity-requirement
TLR: This is about IETF view that DNS names shouldn't be used in the CN field, although the Internet currently works that way.
<tlr> ... then it MUST include an applicable DNS name. The DNS name MUST be derived from a subjectAltName extension. If this extension is not present, and a DNS name is included with the certificate's Common Name attribute, then the latter MUST be used.
Yngve: Perhaps we should just reference the rules in HTTPS RFC, and so just say "according to the rules".
TLR: I fear it is actually
specified in 2817
... the TLS upgrade spec
<tlr> http://www.ietf.org/rfc/rfc2818.txt
<tlr> RFC 2818 section 3.1
Yngve: RFC 2818 is
informational
... its old
tyler: Think we don't want to reference any of the fields in the certificate, but use the hostname from the URL, as validated by the certificate. After all, there may be multiple hostnames in the certificate.
<tlr> *.w3.org -> w3.org if there's a wildcard?
rachna: What are we trying to
convey to the user?
... do we want the user to know there is a wildcard certificate
in use?
tlr: I am worried about a wildcard cert letting the attacker choose an arbitrary string to present to the user
tyler: Perhaps the base domain concept could be useful here.
tlr: Don't want to use that
here
... For example, phisher has cert for *.foo.com and puts up a
site at bankofamerica.foo.com
... Perhaps show the longest validated part of the
hostname.
... which would be similar to the base domain concept
<Mez> cutting off the asterisk is a little odd
<Mez> .foo.com and foo.com look pretty similiar
<Mez> in the former case it's a "good" match, in the latter, it's not
TLR: prefers string transform to the base domain algorithm which uses a separate database
<tlr> "E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com."
<tlr> (from 2818)
Yngve: Opera shows the wildcard value from the certificate.
TLR: Let's also look at how the other browsers are handling this
Yngve: discussing the particulars of wildcard matching in PKIX
<tlr> ACTION: thomas to solicit input on wildcard implementation [recorded in http://www.w3.org/2008/09/24-wsc-minutes.html#action04]
<trackbot> Created ACTION-519 - Solicit input on wildcard implementation [on Thomas Roessler - due 2008-10-01].
<tlr> ACTION: thomas to draft explanation of wildcard & scaling of attacks [recorded in http://www.w3.org/2008/09/24-wsc-minutes.html#action05]
<trackbot> Created ACTION-520 - Draft explanation of wildcard & scaling of attacks [on Thomas Roessler - due 2008-10-01].
<tlr> ISSUE: What information should be shown in the identity signal if no human readable information except for domain names is available? (6.1.1, LC-2088)
<trackbot> Created ISSUE-216 - What information should be shown in the identity signal if no human readable information except for domain names is available? (6.1.1, LC-2088) ; please complete additional details at http://www.w3.org/2006/WSC/track/issues/216/edit .
Mez: Moving on to Section 7.1.1
<Mez> http://www.w3.org/TR/wsc-ui/#sharedsecret-goodpractice
Mez: I thought this whole section
was about the user agent rather than the server. So am looking
for the place where Vijay found the text about the server
... Ah I see in section 7.1.1 we talk about a site spoofing the
browser
Yngve: Perhaps the first sentence should call out the motivation for having a trusted path.
<tlr> oooops, wasn't totally tuned in
<tlr> ACTION: mez to propose clarification for 7.1.1 [recorded in http://www.w3.org/2008/09/24-wsc-minutes.html#action06]
<trackbot> Created ACTION-521 - Propose clarification for 7.1.1 [on Mary Ellen Zurko - due 2008-10-01].
Mez: Give me an ACTION to propose
clearer text
... 6.1.1 looks like it requires the most thought, though the
petnames comments may also
... What are the next steps.
TLR: We're still reviewing the comments. Will need to draft a response eventually.
<tlr> http://lists.w3.org/Archives/Public/public-usable-authentication/2008Sep/