Re: Matter of DN and what's possible

On 9 Jan 2012, at 21:36, Kingsley Idehen wrote:

> It isn't: <mailto:kidehen@openlinksw.com> that determines access. It's: <mailto:kidehen@openlinksw.com>, public key components. The key is a composite i.e, the combination of two unique identifiers .

There are two possible situations here.

1. The relying party is unable to verify itself (and without specifically trusting the certificate issuer) that <mailto:kidehen@openlinksw.com> is actually an identifier for you — in which case, just use the public key material in your ACL: the one piece of information you have about the certificate-holder which you know is true (again, see threads passim). Paying any attention at all to the mailto: URI in this scenario just complicates things.

2. The relying party IS able to verify itself that <mailto:kidehen@openlinksw.com> is your identifier (WebFinger, FingerPoint, whatever) and you can use it (alone) to obtain data containing your key material, mirroring the claim from the certificate. In this case, the URI is behaving in effect no differently from an http/https URI pointing at some linked data, and can be used as-is — you can store the key material if you like, but you don’t need to for access-control.


> There are benefits to using alternative slots if the usage patterns adds complexity re. stuffing many URIs in SAN.
> 
> Again, negated the stuffing everything in SAN because I anticipated predictable "knee jerk" pushback. Why do you think I told Peter to hold fire re. use of SPARQL construct and a URL shortener? Because, I knew stuffing that in SAN wouldn't work with most verifiers, and ultimately it would be deemed to complex.

I long ago lost track of what you were telling Peter to do; it appeared to be an exercise in over-engineering.

> 
>>  What benefit does complicating the number of places a relying party needs to look when processing a certificate bring?
> 
> I can ask you the same question re. mutiple URIs in SAN when most don't still understand the Name/Address ambiguity problem associated with HTTP scheme URI based Names.

If there’s an ambiguity problem, how do you expect people to know which one to put where?


>>>> Who is “I”? The relying party?
>>> I make my cert. and save it locally.
>>> I publish the public key and WebID relation (from the cert I created and saved locally) to an idp space where I have Create, Read, Update, Delete privileges.
>> Um, yes, _you_ believe your _own_ claims. I would hope so (unless you knew you were lying). The point is what relying parties are meant to do.
> 
> Verify identity by leveraging fusion of PKI and the semantics that drive Trust Web Logics. Which is what WebID achieves.

That doesn't tell me anything. I've never heard of a “Trust Web Logics” before.

-- 
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

Received on Monday, 9 January 2012 22:13:25 UTC