[OpenID] Signing method for XRD

Thu Jun 11 15:31:56 UTC 2009

well lets follow your reasoning: signed xrd cites self-signed cert to RPs, where self-signed cert is component of the to-be-signed data set

In the US/Japan space, let's assume 10 mega-OPs and a millon captive RPs applications.

How do you propose the RPs learn to trust the 10 self-signed certs?

If we now go to a European model in which mega-OPs are only outsourcers to personal OPs (100 million say) each owning their own domains, trust models and association handles - where according to Santosh each personal OP has its own self-signed cert. How does your proposal scale? How do the RPs learn 100 million self-signed certs (without being spoofed, 1% of the time)?

my xrd (that you can resolve using any XRI Resolver using @blog*googlelock) already has a cert, which any RP can today process. I have to admit I dont know who issued it, who the subject is, and who might apply it: but it clearly exists. It could obiously easily be replaced by a(nother) self-signed cert.But why would would anyone apply it any more than the cert that evidently currently exists - whose provenance and trustworthiness is unknown,even now?
________________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Santosh Rajan [santrajan at gmail.com]
Sent: Wednesday, June 10, 2009 10:50 AM
To: general at openid.net
Subject: Re: [OpenID] Signing method for XRD

You mean self signed certs wont work in this scenario? In any case Ops using
https will probably not bother with this, unless paranoid I guess, in any
case they can afford it.

Peter Williams wrote:
>
> I wont argue that point.  But you evidently missed mine: that to determine
> the authenticity of the signature (on the blob of binary or otherwise),
> you must first authenticate the verification key.
>
> Xml-dsig makes various assumptions about the nature of the wider
> infrastructure involved in obtaining and validating the authenticity of
> verification keys. Those assumptions are embodied, as one might expect in
> a web standard trying to distinguish itself from the more traditional
> command and control concepts for key management, in the notions of
> reference and linkage. Being a catchall standard, several constructs for
> reference and linking of authenticated keying material are promoted.
>
>
> ________________________________________
> From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of
> Santosh Rajan [santrajan at gmail.com]
> Sent: Wednesday, June 10, 2009 10:18 AM
> To: general at openid.net
> Subject: Re: [OpenID] Signing method for XRD
>
> Once you digitally sign a document, though physically the document remains
> in tact and retains its content type, after the act of signing, it is
> really
> a frozen bunch of bits. And if you dont make that distinction you get into
> all sorts of tangles. And that was the mistake made by XMLDSig. In other
> words after signing the Content-Type should be binary, whatever you want
> to
> call it. After verification it takes up its original Content-Type.
>
>
> Peter Williams wrote:
>>
>>
>> my first reaction was ugh - xml-dsig has its own inband mechanism for
>> referencing keying material - and here is openid/xrd doing yet another
>> standard for verifying signatures and validating the supporting keying
>> material (probably poorly).
>>
>> My second reaction on reflection was that xml-dsig is rarely used to its
>> full potential. Its typically used as a PKCS7 signing and sealing
>> emulation modes, with an XML centric view of the world - with no
>> particular benefit. But, if xml dsig fully uses its external references,
>> and the references are to a world of XRD files which are TRUSTED to act
>> as
>> a key distribution mechanism, things get rather more interesting. In that
>> world, the XRD is becoming a certificate, as we know it - and one whose
>> format and semantics would enable it to go beyond the staid ol X.509 cert
>> chains and benefit the full expression power of xri queries and XRI
>> resolution.
>>
>> What the X.509 v3 format work took part (divorcing asymmetric key
>> management from dap/ldap resolution), XRI/XRD may be putting back
>> together: query-based named-key resolution supporting trust fabric
>> meshes.
>>
>>
>> -------
>>
>> eral-bounces at openid.net [general-bounces at openid.net] On Behalf Of Santosh
>> Rajan [santrajan at gmail.com]
>> Sent: Wednesday, June 10, 2009 2:07 AM
>> To: general at openid.net
>> Subject: Re: [OpenID] Signing method for XRD
>>
>> Looks Good to me. Just two questions.
>> 1) So this is XMLDSig
>> http://www.w3.org/TR/xmldsig-core/#def-SignatureDetached detached
>> signature
>> with no-canonicalization?
>> 2) The signature and certificate links are going to be in the attributes
>> of
>> <XRD> Element and will not be in separate <Link> elements?
>>
>>
>>
>> Nat Sakimura wrote:
>>>
>>> Hi all:
>>>
>>> At XRI TC of OASIS Open, we are talking about the signing method for
>>> XRD.
>>> The current trend in the TC is that to use a constrained form of XML
>>> DSig,
>>> which is found in the SAML Core spec. We are almost deciding on it,
>>> but I would like to hear from the community that if it would be OK.
>>>
>>> The reason I ask this was that when we started to discuss the
>>> signing method for XRD back in November last year, we were
>>> hearing from the community that XML DSig is too complex and
>>> hard to use by some developers. That's why we came up with
>>> "Simple Sign" which basically signes the blob without any
>>> cannonicalization.
>>>
>>> e.g.,
>>>
>>> <SXRD sig="signature"
>>> sigalg="http://www.w3.org/2000/09/xmldsig#rsa-sha1" certuri="pem file
>>> location" data="BASE64 of the payload" />
>>>
>>> Where:
>>>
>>>
>>>    - XRD/@data : Base64 encoded XRD to be signed.
>>>    - XRD/@sig : Signature taken over the original data (before Base64
>>>    encoding).
>>>    - XRD/@certuri: (Optional) Certificate location.Either XRD/@certuri
>>> or
>>>    XRD/@certs MUST be present.
>>>    - XRD/@certs : (Optional) The content of XRD/@certuri.If both
>>>    XRD/@certuri and XRD/@certs are present, XRD/@certs takes precidence.
>>>    - XRD/@sigalg : (Optional) Signature Algorithm. Defaults to rsa-sha1.
>>>
>>>
>>> When we started writing spec on such thing, we found that we are
>>> re-writing
>>> a lot of things that are already in XML DSig.
>>> As the result, XML DSig with new canonicalization
>>> method=no-canonicalization
>>> was discussed and in the end,
>>> it seems the discussion precipitated to "After all, constrained XML DSig
>>> would be good enough."
>>> Theoretically, it looks good.
>>>
>>> The remaining question is then the reality check, such as:
>>>
>>>    - Is it widely implementable, in each scripting language and hosting
>>>    environment including Google AppEngine, Force.com, etc.?
>>>    - Would the community feel that this is simple enough?
>>>
>>> I would appreciate your insight/opinion/input into this matter.
>>>
>>> Best,
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>
>>
>> -----
>>
>> Santosh Rajan
>> http://santrajan.blogspot.com http://santrajan.blogspot.com
>> --
>> View this message in context:
>> http://www.nabble.com/Signing-method-for-XRD-tp23956678p23957874.html
>> Sent from the OpenID - General mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
>
>
> -----
>
> Santosh Rajan
> http://santrajan.blogspot.com http://santrajan.blogspot.com
> --
> View this message in context:
> http://www.nabble.com/Signing-method-for-XRD-tp23956678p23966982.html
> Sent from the OpenID - General mailing list archive at Nabble.com.
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>

-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--
View this message in context: http://www.nabble.com/Signing-method-for-XRD-tp23956678p23967619.html
Sent from the OpenID - General mailing list archive at Nabble.com.

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general