[OpenID] general Digest, Vol 27, Issue 52

Thu Nov 13 18:13:44 UTC 2008

2008/11/13, general-request at openid.net <general-request at openid.net>:
> Send general mailing list submissions to
>        general at openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://openid.net/mailman/listinfo/general
> or, via email, send a message with subject or body 'help' to
>        general-request at openid.net
>
> You can reach the person managing the list at
>        general-owner at openid.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of general digest..."
>
>
> Today's Topics:
>
>   1. Re:  Random failures when validating signatures (Richard Davies)
>   2. Re:  Random failures when validating signatures
>      (Breno de Medeiros)
>   3. Re:  Random failures when validating signatures
>      (Breno de Medeiros)
>   4. Re:  [LIKELY_SPAM]Re:  OpenID SREG best practice question
>      (Peter Williams)
>   5.  text/plain; charset=ISO-8859-1 (ashraf nasr)
>   6.  text/plain; charset=ISO-8859-1 (ashraf nasr)
>   7. Re:  Random failures when validating signatures (Hans Granqvist)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Nov 2008 09:04:23 -0800 (PST)
> From: Richard Davies <richard at richarddavies.us>
> Subject: Re: [OpenID] Random failures when validating signatures
> To: general at openid.net
> Message-ID:
>        <24307280-f0ba-4e67-baea-c2c59cc9d7e3 at c22g2000prc.googlegroups.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I'm not sure... could you please elaborate on what I need to do in
> regards to handling signed types correctly. Thanks.
>
> On Nov 13, 8:50?am, Breno de Medeiros <br... at google.com> wrote:
> > Are you handling signed types correctly? This would cause a 50/50 error rate.
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 13 Nov 2008 09:08:47 -0800
> From: Breno de Medeiros <breno at google.com>
> Subject: Re: [OpenID] Random failures when validating signatures
> To: Richard Davies <richard at richarddavies.us>
> Cc: general at openid.net
> Message-ID:
>        <29fb00360811130908w4a1ecfcao5cf750c45695bea2 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> See
>
> ==quote
> 4.2.  Integer Representations
>
> Arbitrary precision integers MUST be encoded as big-endian signed
> two's complement binary strings. Henceforth, "btwoc" is a function
> that takes an arbitrary precision integer and returns its shortest
> big-endian two's complement representation. All integers that are used
> with Diffie-Hellman Key Exchange are positive. This means that the
> left-most bit of the two's complement representation MUST be zero. If
> it is not, implementations MUST add a zero byte at the front of the
> string.
> ==/quote
>
> This applies, for instance, to the nonce.
>
>
>
> On Thu, Nov 13, 2008 at 9:04 AM, Richard Davies
> <richard at richarddavies.us> wrote:
> > I'm not sure... could you please elaborate on what I need to do in
> > regards to handling signed types correctly. Thanks.
> >
> > On Nov 13, 8:50 am, Breno de Medeiros <br... at google.com> wrote:
> >> Are you handling signed types correctly? This would cause a 50/50 error rate.
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 13 Nov 2008 09:22:04 -0800
> From: Breno de Medeiros <breno at google.com>
> Subject: Re: [OpenID] Random failures when validating signatures
> To: Richard Davies <richard at richarddavies.us>
> Cc: general at openid.net
> Message-ID:
>        <29fb00360811130922h49bdaaaemebaaa02652f56739 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Nov 13, 2008 at 9:08 AM, Breno de Medeiros <breno at google.com> wrote:
> > See
> >
> > ==quote
> > 4.2.  Integer Representations
> >
> > Arbitrary precision integers MUST be encoded as big-endian signed
> > two's complement binary strings. Henceforth, "btwoc" is a function
> > that takes an arbitrary precision integer and returns its shortest
> > big-endian two's complement representation. All integers that are used
> > with Diffie-Hellman Key Exchange are positive. This means that the
> > left-most bit of the two's complement representation MUST be zero. If
> > it is not, implementations MUST add a zero byte at the front of the
> > string.
> > ==/quote
> >
> > This applies, for instance, to the nonce.
>
> Sorry, that is not true. It does not apply to the nonce, but it would
> cause you to interpret the "server_public" value incorrectly, and
> compute the wrong mac key 50% of the time.
>
> >
> >
> >
> > On Thu, Nov 13, 2008 at 9:04 AM, Richard Davies
> > <richard at richarddavies.us> wrote:
> >> I'm not sure... could you please elaborate on what I need to do in
> >> regards to handling signed types correctly. Thanks.
> >>
> >> On Nov 13, 8:50 am, Breno de Medeiros <br... at google.com> wrote:
> >>> Are you handling signed types correctly? This would cause a 50/50 error rate.
> >> _______________________________________________
> >> general mailing list
> >> general at openid.net
> >> http://openid.net/mailman/listinfo/general
> >>
> >
> >
> >
> > --
> > --Breno
> >
> > +1 (650) 214-1007 desk
> > +1 (408) 212-0135 (Grand Central)
> > MTV-41-3 : 383-A
> > PST (GMT-8) / PDT(GMT-7)
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 13 Nov 2008 09:22:00 -0800
> From: Peter Williams <pwilliams at rapattoni.com>
> Subject: Re: [OpenID] [LIKELY_SPAM]Re:  OpenID SREG best practice
>        question
> To: Nate Klingenstein <ndk at internet2.edu>
> Cc: OpenID General <general at openid.net>
> Message-ID:
>        <BFBC0F17A99938458360C863B716FE46397CC4F8E5 at simmbox01.rapnt.com>
> Content-Type: text/plain; charset="us-ascii"
>
> We do the same thing in US realty, essentially. Using a metadata standard (that has various forms, including csv and xml schema, and could easily dynamically spit out the RP's own XRDS too) each RP subscribes out-of-band to the attribute authority. It's like what SAML would do if its metadata for attribute contracts was more complete (and used). In our metadata, the data model is RDF like - with types and classes. Security Contracts are just oneobject to be searched for, like more typical data on members and listings.
>
> We now have several spokes that upon receiving the SAML post (or would-be openid assertion) then go and pull the membership attribute  relating to the primary key from the attribute authority. We have 1000 spokes who do the equivalent of the  SAML/OpenID using a variety of proprietary handoff techniques, mostly developed over the last 15 years of doing this sort of thing on the web. Some of the techniques are relics of the pre-web versions of the same flow, using authorized dialbacks!
>
> Of course this is just the classical SAML push then pull model. What we did a bit better was allow the RP metadata to be actually published in a repository with a common access method, so it ACTUALLY auto-configures the RP software (once the policy is set, and expressed). Change policy, software adjusts.
>
> The attribute authority is itself often a chaining and aggregation proxy, much like the X.500 directories chaining model. Now that RDF is getting mainstream and works in the core of SQL-server 2008, I can see us making our authorities perform dynamic collation of subordinate attribute authorities, quite soon, at high data rates.
>
> All we really need for openid is some XRDS extensions that describe the attribute contracts.
>
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Nate Klingenstein
> Sent: Thursday, November 13, 2008 7:53 AM
> To: Ben Laurie
> Cc: OpenID General
> Subject: [LIKELY_SPAM]Re: [OpenID] OpenID SREG best practice question
>
> Ben,
>
>
>
> Clearly as (if?) more attributes get added into the mix more thought
>
> will have to go into this aspect.
>
> We share and utilize a very large number of attributes, and many applications do need much more information than email address.  Some need less.  In our deployments, each service has the ability to express which attributes it needs.  See, for example, this page, and click on "Show requested attributes":
>
> http://www.switch.ch/de/aai/participants/allresources.html?show=all
>
> Then, the IdP administrator can choose to alter these defaults for their local userbase.  This has worked out great for these apps, but it's not a general solution (and doesn't help in your situation regardless).
>
> User-managed release of attributes was a key design tenet for us that has seen very little uptake in the real world.  We've tried interfaces that allowed users to individually select which attributes, building from a default set, they would like to block or enable the release of.
>
> 1)  It created a surge in help desk calls as well-meaning users locked themselves out of apps.
> 2)  Most users didn't care at all, and the ones who did care, didn't care on such fine granularity.
>
> We're now toying with interfaces that are opt-in/opt-out, and ones that can give "levels of service" based on how much information you're willing to reveal, e.g. persistent pseudonym = personalized content.  It gives the user the ability to do consent-based release for many services, and for services that are absolutely necessary to providing an education for the student, they won't be prompted.  We'll see if these are more successful.
>
> Something certainly has to be done, though.  We don't want the IdP administrator to be a gatekeeper for all services.  It works very well for the major apps with our large user bases, but it's not scaling down to the small collaborations.  I suspect this is why Eric is so keen to have some formal research into the problem.
>
> Take care,
> Nate.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://openid.net/pipermail/general/attachments/20081113/0bd51e68/attachment-0001.htm
>
> ------------------------------
>
> Message: 5
> Date: Thu, 13 Nov 2008 19:26:04 +0200
> From: "ashraf nasr" <srce.p123b at gmail.com>
> Subject: [OpenID] text/plain; charset=ISO-8859-1
> To: general at openid.net
> Message-ID:
>        <656821e40811130926q47e2380fy9ca9d70c0d105a83 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> text/plain; charset=ISO-8859-1
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 13 Nov 2008 19:27:07 +0200
> From: "ashraf nasr" <srce.p123b at gmail.com>
> Subject: [OpenID] text/plain; charset=ISO-8859-1
> To: general at openid.net
> Message-ID:
>        <656821e40811130927x69164aceld6d1a93345c31170 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> text/plain; charset=ISO-8859-1
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 13 Nov 2008 09:29:40 -0800
> From: "Hans Granqvist" <hans at granqvist.com>
> Subject: Re: [OpenID] Random failures when validating signatures
> To: "Breno de Medeiros" <breno at google.com>
> Cc: Richard Davies <richard at richarddavies.us>, general at openid.net
> Message-ID:
>        <c47f68be0811130929r1aab8ed6ka7d88875e4645007 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Compare to how Java's BigInteger adds a leading zero byte to make sure 2s
> complement form is always positive. Perhaps
> CF is similar?
>
> At any rate, this is a can o' worms. Perhaps this can be of value, or
> further
> cause confusion (even though it is an ASN.1 class, there is bit of
> explaining
> text + code related to this problem):
> https://svn.apache.org/repos/asf/incubator/tsik/trunk/src/org/apache/tsik/xmlsig/Asn1.java
>
>
> On Thu, Nov 13, 2008 at 9:22 AM, Breno de Medeiros <breno at google.com> wrote:
>
> On Thu, Nov 13, 2008 at 9:08 AM, Breno de Medeiros <breno at google.com> wrote:
> > > See
> > >
> > > ==quote
> > > 4.2.  Integer Representations
> > >
> > > Arbitrary precision integers MUST be encoded as big-endian signed
> > > two's complement binary strings. Henceforth, "btwoc" is a function
> > > that takes an arbitrary precision integer and returns its shortest
> > > big-endian two's complement representation. All integers that are used
> > > with Diffie-Hellman Key Exchange are positive. This means that the
> > > left-most bit of the two's complement representation MUST be zero. If
> > > it is not, implementations MUST add a zero byte at the front of the
> > > string.
> > > ==/quote
> > >
> > > This applies, for instance, to the nonce.
> >
> > Sorry, that is not true. It does not apply to the nonce, but it would
> > cause you to interpret the "server_public" value incorrectly, and
> > compute the wrong mac key 50% of the time.
> >
> > >
> > >
> > >
> > > On Thu, Nov 13, 2008 at 9:04 AM, Richard Davies
> > > <richard at richarddavies.us> wrote:
> > >> I'm not sure... could you please elaborate on what I need to do in
> > >> regards to handling signed types correctly. Thanks.
> > >>
> > >> On Nov 13, 8:50 am, Breno de Medeiros <br... at google.com> wrote:
> > >>> Are you handling signed types correctly? This would cause a 50/50 error
> > rate.
> > >> _______________________________________________
> > >> general mailing list
> > >> general at openid.net
> > >> http://openid.net/mailman/listinfo/general
> > >>
> > >
> > >
> > >
> > > --
> > > --Breno
> > >
> > > +1 (650) 214-1007 desk
> > > +1 (408) 212-0135 (Grand Central)
> > > MTV-41-3 : 383-A
> > > PST (GMT-8) / PDT(GMT-7)
> > >
> >
> >
> >
> > --
> > --Breno
> >
> > +1 (650) 214-1007 desk
> > +1 (408) 212-0135 (Grand Central)
> > MTV-41-3 : 383-A
> > PST (GMT-8) / PDT(GMT-7)
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://openid.net/pipermail/general/attachments/20081113/b648beda/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
> End of general Digest, Vol 27, Issue 52
> ***************************************
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.gif
Type: image/gif
Size: 10085 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081113/2bf04361/attachment-0002.gif>