W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: PKI signing of certs with SAN URIs : NVSI : openid domain procedures

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Sat, 30 Apr 2011 21:49:28 +0200
Message-ID: <BANLkTi=FYjbH9N6L_W1qvd_s6_-K=dixVQ@mail.gmail.com>
To: peter williams <home_pw@msn.com>
Cc: WebID Incubator Group WG <public-xg-webid@w3.org>
On 30 April 2011 21:30, peter williams <home_pw@msn.com> wrote:
> There is a procedural objection to webid that we will need to solve, if we
> truly wish CAs to be part of our adoption community. Its concerns the notion
> of “non–verified subscriber information”: NVSI.
>
>
>
> NVSI is a procedure in PKI/CA issuing of certs that enables a CA to stuff
> any old value in an “assured” cert, accompanying those identifiers/names and
> attributes that it has properly “confirmed” -  using the identity
> verification procedures of its assurance class. There is an extension that
> conveys such information, marked by definition to say: unverified. To use
> this field in one of the “standard assurance classes for certs”, only that
> field can store NVSI. You cannot put the same class of unverified
> information anywhere else, in certs whose issuers procedures conform to the
> higher assurance class. You cannot put it in the SAN_URI field, for example.
>
>
>
> What this means, unless CAs (operating at say class III assurance level)
> have a means of “verifying webid” that they CANNOT counter-sign the
> cert/request, and attach a classical cert chain to the certified key. They
> could put the value in the NVSI, however. This doesn’t help us, unless our
> protocol goes looking for URIs in the NVSI extension.
>
>
>
> Our work tends to oscillate between two public positions: (1) we exist to
> eliminate PKI, CA and cert formats like X.509, and cert chains based on
> public anchoring by well-known parties, (2) self-signed webid can be
> properly augmented with PKI signed certs and chains, issued by classical
> CAs.
>
>
>
> I think we have to get clearer which path we are going down. Ive talked to
> several CA firms, and the “brand” of webid is known in some cases for being
> “anti-CA” (the usual PGP rant), and on the other hand being pragmatically
> “CA-tolerant”. In the pragmatic case, SAN_URI means to the CA however, that
> it can NOT sign/issue a cert in the more useful higher assurance classes,
> since its NVSI).
>
>
>
> One way to solve this is to standardize two things in our community: that
> (a) CAs are more than welcome (we don’t exist to eliminate the whole
> industry), and (b) CA might use the “openid domain” type procedure to
> validate the data in SAN_URIs, so it can avoid being forced into the NVSI
> bucket.
>
>
>
> Openid domain procedures are an administrative method: you prove to the TTP
> you control an identifier, as an administrator, by posting a TTP-generated
> value communicated offline to the online claimed-identifier endpoint, within
> a certain timeframe. This shows you have write-access (and knowledge of the
> one-time value), and can/will respond in a timely fashion.

A couple of questions:

Is it possible for a trusted CA to assert that a certificate is tied to a WebID?

Can we become notaries or CAs ourselves and sign each others certs?

>
>
>
>
Received on Saturday, 30 April 2011 19:49:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:24 UTC