Re: [APPS-REVIEW] Fwd: Transition announcement: LC of wsc-ui

[Thomas Roessler <[e-mail]>]

Well, speaking with my W3C hat on, I'd appreciate if you could share
your review with the public comment list for that Working Group,
[e-mail].

I don't know, though, whether Lisa wants the review to go through
additional channels. ;-)

(I haven't yet read the comment in any detail.)

Thanks a lot,
-- 
Thomas Roessler, W3C  <[e-mail]>




On 2008-09-03 08:59:20 -0500, Vijay K. Gurbani wrote:
> From: "Vijay K. Gurbani" <[e-mail]>
> To: Lisa Dusseault <[e-mail]>
> Cc: [e-mail]
> Date: Wed, 03 Sep 2008 08:59:20 -0500
> Subject: Re: [APPS-REVIEW] Fwd: Transition announcement: LC of wsc-ui
> List-Id: Applications Review List <apps-review.ietf.org>
> X-Spam-Level: 
> Organization: Bell Labs Security Technology Research Group
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
> 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.
> 
> Lisa, Eric: I reviewed "Web Security Context: User Interface
> Guidelines, W3C Working Draft 24 July 2008" as requested.  Attached
> is the review.  I am not quite sure if I should also CC the
> editors of the above document or if the review should go through
> a liaison, etc.  Thus, I trust that you will forward it to the
> appropriate people.  If there is anything else I need to know,
> please do let me know.
> 
> 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 <[e-mail]>
> 
> 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
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://www.alcatel-lucent.com/bell-labs
> _______________________________________________
> APPS-REVIEW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-review
> 
> 

_______________________________________________
APPS-REVIEW mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-review