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

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

From: peter williams <home_pw@msn.com>
Date: Sat, 30 Apr 2011 12:30:21 -0700
Message-ID: <SNT143-ds11A20EA28A22AC5F82E851929D0@phx.gbl>
To: "'WebID Incubator Group WG'" <public-xg-webid@w3.org>
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.

 

 
Received on Saturday, 30 April 2011 19:30:51 UTC

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