[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] SimpleSign for estabilishing the authenticity of XRD.
Done a bit of research. If the language has a openssl support, then it is likely that it has an ability to parse the optional field. (It is a requirement of RFC3280 compliant client.) After a bit of thought, I thought using CN for CanonicalID is not a good idea. We just should use Subject (possibly in combination with issuer) as CanonicalID if it cannot be found in SubjectUniqueIdentifier (or other extension field) if the cert is RFC3280 compliant, because it is going to be unique over the time. So, taking openid.net cert as an example, it is going to be like: C=US/O=openid.net/OU=GT57216512/OU=See www.geotrust.com/resources/cps (c)08/OU=Domain Control Validated - QuickSSL(R)/CN=openid.net =nat Sakimura Nat wrote: > Hi Markus, > > Right. SubjectUniquieIdentifier is not very popular. I was going to check if it is easy enough to extract that in various languages, but I have not done that yet. On the other hand, as you point out, CN support is ubiquitous. We could use CN, but then, we have to be able to differentiate if that is the usual "domain name" or a "CanonicalID"/"Cool URI". Do you have any suggestion on this regard? > > For the canonicalization, I thought 2.1 would be nice, too, but then I was pointed out by Brian that it may not be as simple. (I have noted his point in italics on the wiki.) Perhaps could you demonstrate how it could be rather simple and would not cause headaches to developpers? > > =nat > > > > ________________________________________ > 差出人: markus.sabadello@gmail.com [markus.sabadello@gmail.com] は Markus Sabadello [markus.sabadello@xdi.org] の代理 > 送信日時: 2008年12月10日 23:23 > 宛先: Sakimura Nat > CC: XRI TC; Brian Eaton; Drummond Reed; jbradley@mac.com > 件名: Re: [xri] SimpleSign for estabilishing the authenticity of XRD. > > [Sorry for posting my reply twice - used wrong address before] > > Hi Nat, > > I have never heard of SubjectUniqueId, so I just googled it, and to me > it seems that field isn't very well known and not easy to work with.. > Not sure if all libraries support it? In contrast, everyone knows how > to use CN, so wouldn't that be a better choice? I understand that > SubjectUniqueId has extra semantics which CN doesn't have, but do we > really need that? > > As far as your Signature Method proposals are concerned, I think I > like 2.1 best. With a well designed RegExp I think this can be done > quite easily. > > Markus > > On Wed, Dec 10, 2008 at 9:08 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote: > >> This message never found any response. >> >> However, I think it is pretty improtant to consider, especially for XRI >> folks. >> >> I like file based signature. I started off from there. Then, I stumbled >> with the XRDS usecase, which cannot be done with this approach. That's >> why I came up with the simple canonicalization method based XRD SimpleSign. >> >> If we are to take this file based approach, we have to define how the >> signature will work for XRDS. >> >> Also, I would like to re-iterate that CanonicalID is not a usual domain >> name (= re-assignable.) >> It has to be a cool uri with fragments or i-number kind of ID that is >> guarantee not to be re-assigned to another entity by the relevant CA. >> >> It would not be stored in CN, I think. That is why I am using >> SubjectUniqueIdentifier field that was defined in X.509v.2. >> >> =nat >> >> Sakimura Nat wrote: >> >>> Hi. >>> >>> I have updated the SimpleSign. >>> Now it include an Overview section so that you can find out how this >>> SimpleSign establishes the authenticity of the XRD. By just inspecting >>> the XRD, one can estabilish its authenticity, using >>> SubjectUniqueIdentifier and CanonicalID. >>> >>> #Note: It is different that if one can Trust that entity. It just >>> establishes the authoritative-ness. >>> >>> Also, I have added another potential signature method. #2.4. >>> Problem of #2.3 (File signing) is that it cannot be applied for >>> sequences of XRDs (i.e., XRDS)except for the entire XRDS. #2.4 solves >>> this. In #2.4, the XRD is Base64 encoded and saved as an attribute of >>> XRD, and signature is applied on that string. Downside is that the XRD >>> become approximately 2.3 times bigger. >>> >>> =nat >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. Follow this link to all your TCs in OASIS at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>> >>> >> -- >> Nat Sakimura (=nat) >> Nomura Research Institute, Ltd. >> XDI.ORG Vice Chair >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]