RE: [foaf-protocols] possibly related

It's very traditional, CA-oriented stuff, focussed on best practice of communications security. It almost defines itself as being irrelevant to us, since
 
1. its notion of a URI in a cert is there ONLY to convey the URI's authority component - a domain-name
2. self-signed certs are out of scope, because they dont support CRLs and OCSP assume for best practices (not true... but what the hey!)
 
The offer a model, that is classical - in which an identity is asserted (they call it being "presented") and an identity must be verified by she who is relying upon the CA which "issued" the identity. its a classical offline TTP model, and is rather old hat. But, the document is attempting to represent old-hatness - being about best practices.
 
Overall, its assumption is that the relationship between CAs, the entities engaged in a handshake about identity, and the naming instructure need to be "regularized." the loosy-goosy model of https from 1994 is now hurting (they claim), and the formal DNS object model needs to properly adopted, so naming of services is properly projected through the certification apparatus to the identity apparatus used be online peers.
 
There is an interesting term called pinning that is webby - and is of interest to any formalist used to the philosophical ideas of identity, sense and reference.
 
If I guess, the document is heavily influenced by Microsoft, since ony they had the foresight to be addressing some of the harder interactions between DNS and name-certification, using their other-name name-form for orchestrating how domain-controllers supprot secure service-name resolution.
 
The notion of reference is tied to the praxis of "matching" - which ties the scheme very much to the logic of name-constraints, used in advanced X.509 path-based authentication. It is this that denies them any  value in self-signed certs, or URIs (like webids) that let the entities other than CAs/DNS (e.g. the web) define reference semantics.
 
The document is worth reading, to learn how PKIX and X.509 really work when treated professionally. So much of the general undersatnding is like certs 101, tied to PGP wars; and gave cert logics a bad name. Such is life in the world of competition!
 
In competition terms, there will be confusion over who gets to define what a URI means, when put in a cert  This group has already re-branded "URI" in certs to 'webid', and thus gets to controls the messaging of this term, so its reference semantics are those of the web architcture (not the "URI-ID" service-oriented DNS-based naming/certification world being promoted by the IETF WG/saint-andre/microsoft)
 
focussed on the world of SSL in SIP, there is elementary consideration of mappings and delegations - and these notions are built into the model. Once again, DNS is the mediator, and the security of delegation is offloaded to the authenticaiton logic of certs - based on the sequence naming/certification/revocation.
 
There is some mandatory-guidance on UI builders, limiting when pinning is "best practice". This is a fundamental attack on classical-https (dont offend the user, by knowing better than she  does in crypto-politics). They are standardizing when the user may show discretion, in an otherwise mandatory regime controlled by the certifier of the service name forms. This dogma is dressed up in a theory of "reference identifiers" focussed on the clients viewpoint on a to-be-verfied on a [server] "presented" identifier.
 
section 6.3 and 6.4 get very technical. Speed reading shows that it embodies the core logic of "matching". Its very "engineered", and very "refined". A lot of work has gone into this document. to be fair, it correctly addresses the world of the URI scheme and URI authority, fleshing out what the URI *used to* mean  before linked-data came along.
 
The SNI extension is mentioned. SNI is the extension in that allows the the client to fore-mention the virtual host name it expects the server to assume. This ties then into their logic of references identifies.
 
looking at the "respsects" list, its a list of the great and the good in IETF security area , and TLS WG in general.
 
Summary: it gets an A in security engineering class. In web engineering class, it gets a D becuase it doesnt address the topic. To be fair to the student, the paper was submitted for an engineering class...
 
 
 
 
 
 
 
 
 
 
 

 
> From: henry.story@bblfish.net
> Date: Tue, 25 Jan 2011 11:09:58 +0100
> To: nathan@webr3.org
> CC: public-xg-webid@w3.org; foaf-protocols@lists.foaf-project.org
> Subject: Re: [foaf-protocols] possibly related
> 
> Thanks Nathan for the interesting find. I am just perusing it quickly.
> Can you summarise what it is aiming to do?
> 
> Henry 
> 
> On 25 Jan 2011, at 05:08, Nathan wrote:
> 
> > http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14
> > _______________________________________________
> > foaf-protocols mailing list
> > foaf-protocols@lists.foaf-project.org
> > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> 
> Social Web Architect
> http://bblfish.net/
> 
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols