spec definitions, CAs, SSL handshake

 

 

1 "A Certificate is a document that affirms statements ... about a Subject such as its public key..."

 

No. a document cannot affirm anything, only a person can affirm. An Affirmation is a legally defined act. If you are trying to capture the notion of a rcord, then use the term. not all documents are records, however, as records require an intent for their to be an act of "registration", however minimal. Records trustworthiness is evaluated typically by accountants, or auditors, enforcing minimal levels of public trust for integrity and accuracy.

 

 

 

2 "A Certificate Authority is a Subject that signs Certificates.:

 

No typically, the Issuing Authority function (of a CA) signs certificates. IA is not a common notion, but captures the seperantess of the act of user authentication from the rest of a CAs duties (including signing). It also registers the certificate as a name in a name registry. yes, the certificate it itself a name, formally, under ISO definition of a registration authority. As a registered object, formal ISO-defined protocols govern the status of the object in the records repository.

 

No, typically a CA is a Person (often a juridical person, known as a Corporation) that affirms/attest/asserts/represents/acknolwedges (choose your legal tradition) one or more fact upon which another party is invited to _rely_, taking upon itself responsiblity for accuracy and the consequences of false reliance or acts of willful mis-representation.

 

 

 

3 "A TLS-Light Service is a standard TLS Service, except that it does not do CA Based Client Certificate Authentication".

 

this misreads the RFC on TLS. TLS is always indepedent of certs (expect for defining the X.509 and other cert blobs, as cert types). TLS RFC does NOT mandate PKIX, or X.509, and is perfectly happy for folks to use the PGP cipher suite, or the Kerberos cipher suite - which are given equal footing by IETF/IESG/IAB. This definition in superflous. If its its required, you have to add 3 more:

 

"A second TLS-Light Service is a standard TLS Service, except that it does not do PGP Based Authentication".


"A third TLS-Light Service is a standard TLS Service, except that it does not do kerberos Based Authentication".


"A third TLS-Light Service is a standard TLS Service, except that it does not do SRT Based Authentication".

 

you dont have to mention the several proprietary techniques folks use, with propreitary cert types (mostly military folks, using legacy mechanisms)

 

I recommend removing the bias, for that is what it appears to be.

 

 

4. on the topic of 3, if one wants to define a custom cipher suite, one can. This is how to do it professionally. It can say: use cipher suites X Y and Z, but dont verify the first cert's signature and dont the validate cert chain one didscovers for that first cert. 

 

The text FAILS to say what I think its trying to say: that the signature on the CertVerify message MUST verify using the public key of the first cert on the wire, even without having verified daid cert.

 

 

5 "WebID Verifier A WebID Verifier takes a WebID Certificate and verifies that the Subject of the Certificate is indeed identified by the Subject Alternative Name WebID published there."

 

This is poor. It saying that, nothing to do with the SSL protocol, one could take an arbitary cert, and do what it says above. This is not part of our scope. We do not need the concept of a webid verifier. What we needs is tp get back to what we had: a "webid validation agent" that proves facts about the SSL handshake in a webid security context, of which the cert blob is a part of the security enforcing function of the handshake protocol. Focussed on the certverify message, trying back to the mac over the certificate blog which links them together with integrity of the SSL handshake protocol (which is distinct from the record layer integrity mechanism recall), we want three facts confirmed: (1) certverify is consitent with hte handshake integrity, (2) cert is consistent with the certverify signature, (2) the SAN URI and the document reosurce found there binds the URI to the public key also published in the cert.

 

I dont expect a definition to capture all that. I do expect it not to undermine elementary properties of SSL, though. It looks crypto-amateurish, currently. Look Mom, Ive got a PGP key. Noone can see me cheating at my homework, now.

 

 

 

6 General

 

Now, I really dont expect an incubator spec to get CA or SSL theory wholly right. What I do expect is that it not biased (by structure) into someones personal mental model of how he would like the world to be distinct from how it actually is (when now CAs are to be diminished in role).

 

Try to decide if the spec is a nice bit of open source work, or something one wants a billion people to use next year.If you want the latter, you will need friends who you are not antagonizing. You will need to ensure CISCO get something out of it (by adding some hardware value, when inspecting the first 400 bytes of a TCP connection), the DNS folks understand their role, the auditors and accountants can formulate new criteria for trustworthiness, the insurers can fasion new actuarial data sets, etc etc.

 

Trty to decide if one wants to be openid 1 (that went nowhere, despite best efforts of the user centric community), or openid 2 (that is mostly about the hub and spoke world) running "system rules" governing multi-partite behaviour and conduct.

Received on Saturday, 31 December 2011 02:33:12 UTC