Re: [xri] CanonicalID in XrdOne/TrustWorkflowByExample

[Nat Sakimura <n-sakimura@nri.co.jp>]

Hi Brian,

Brian Eaton wrote:
> On Wed, Dec 10, 2008 at 3:39 PM, Sakimura Nat <n-sakimura@nri.co.jp> wrote:
>   
>> Currently, in OpenID AuthN 2.0, it is the job of the OP to keep this string unique,
>> but it does not work with delegation nor the case when OP went out of business etc.
>> That's why I am proposing to move this task to CA.
>> It is a regular job of a CA to do this "identification" and keep record of it. Then, why not
>> levarage on it?  I think it is a reasonable thing to do.
>>     
>
> I don't think this is reasonable, because there is no way to get such
> a certificate today.  We can't build a spec on top of a certificate
> issuance infrastructure that does not exist.
>   
Not really. If the certificate is strictly RFC3280 compliant, then 
UniqueIdentifiers (Subject and Issuer) will be empty, and Subject will 
be guaranteed to be unique over time. So, we can use that instead. If 
there is a filled in UniqueIdentifier in the cert (I do not see many), 
then we should use that instead because it means Subject may be reused.

I am trying to find out how we can find out if the particular cert is 
RFC3280 compliant or not.
If anybody knows it, I will appreciate if you can point me to the 
information.

Also, I have got a feeling that if we spec it out, it will be supported 
by CAs.
(On the other hand, if we do not spec it out, it will never be.)

> OTOH, I did write a wiki page that mentioned "unspecified out of band
> key distribution", so maybe we need to refine that a bit.
>