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