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

CAs policies don’t typically talk about assert'ing. Tpyically, notaries will
not "attest" to a name/key binding. The notary will confirm the identity
docs, and even allow the user to make a statement (my key is 0x1234...).
nbut the notary does not confirm 0x1234, let along the binding. Its an
"affidavit" of truth, "acknowledged" by the notary for having occurred, at
time T by person P, journaled at page 7 in book 32.

So "TTP-class" CAs in "policy-speak" talk about confirmation,
acknowledgement, and various other notions  found at law. They also talk
about verification and validation, concept that in the US law are reasonably
distinct procedures when "handling" records.

So, since most TTP-grade CAs just copy the VeriSign policy (being a profile
of the American Bar Association's generic model for such policies, which
provided the terminology or "terms of art" after much legal thought in
1990-1995 period), CAs do identity verification. Then they "issue" - much
like a birth certificate is "issued." The issuer is formally known as a
"registration authority" (in ISO speak). Issuing has more legal semantics
that mere registration (in ISO speak),  leading to notions of validity -
that required that the issued object is "confirmed" during "reliance" to
[still] exist in a legal repository - of which the notary's journal is a
classical type. The registry of land transfers is another... and so are
hundreds of other types of records management procedures, that result in a
"certificate" of this or that. The cert is just a copy of the registry
journal, in many formalisms. As we saw from the Obama birth cert affair
(designed to humiliate him as a black man, being forced through additional
hoops in rather traditional anti-black politiking), a given cert's validity
can change. This year the rules say this (instance's) form of the core
information is valid, and that one aint (even if its "more original" than
the current [partial] certified copy). Older  records which were ONCE valid
still exist of course, as historical/archived records. They are value-less
(except when being divisive).

So, CAs can do anything they like, during technical conformance to X.509.
Those that are aping VeriSign, are aping the above conception set. It's what
sets them apart as TTPs (invoking, projecting and inducing reliance on legal
assurances), distinct from those CAs that have a Microsoft cert server or an
openssl(1) tool chain and mint just any old crap, on demand. Of course, some
corporates operating a cert server operate it not as a TTP, but at least
"under security policy". These rules are often designed to support
inter-enterprise networking, sometimes called federation. Its great for
websso, for example.

Can an individual act according to the above scheme? Of course. A "public"
CA is just a business (generally), and a legal person, no different to me or
you. What makes one a TTP is that there is something about one's behavior
that is not-crap. Then, ideally, the not-crapiness projects, affirms and
binds to deliver a model that re-assures folks that its "in tune" with
public expecations, set by analogy with birth certs, land transfer docs, etc
etc. Often, financial assurance are an important part of this, since one
assumes the insurer is "being inspector", wanting not to underwrite huge
risks.

In PGP trust model, a different conception exists: trust is induced not
through public institution-ality-ness, but because  of a "I know thee and 4
persons down the line" chain (or, in GNU PGP land a metric that does
estimation about likelihoods...of such know-you chains being true)

What I'd like to see is a mixed world for webid - speaking as an experienced
designer. I'd love for identifier control confirmation (the basis of our
de-referencing) to NOT be based ONLY on foaf cards, but on self-signed certs
posted at the users endpoint. This allows semantics denied us today (since
Foaf cards cannot be signed, unlike self--signed certs). The IAN of that
cert would then point to the N foaf cards, one of which can be on the same
site as the .cer file - at which point semantic-web theories take over from
certs/crypto. If access control is based on the publickey fingerprint (not
the webid), then one implements what openid 1 HAD (past tense), which was
the ability to bind several IAN webids to the authorization algebra,
ensuring no one IDP gets too much control/power over user access to
resources, when the IDP boots the user (e.g. facebook, today, boot UK
activitists).

As webid matures in the next 4-5 months of this IX groups life, hopefully
lots of such "hybrid" models will be allowed, and encompassed. They are
"bridges" to the world of signed triple graphs, being bridges AVAILABLE
today, and thus then can offer an alternative to signed XRD files going
increasingly live in the Google world, in the Hammar stack.

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Melvin Carvalho
Sent: Saturday, April 30, 2011 12:49 PM
To: peter williams
Cc: WebID Incubator Group WG
Subject: Re: PKI signing of certs with SAN URIs : NVSI : openid domain
procedures

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 20:31:15 UTC