Re: IETF Apps area review of wsc-ui ( LC-2088)

 Dear Vijay K. Gurbani ,

The Web Security Context Working Group has reviewed the comments you sent
[1] on the Last Call Working Draft [2] of the Web Security Context: User
Interface Guidelines published on 24 Jul 2008. Thank you for having taken
the time to review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-usable-authentication@w3.org if you agree with it or not before 28
January 2009. In case of disagreement, you are requested to provide a
specific solution for or a path to a consensus with the Working Group. If
such a consensus cannot be achieved, you will be given the opportunity to
raise a formal objection which will then be reviewed by the Director
during the transition of this document to the next stage in the W3C
Recommendation Track.

Thanks,

For the Web Security Context Working Group,
Thomas Roessler
W3C Staff Contact

 1. http://www.w3.org/mid/48BE9CAC.4080602@alcatel-lucent.com
 2. http://www.w3.org/TR/2008/WD-wsc-ui-20080724/


=====

Your comment on :
> 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


Working Group Resolution (LC-2088):
In our latest editor's draft we have:

- 5.1.2 nit fixed - thank you. 

- changed references from 3280 to 5280 

- on your 5.1.2. OOB/OID question - we've updated the text to clarify. 
The OID may be in addition to specifying which are AA via an out of band
mechanism. 

- on your 5.1.2 Subject field question - the subject must contain at least
an org to be considered an AA certificate. If the subject was empty, the
certificate would still be trusted, but not AA. 

- on 5.1.5 - 
We have decided not to specify how many times  site has to present the
same self-signed cert before being considered trusted. 

- 5.1.6 comment - we have removed the conformance language around
petnames, though have kept it in the security considerations section, and
added a better reference. 

- updated the 5.4.1 text to read: When certificate information is
presented in the interactions described in this section, then
human-readable information from certificates MUST NOT be presented as
trustworthy unless it is attested to. E.g., a self-signed certificate's
Common Name or Organization attribute must not be displayed, even if that
certificate is pinned to a destination.  Web user agents MAY display this
information in a dialog and other secondary chrome reachable from the
warning or error messages specified here.

- Updated the 6.1.1 text to read: 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), then it  MUST include an applicable DNS name that matches
either the  subject's Common Name attribute or its subjectAltName
extension.  User agents MAY shorten such a DNS name by displaying only a
suffix.

- Removed the trusted path section. 


----

Received on Wednesday, 21 January 2009 20:08:33 UTC