OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] [Libraries] Response to >> Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-12-17


Nika, that's great, we'll look forward to it.

Do take time for the holidays while you're at it ;-)

Best,

=Drummond

On Thu, Dec 17, 2009 at 5:06 PM, Nika Jones <njones@ouno.com> wrote:
In response to Libraries... I will update the PHP one I have this weekend
and give out the URL early next week.

Nika

> Following are the minutes of the unofficial telecon of the XRI TC at:
>
>
> Date:  Thursday, 17 December 2009 USA
> Time:  2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC)
>
> ATTENDING
>
> Will Norris
> Tatsuki Sakushima
> Breno de Medeiros
> RL "Bob" Morgan
> Scott Cantor
>
>
> 1) DISCUSS REVISIONS TO XRD COMMITTEE DRAFT 01 REVISION 01
>
> Will asked if there was any additional feedback on the Public Review wiki
> page... any responses that needed work, or any feedback that we missed
> including?
>
> http://wiki.oasis-open.org/xri/XrdOne/PublicReviewFeedback
>
> Breno noted that there was considerable discussion on the OpenID mailing
> list, particular around the <Subject> element, but agreed that what we
> have on the wiki encompassed all of the major points from that discussion.
>
>
> 2) TRUST PROFILES
>
> Breno mentioned that he has been working on drafting a trust profile for
> XRD and/or LRDD using X.509 certificates.  One of the particular
> challenges was whether this should be one document or multiple, and what
> the scope of each should be.  A document that only defines a trust profile
> for generic XRD documents doesn't cover the Host Meta use case, because
> Host Meta has no <Subject>.  Similarly, including Host Meta in a somewhat
> generic trust profile seems odd since it's not part of the core XRD spec.
>
> Will noted that he had always imagined that there would be at least two
> documents... one that defines what to do with generic XRDs, and then
> another for Host Meta that references the first, but explains what to do
> about <Subject>.
>
> (We then had a lengthy discussion about the approaches to XRD trust,
> mainly between Breno and Scott.  There are a few holes, but I think I
> captured most of it:)
>
>
> Scott: so you want to use TLS name matching rules for something that isn't
> TLS (which is fine).  If you want to do this, then you need to be very
> precise -- specify the OID you want, and where in the cert is should
> appear.  My suggestion is, unless you have a strong argument for doing it,
> you try and not rely on certificate extensions.  The SAML example is quite
> illustrative -- there is no extension that means you are allowed to sign
> SAML assertions. Different people will interpret the application of
> extensions differently.
>
> Scott: If you try to interpret the certificate semantically, I guarantee
> you will have interop problems.  The answer is that if you rely on
> commercial CA's, you're effectively misusing what those CA were designed
> to use.  If you take something intended for SSL (which is what CA's
> issue), those certs do not mean what you want them to mean (valid for
> signing XRD documents).  The CAs were not issuing the certs, and binding
> them to the names they bound them to, for the purposing you're describing.
>
> Breno: But CAs typically do not allow you to add arbitrary extensions.
>
> Scott: if you're trying to use the SSL infrastructure for your trust
> model, you should not sign the XRDs.  If you're relying on SSL, then
> actually rely on SSL.  I should host my XRD at a secure URL that can be
> plausibly bound to the subject.  Anything else is a misuse of SSL
> certificates.  When we use them in SAML, I'm okay with it because we have
> metadata that specifically says what they are intended to be used for.  I
> personally would be somewhat uncomfortable with the idea that I should
> trust a signature that was signed by a TLS certificate.  But to the extent
> that you do that, if you're going to use any extension at all, it would be
> the TLS server extension, which is a signing extension.
>
> Breno: what I've heard (but unable to confirm) is that some CAs will issue
> certificates with additional extensions that can be used both for TLS and
> for code signing.  I've not seen one of these yet.  But I would imagine
> that if such a certificate were issued, it would not be stretch to use the
> TLS name matching to verify the authority.
>
> Scott: It depends on what thread model you're trying to protect against
> (not using TLS loses the man in the middle protection).
>
> Scott: It's a slippery slope to try to define matching rules and extension
> requirements, if you stop there, but then try to leave the rest of the
> evaluation process undefined or loosely defined.  The reason I'm trying to
> abondone the use of PKI, is that no one wants to be precise in how to
> validate the certificate (do I use CRL, OCSP, what extensions, etc).
> Everyone just punts and says "it's up to the relying party" which doesn't
> help me as an implementor.
>
> Breno: there is still value in providing an interop layer.  Now we could
> just say PKI is complicated, there are all these issues (which there are).
>  But I don't know much of an alternative that would be simpler
>
> Scott: well there is a simpler requirement, but it doesn't meet the
> requirement of dynamic bootstrapping.  We (SAML) exchange trust data out
> of band.
>
> Breno: in practice you can get a long way with the dynamic bootstrapping
> of TLS
>
> Scott: but TLS just doesn't work. browser security today is useless except
> in the EV case.  One of the reasons for that is because CAs do not vet
> identity within organizations.  They only vet organizational identity.
>
> Scott: If you're going to write up a profile that uses PKI as the basis
> for its trust, I would argue for specificity.  If you don't and leave it
> undefined or loosely defined, then I have no idea what to actually
> implement.  I know that every library is buggy in different ways, and I
> don't know which bugs I should care about.  Which is an interop mess.  I
> would suggest we be as specific as possible with all the pieces that are
> mandatory for people to do.  Either was specifically say we ARE or ARE NOT
> expecting use of CRLs, etc.  That is what has led me to give up and just
> go in the other direction [with SAML].
>
> Scott: Everybody is doing this stuff with PKI, and the rest of us are
> avoiding it, because they are not being specific in what they mean by
> "PKI".  Now I just do what OpenSSL does, and point to them when there are
> bugs.  But meanwhile we're doing this other model where we DO control
> everything and know exactly what will work.
>
> Scott: In my experience, when your security requirements are low, they're
> usually zero.  I've not found any evidence that even a low security model
> is leading to any better security overall.
>
> (some discussion of DNS Sec that I missed)
>
> Breno: while you could certainly use self-signed certs and bring trust in
> from somewhere else.  But we also thought that using TLS provides some
> non-zero value.
>
> Scott: what is the advantage of having the XRD signed using TLS, rather
> than just using a protected endpoint to retrieve the XRD?
>
> Breno: XRD libraries will have less control over validating the trust of
> the XRD, because the transport layer will be handling TLS.  It's much more
> difficult to maintain that trust information throughout the process.
>
> Scott: If you're going to do a profile on the side of simplicity, if
> you're not going to go to such extents that you're likely to avoid all the
> PKI validation pitfalls.. I actually wouldn't go too far down the road of
> extensions.
>
> Breno: If you're going to be using TLS name matching, there is no point in
> requiring anything beyond a standard TLS certificate.  If we clarify the
> levels of assurance we're hoping to get with this profile (not incredibly
> high, but something comparable with browser security), and what the goals
> are, we can simplify this considerably.
>
> Scott: the other issue is that it's difficult to write a completely
> generic trust profile.  the threat models are specific to the use cases.
> the best thing to do is to be as limited as possible in the base profile,
> and let others lock it down for their specific use cases.
>
>
> 3) TESTING LIBRARIES
>
> Scott asked whether there were many libraries being written right now for
> this, and if any attempt had been made to do any interop testing.  Tatsuki
> mentioned he had a new XML canonicalization library in pure ruby, and Will
> noted that there was talk of a perl library on the webfinger list, though
> it was not clear if they were going to support signing.
>
> AI: Scott is going to gather existing XML canonicalization test cases so
> that we can test interop with the current and upcoming libraries
>
>
> 3) NEXT CALL
>
> We will be taking a break over the holidays, so the next call will be
> Thursday, January 7, 2010.
>
>
> ---------------------------------------------------------------------
> 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]