RE: new WebID spec published

1. modulus While the written text of modulus was indeed changed, at least one graphic of a modulus was not. Take a look. its an easy oversight to  fix. If you cannot find it, dont worry. My advice is to note in the text that leading zeros are undesirable, so one gives direction to implementors. 2. want and need I dont know the provenance of WANT and NEED in the client cert context; its a not in a security curriculum (sounds more like sales techniques for business). I tried to hint that, with the quackery comment, it really doesn't belong. Here is something simple that gets one at least a C grade in a web e-commerce class: A support engineer for the IIS product writes, in http://support.microsoft.com/kb/907274 that "In IIS,		  you have the option of ignoring, accepting, or requiring client certificates		  when a user accesses resources on your server. Ignoring certificates simply		  means that you are not using them, will not ask the client for one, and will		  discard one if it is sent to your server. If you choose to accept certificates,		  your server will prompt for a certificate but will not necessarily deny access		  if a certificate is not provided. If you require client certificates, the user must supply		  a valid certificate or the user will receive an error message." That is based on the following, reading between the lines on the IIS design 9 which I know from personal experience harkens back to the work Microsoft engineers did on the PCT 1.0 design which spurred the design and specification of SSL v3. At http://www.lincoln.edu/math/rmyrick/ComputerNetworks/InetReference/ssl-draft/3-SPEC.HTM someone once wrote  "7.6.6 Client certificateThis is the first message the client can 
send after receiving a server hello done message. This message is only 
sent if the server requests a certificate. If no suitable certificate is 
available, the client should send a no certificate alert instead. This 
error is only a warning, however the server may respond with a fatal 
handshake failure alert if client authentication is required. " 3. HTTP error codes for client cert errors Writing further, the microsoft support engineer also notes how IIS abuses the spec (my criticism, built into my paraphrasing), by layering _apparent_ SSL handshake protocol signals into HTTP status codes. One can argue (as did the product manager when I challenged him a very long time ago) that these errors are not SSL errors. Rather, they are handling errors by the consumer of the SSL socket (i.e. IIS). Since they are not SSL errors, they do not need the error-centric protections provided for errors by proper use of the SSL record layer - remembering that error signals are a common means of making oracles (sophisticated cryptanalytical means of compromising security services, by undermining the strengh of cryptographic mechanisms or key). This is james bond stuff, rather beyond the remit of W3C research effort. Not all windows client side libraries consume those HTTP error  codes. Some do, though. So, it matters to implementors on Windows. (I've no idea if other server vendors copied Microsoft.) 4. Elimination of CAs If one reasons formally, the X.509-powered ciphersuites cannot be used without the notion of CA. Take the text "For a		  certificate to work properly, certain requirements must be met on		  both the server and the client. Each side has a list of root certification		  authorities that they trust. When the server prompts for a certificate, the request includes a		  list of the certification authorities that the server trusts. The client then compares this list to		  the list of certification authorities that the client trusts and creates a list of the ones		  that match."  If one is implementing the SSL v3 spec _faithfully_, these steps tell the implementor what to do. If there are no CAs in the system concept, one really cannot implement client certficates per the spec. Folks typically get around this, formally, by saying the user is a self-CA (but a CA he/she still is). We are different, in that there are no CAs that "issue" client certs. There is thus and can only be thus a formalists clash with the SSL v3 spec. As a security reader of the webid spec, I care about such matters (its my professional duty). I suspect Im the only one here who so cares, and who also comments openly. I can live with the contradiction between the security model of webid and the security model of SSL v3 for client certs - and I dont find the contradictions entirely inappropriate, as folks are balancing goals (nearly 2 decades after the original security model for client certs was conceived).  SSL v3 aimed at addressing e-commerce, and its biases towards bilateral trading agreements governing commerce. Webid does not so aim, in any reasonable comprehension of the opening statement.    From: henry.story@bblfish.net
Date: Thu, 24 Nov 2011 10:01:31 +0100
CC: public-xg-webid@w3.org
To: home_pw@msn.com
Subject: Re: new WebID spec published



Ok, I am happy to see that this list of issues is a lot shorter than the previous one. So there's progress.
I forgot to add the Change History, which means that I need to do a new release anyway. As it takes a bit of timeI will accept another round of fixes and overwrite the current version - if that is ok.

On 24 Nov 2011, at 03:25, Peter Williams wrote:I advise, as the incubator comes to a close: be clear what you are (and stop stating what you are not).
 
dont be known as that the group that hates CAs (while then relying on CAs to protect the document endpoints). its just sounds inconsistent, anti-capitalist, etc etc. 
 
Dont be thought of as something that is using the old digital ID concept. Its a spec that applies as much to PGP ciphersuites of https as much as those the Mozilla-centric ciphersuites (using X.509 blog formats and .p12 files for private keys and/or references).
 
Try NOT to use terminology that make it sound like a UCI-vintage system, given openid 1.0 and UCI essentially failed to get ANY traction from users. Decide if you want paypal on board, or not. Dont diss brands and commerce, if you are looking to the major cloud brands to adopt. Dont believe that wordpress will be bullied (presured), just becuase folks use horrid terminology on blog sites. The web has release the horrid side of humanity, remember.
 
Dont tied into the PGP web of trust. Be assertive and be stating that the linked data mesh is something refresingly new. The pgp model is old and tainted (and never broke out of its niche).
 
Stand up for the semantic web, as it matures with its new moniker: the linked data mesh. One has to move beyond Harry Halpins first impression (oh nO!, its the old RSS lot back in gear...refigthing old wars).
 
I note that opening 1000 words (non-normative) seems to be very political in prhasing, a bit like a politician using a few terms selective, know to be cues for particular voting communities. The result is a mongrel though. its will struggle for mind share, compared to those who have single minded conviction (e.g. the browserID folks). civilian security is a funny business, and needs particular marketing.
 
Remember, its supposed to be the result of an incubator, not a working group. Its supposed to be advanced research. If the eventual system that falls out looks more like the things that Kingsley is working on. DONT WORRY. the incubator succeeded. It created a market, and got a some core principles established. If it doesnt get all of them, let it go!
 
 
The text sends mixed messages, in its formalism. At times, its focussed on persons only, Then sometimes it admits its relevant to organizations, and then finally a webid definition starts talking about robots, and groups. perhaps give up on anything than Persons, this time around. Dont feel like one has to carve out space, lest it be lost later.  TLS is 15 years old, and still in active standardization....
 
The text still goes on about "Identification Certificate", from the previous attempt at formalism. Its not even defined. Just get rid of it. This spec is never going to have a rigorous security model. Its not why it one should be reading it, either. It has to say what the semantic web is doing (that CA trust networks and kerberos and websso do not).
 
The cert :hex arc in the picture has 00 leading bytes... (sigh). This is going to be the bane of this work, I supsect, since folks will do exactly what Henry did (probalby). view a cert, copy its modulus, which includes the 00 byte (which is significant, but only on cert land).

No, that was fixed, look again.
 
"information at that URI represents." typos.
 
I passed on the first time I got the hint, but its too obvious to do so the second time: "a TLS enabled protocol such as https in order to access a Protected Resource or a Protected Service." What does this mean? Does it mean I can use ftps? EAP-TLS?? SSLVPNs? The vagueness is making a point, and its hanging.
 
I really dont like the step 7's implication. The protocol as spec'ed really has nothing to say about linked data mesh, that MIGHT qualify the results of the validation protocol run in some kind of repuation sytsem. Its just confusing folks, who might nbelieve that the spec delivers such a method. It doesnt align (in spirit) with the bare bones text of 7: "a TLS enabled protocol such as https in order to access a Protected Resource or a Protected Service."
 
The material in 3.2.1 should just be removed. Specs dont refer to wikis. The material is all too political, too. Your average TLS expert will not know what is being alluded to.
 
3.2.2 make it sound like one is proposing an post-connection SSL setup regime (like the last one W3C specified, that got nowhere). Dont step in it... twice.
 
Note the prhase "Since WebID TLS authentication does not rely on CA's signing the certificate" note the politics. One is fomrally breaking with the CA/PKI community. This will make some of even this groups, very lurky technical experts nervous (as that community is rather powerful, in military systems). They tend to be quite manipative, and will happily message against standards that they see as contray to the national interest/policy, etc)
 
The NEED and WANT model is lacking. Its a bit of quackery, to be honest. Not trying to be insulting here. but recognize that TLS is hardly new, and terms are established.

yes, I asked you as a security specialist to tell us where that language came from, so that we can reference it.
 
3.2.4.1 makes RDFa processing mandatory (I think, at 99%). Someone needs to make sure RDFa parsers are are lot more widely implemented than today. It should not be e.g. me (a security type in an RDFa application group) that is struggling to parse an RDFa document in a system built using dotNet. If there are not 3 dotnet  and 4 java implementations, its seems strange to me mandating that a security app be using RDFa when, more mainstream and non-securitiy apps have yet to do so on those same platforms.
 
'Assuming the public key is an RSA key, and that its modulus is "9D79BFE2498..." and ' . The ASK query's mod does NOT align with 9D....
 
 
3.2.5 should make it clear that this spec does none of the things - that are howeever expected or envisaged (perhaps) in the "family of related specification".
 
3.3 goes back to the earlier formalism, about "identity crednetials", identification agents: , or some attempt at a formalisn model now discarded.
 
3.3.2 has a SHOULD (not a MUST) for the key and name. im scratching my head wondering what on earth could induce this not to be MUST. Im wondering if I'm somehow REALLY MISSING the point, somehow. The decisions seems to arbitary, in many ways.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
> From: henry.story@bblfish.net
> Date: Wed, 23 Nov 2011 22:01:16 +0100
> CC: foaf-protocols@lists.foaf-project.org
> To: public-xg-webid@w3.org
> Subject: new WebID spec published
> 
> Hi team,
> 
> so in the last week we have had a major rewrite of the spec, including new graphics,
> UML diagrams, change to ontology, etc... It is all up on 
> 
> http://www.w3.org/2005/Incubator/webid/spec/
> 
> There is a lot more to do of course, but I think this feels a lot more solid that the previous
> version.
> 
> Please send feedback,
> 
> Henry
> 
> Social Web Architect
> http://bblfish.net/
> 
>

Social Web Architect
http://bblfish.net/