W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2015

Re: Issue 378: `getRemoteCertificates()` is ill-defined

From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 9 Nov 2015 03:07:15 -0800
Message-ID: <CABcZeBO2oSROvHJ--4LnVNwFFJEXvg6P8Dk8bHAKXLKaOrwRng@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Sun, Nov 8, 2015 at 9:45 PM, Martin Thomson <martin.thomson@gmail.com>

> On 8 November 2015 at 15:42, Eric Rescorla <ekr@rtfm.com> wrote:
> >> The most typically suggested use of this method is to retrieve one or
> more
> >> certificates so as to be able to display information to the user.
> However,
> >> since it is up to the application what to do with the certificate(s),
> any
> >> information displayed to the user is potentially untrustworthy.   For
> >> example, chain validation is a browser, not an application
> responsibility.
> >
> >
> > Actually, I'm not sure it is a browser responsibility, since there are
> lots
> > (most) cases where the peer certificate is unverifiable. At minimum you
> > would need a "verified" bit.
> I would have thought that we would error out if the certificate didn't
> match the a=fingerprint line.


> And we're certainly not building a
> chain of any sort.

Yes, that was my point. However, as Cullen pointed out separately,
it's not impossible that the peer (typically a server) would have a valid
chain and that one might do something with that, e.g., display it as
an identity. See:

"  If the far endpoint was directly verified, either via a third-party
verifiable X.509 certificate or via a Web IdP mechanism (see Section 5.6
the "security characteristics" MUST include  the verified information.
X.509 identities and Web IdP   identities have similar semantics and should
be displayed in a         similar way."

Received on Monday, 9 November 2015 11:08:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:10 UTC