Lisa Dusseault wrote:
>> Although this is an external spec, it would be great to get a
>> couple of IETF reviewers. I'll send this to secdir as well.
[...]
>> The Web Security Context WG announces the publication transition of
>> Web Security Context: User Interface Guidelines.
>> Review ends on on September 15 2008.
All: I reviewed wsc-ui for the IETF APPS area; review is
attached. For any follow-ups, please CC me to the email
since I do not subscribe to the public-usable-authentication@w3.org
list. Thank you.
Review: Web Security Context: User Interface Guidelines,
W3C Working Draft 24 July 2008
Review date: Sept. 3, 2008
Due date: Sept. 15, 2008
Reviewer: Vijay K. Gurbani <vkg@bell-labs.com>
Global: At various places, the draft refers to RFC 3280. That
RFC is obsolete, having been replaced by RFC 5280.
Nit: In Section 5.1.2 second paragraph, second line, small typo:
s/document but/document, but/
The rest of the comments refer to specific sections. In crafting
my feedback below, I quote the specific text in the section first
by indenting two spaces, and follow that with the particular comment
I have on that text.
Section 5.1.2:
Web user agents MUST establish that a trust anchor is
[Definition: AA-qualified ] through some out of band mechanism
consistent with the relevant underlying augmented assurance
specification.
Marking a trust anchor as AA-qualified is a security-critical
step and most often will involve the use of some application-
specific out-of-band mechanism.
A couple of paragraphs before the above quoted paragraphs, it is stated
that a Web user agent may adequately trust a certificate if it is
specially marked using an OID, for instance. But yet the two paragraphs
quoted above appear to be making a case against that statement by
implying that a Web user agent MUST only trust a trust anchor using some
OOB means. So, which is it: an OOB means or a well-known OID?
Section 5.1.2:
If the certificate's Subject field does not have an
Organization attribute, then user agents MUST NOT consider the
certificate as an augmented assurance certificate, even if it
chains up to an AA-qualified trust root. User agents MAY
consider such a certificate as an ordinary validated certificate.
What happens if a certificate's Subject field is empty, but the
SubjectAltName extension is marked critical and the subject's
identity is specified in the SAN field? All things being equal
(i.e., an OID marks the certificate), would such a certificate be
considered trusted?
Section 5.1.5:
... Such behavior includes, e.g., warning users about changes of
certificates, and not showing warning messages if a site shows
a certificate consistent with previous visits.
Just curious: do we need to specify how many times the site has to
present the same self-signed cert before being considered trusted?
I think ssh asks for confirmation from the user on the first instance;
after that, connections to the same ssh server are deemed trusted.
Section 5.1.6: I have not used petnames, nor do I know much about their
usage in the context of this document, so treat the rest of this comment
as feedback tinged with curiosity from someone uninitiated with the
workings of W3C and unaware of how pervasive the petname concept is
in that domain (certainly, I do not think I have ran across a current
browser that uses petnames in its chrome.) Please treat this as a
pure comment and not anything that needs resolution.
It seems to me that the petname is a concept layered on top of the
information present in X.509 certificates. As such, it is a level of
abstraction above the X.509 certificate. Especially, the petname
implementor would have to account for wildcards, delegation, etc.
If care is not taken to write a good implementation, then security could
be -- I think -- compromised by someone modifying the contents of the
petname database, or by other means.
If any action item results from this comment at all, it would
be along one or more references on more information into the
petname concept, especially any papers that outline the threat
model of using such a concept. I Googled and ran across
http://www.w3.org/2005/Security/usability-ws/papers/02-hp-petname,
but that does not contain a threat analysis of this concept. It
does, however, explain very well the concept of a petname.
Section 5.4.1
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.
Suggest to clarify what "these interactions" means. Do you mean that
information derived only from self-signed certificates must not be
presented as trustworthy? Or do you mean that information derived from
certificate issued by a CA whose certificate path has been verified is
also untrustworthy? I think you mean the former, but a clarification
will help (as an example, the paragraph right after the one I quote
above makes it abundantly clear that "these interactions" consist of
deriving identity information from untrusted certificates.)
Section 6.1.1
o If the identity signal does not include any other human readable
information about the identity of the certificate subject
(derived, e.g., from an augmented assurance certificate or a
petname), then it MUST include an applicable DNS name retrieved
from the subject's Common Name attribute or from a
subjectAltName extension.
The PKIX WGs view is that DNS names should not appear in the CN
but rather in the SAN extension. That said, it is the case that
existing certificates in use today for web traffic do carry a
DNS name in the CN attribute. To future proof this specification,
you may want to indicate that if a DNS name is not found in the
SAN (or if the SAN is empty) and there is a DNS name in the CN,
then the DNS name from the CN must be used.
Another aspect to consider is what happens if there are multiple
identities in the SAN? Some may be email identities and other
DNS identities. Any guidance on what the implementation should
do when faced with multiple identities in SAN would be helpful.
As a start, implementations should look for a DNS identity in
the SAN that matches the URI used to reach that resource, keeping
in mind wildcard matching (since this is apparently allowed in HTTP.)
Section 7.1.1
A trusted path can be established between a web user agent
and the user through the use of a secret shared between the
user and the agent.
Here, do you mean that a trusted path can be established between a web
*server* and user? When I read "web user agent", I automatically
think of the browser; but the discussion in Section 7.1.1 appears
to pertain to a web server, especially with references to phishing.
Or am I missing something?
That's it.
Thanks,
- vijay