Re: [xri] Rewriten SimpleSign page

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

Brian Eaton wrote:
> Hi Nat -
>
> Thanks for writing that up.  I've got a few comments:
>   
You are very welcome.
> 1) The core XRD use cases do not require XRDS documents.  Shouldn't we
> defer specification/handling of XRDS to the XRI spec?  I don't feel
> particularly strongly on this, just seems like a way to simplify.
> What are the XRD applications that need XRDS?
>   
It could very well be. It really depends on what the XRI Resolution Team 
feel, though.
I am fine either way.
> 2) The canonical ID == subjectAltName rule is not going to work for
> most applications, for multiple reasons:
>     a) you can't buy those certs.
>     b) even if such certs did exist, they would make key rotation and
> reassignment impossible.
>     c) even if such certs did exist, the proposal would require
> purchasing a separate certificate for every single user of a site.
>
> Those are three deal-breaking obstacles to deployment.  I can't
> imagine anyone ever deploying that scenario on the open web.  It might
> get deployed in some more controlled/restricted environments, though
> the complexity of the model will be a problem even there.
>
> If there is consensus in the TC that we need both a canonicalID ==
> subjectAltName rule (section 3.2.1) and a DNS name rule (section
> 3.2.2), let's handle it by defining separate trust profiles
> (http://wiki.oasis-open.org/xri/XrdOne/TrustProfiles).  That way we
> can keep most of the security steps identical across deployments and
> code, with limited differences called out clearly.
>   
Exactly. There is a basic format for XRD. Then, there is an 
interpretation rules, which are profiles.
3.2.1 would be simpler to define and is likely to provide stronger cases 
legally. (For example,
at least in Japan, proxy signing is not legally accepted, though I am 
negotiating hard to change it.)

3.2.2 would involve more steps, but has much more adoption possibility, 
at least in the short term.
> The DNS name rule you've described is pretty close to the HTTP
> authority trust profile I wrote up earlier
> (http://wiki.oasis-open.org/xri/XrdOne/TrustProfileHttpAuthority).
> The canonicalID == subjectAltName rule would be a "cert per document"
> trust profile.
>   
Perhaps the handling of fragment and introduction of explicit Signing 
Authority (SignerID) is the only difference.
> 3) I have a preference for reusing the XML DSIG schema where we are
> redefining elements that have the exact same semantics.  For example,
> your XRD/Cert element has exactly the same semantics as
> ds:X509Certificate, but you've used slightly different syntax.  Rather
> than creating new syntax, we should just pull in the definitions we
> want from XML DSIG.  We won't be able to reuse much code, but we'll be
> able to reuse the thought they put into their definitions.
>   
In was debating inside myself.
Our assumption is that we do not have xmldsig processor.
Given this, the question to ask would be:

 1. which is more implementor friendly?
 2. would it not cause confusion?

I would go with the sentiment of the TC for this.
I put forward the non-ds syntax just to test the water level there.

For using XML Dsig syntax, we can go even further. Following is a 
modified version of the example XMLDsig
from the spec. ( http://www.w3.org/TR/xmldsig-core/#sec-o-Simple )

   [s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#";> 
   [s02]   <SignedInfo> 
   [s03]   <CanonicalizationMethod Algorithm="http://oasis-open.org/xri/xrd-simple-sign"/> 
   [s04]   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> 
   [s05]   <Reference URI="http://oasis-open.org/xri/xrd_1_0";> 
   [s06]     <Transforms> 
   [s07]       <Transform Algorithm="http://oasis-open.org/xri/xrd-simple-sign"/> 
   [s08]     </Transforms> 
   [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
   [s10]     <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK.../DigestValue> 
   [s11]   </Reference> 
   [s12] </SignedInfo> 
   [s13]   <SignatureURI>...</SignatureURI> 
   [s14]   <KeyInfo> 
   [s15a]    <KeyValue>
   [s15b]      <DSAKeyValue> 
   [s15c]        <P>...</P><Q>...</Q><G>...</G><Y>...</Y> 
   [s15d]      </DSAKeyValue> 
   [s15e]    </KeyValue> 
   [s16]   </KeyInfo> 
   [s17] </Signature>

In [s13] <SignatureURI> is used instead of <SignatureValue> and that 
will settle most of the issues.
Also, I have changed the Algorithm identifier and Reference since these 
are going to be defined here in this TC.
Then, we are almost home free.

However, it may look dawnting to those uninitialized to XMLDsig, though. 
What it is conveying is essentially equivalent to

 <Signature>...signature over the base64_decode(SDSIG/Data)</Signature>
 <CertURI>location of the pem file</CertURI>
 <Certs>pem representation of the certs</Certs>
 <SigAlg>http://www.w3.org/2000/09/xmldsig#rsa-sha1</SigAlg>

which "looks" much simpler. 

=nat


> Cheers,
> Brian
>
> On Thu, Dec 18, 2008 at 10:47 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:
>   
>> I have re-written the XrdOne/SimpleSign page to reflect the talks today.
>>
>> http://wiki.oasis-open.org/xri/XrdOne/SimpleSign
>>
>> Hope this is simple enough and close to an agreement.
>>
>> I have changed <SXRD> element name to <SDSIG> to generalize it.
>> Perhaps that's too much of a generalization though.
>> Also, instead of ds:KeyInfo, I have flattened things and defined
>> <CertURI>, <Certs>, <SigAlg>.
>>
>> We do not gain much by borrowing just ds:KeyInfo from XML Dsig.
>> If we have XML Dsig processor, we would be using XML Dsig after all.
>>
>> =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
>>
>>
>>