RE: How To Handle WebIDs for (X)HTML based Claim Bearing Resources

> > 1 URI based Name in the subjectAlternativeName slot implies 
> (semantically) that all the Names have the certificate's Subject as 
> their a co-referent .


 

Its actualy more formal. The (issuername,subjectname) is the co-referent of each one.


 

Alternatively, the (issuername,subjectkeyid) is the co-referent (as the subject Name can be empty, or null)

 
In each case, it got issuer name in it, so there is at least one fixed reference (based on crypto and one-way signatures)

 

To be honest, I think each are co-rfrerence with each other (too). but, there must be 1, from the v1 component of the cert.



This is where (formally) webid is non-conforming with even core X.509. To us, its just a blob, to be abused however modern open source code libs allow - so it comes down to a PGP class blob. IN general, and naturally after a 20 years, such code allows one to do anything, not enforcing any kind of formal typing limits youd find in higher assurance securty systems. 

 

After all, if you look at our ontology, the definition of cert in cert:key is defined on some pgp website (which kinda limits the formalism to the capabilties of 12 years olds). This kinda tells you where the head of the author is (denying any of the formality and semantics of ISO, or IETF). The hole is obvious (and telling).

 

I dont know whether this is henry-ego at work, W3C-ego (implicitely denying ISO or IETF), some free software foudation mission, a means to rehabilitate wikileaks, or a plot to kill of some post-Ceasar dictator and his male heirs to 3 generations

 

But, as a security engineer trained to enforce type theory as a core measure of delivering system integrity (and assurance), it puts webid in a particular bucket currently (the PGP bucket, or a perhaps the anonymous bucket that also contains PGP).

Received on Tuesday, 3 January 2012 19:32:48 UTC