[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [APPS-REVIEW] Fwd: Transition announcement: LC of wsc-ui
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,
public-usable-authentication at w3.org.
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 <tlr at w3.org>
On 2008-09-03 08:59:20 -0500, Vijay K. Gurbani wrote:
> From: "Vijay K. Gurbani" <vkg at alcatel-lucent.com>
> To: Lisa Dusseault <lisa at osafoundation.org>
> Cc: APPS-REVIEW at ietf.org
> 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 <vkg at 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
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg at {alcatel-lucent.com,bell-labs.com,acm.org}
> WWW: http://www.alcatel-lucent.com/bell-labs
> _______________________________________________
> APPS-REVIEW mailing list
> APPS-REVIEW at ietf.org
> https://www.ietf.org/mailman/listinfo/apps-review
>
>
_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW at ietf.org
https://www.ietf.org/mailman/listinfo/apps-review