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

RE: Authentication workflow draft.

From: peter williams <home_pw@msn.com>
Date: Tue, 12 Apr 2011 09:14:35 -0700
Message-ID: <SNT143-ds1447C89BC53413D240B94492AB0@phx.gbl>
To: "'Andrei Sambra'" <andrei@fcns.eu>, "'WebID XG'" <public-xg-webid@w3.org>

What's the point of step 4?

(a) It’s a self-signed certificate, in concept, so I can stick any date in, I want. Its self-asserted, and thus rather meaningless. This goes to the heart of another issue below (see extensions).

(b) there was no step to check the self-signature on the cert (or any signature on the cert). Do not assume TLS server implementations do in the SSL stream handling, during client authn!

In most cert designs, its up to local policy to decide whether or not elementary validation failure are to be treated as authentication failures; There is no standard policy on the topic. There is a comparison with a date offset locally, to see if the cert expiry is "beyond tolerance". Similarly, there is a policy that says: if cert is missing certain extensions (e.g. ClientAuthn) even in a critical extension, don't worry.

Step 6 says that all referenced URIs are resolved to a card, looking for any 1 that has any RSA public key. It doesn’t matter which one. Assuming async APIs, this test is satisfied by one card having any key. The first  card wins, it seems to assert ( even if it will turn out it has no pubkey matching the claim from SSL client authn.)

It seems to imply that if no card is found, that’s fine.

If the cert points to whitehouse.gov, one pints whitehouse.gov as a server. If the cert is presented a million times a day, and has 10 URIs to whitehouse.gov, one pings whitehouse.gov 10 million times a day (which may get the operator "a little visit").

Step 7 is ambiguous. I think its saying that one should first collect all RSA pubkeys from all files, build a local array of them, and then do query looking for a match against the input cert claim. Pulling one referenced card at a time (and finding a match) is NOT correct behavior. One must pull all resource, before attempting a match.

This is relevant to me, as it means for each URI in the SAN, I do a uriburner query, which (remotely) looks for a cert:identity match for 1 card at a time.

Can sparql have multiple FROM lines? Perhaps? Can the query be modified so Id know which URI matched, if one could specify multiple matches?

I note that it fails to discuss critical extensions, including key usage extensions. If the cert (self-signed even) has a critical extension called key usage that OMITS the digitalSignature bit, is the authentication valid?

There are n other extension questions, similarly. What is the party line? Is the webid validator supposed to enforce PKIX extensions? Is it supposed to enforce the ISO semantics of criticality? (guarantee to enforce the extension semantics correctly, or not process the cert at all).

Can I use a v1 format certificate (with no extensions, therefore)?

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Andrei Sambra
Sent: Tuesday, April 12, 2011 6:37 AM
To: WebID XG
Subject: Authentication workflow draft.

After a chat with Henry today, we decided to draft a "workflow" to describe how the authentication process takes place from the moment a user is accessing the service.

We are assuming the user possesses a client certificate which is installed in his browser, as well as a publicly accessible WebID on the web. The URI of the webid is found in the certificate's subjectAltName. 

Note: GOTO is used for the sake of simplicity and should not be generally used! :-)

Feel free to comment/add/change stuff if you consider it important.


Step 0. Init / no authentication / authentication failed (implementation

Step 1. The user connects to the authentication server (service) and is asked to provide a certificate. 

Step 2. The user selects the certificate and clicks the submit button.
If the user does not provide a certificate, GOTO Step 0.

Step 3. Using TLS, the server verifies that the public key found in the certificate matches the user's private key. If the keys do not match, (print an error maybe) GOTO Step 0.

Step 4. The server verifies the validity date of the certificate. If the certificate has expired, GOTO Step 0.

Step 5. The server extracts any URI found in the certificate's subjectAltName field, ignoring everything else (like email, etc.). If no URIs are found, (print an error maybe) GOTO Step 0.

Step 6. For each URI found, the server fetches and parses the profile file located at that particular URI, looking for resources pointing to a public key (i.e. rsa#RSAPublicKey?). If no resources are found, (print an error maybe) GOTO Step 0.

Step 7. If a public key resource is found, the server will try to check if the contents of "cert:identity" match the WebID's owner. If no match is found for any URI, then GOTO Step 0.

Step 8. If the identity matches the WebID, the server will try to match the WebID's modulus and exponent values to the ones provided by the user's certificate. It is possible to have multiple modulus values (belonging to several keys) therefore the server should cycle through all of them. If no match is found for any modulus/exponent of any URI, GOTO Step 0.

Step 9. If the modulus values match, the client is authenticated.


Received on Tuesday, 12 April 2011 16:15:04 UTC

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