Subject: Re: [jose] xpo

From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Wed, 17 Oct 2012 01:24:29 -0700

+1

--
Vladimir Dzhuvinov : www.NimbusDS.com : [email-masked]

-------- Original Message --------
Subject: Re: [jose] xpo
From: Richard Barnes <[email-masked]>
Date: Wed, October 17, 2012 12:15 am
To: "Manger, James H" <[email-masked]>
Cc: Mike Jones <[email-masked]>, "[email-masked]"
<[email-masked]>

+1 

On Oct 16, 2012, at 6:55 PM, Manger, James H wrote:

>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06
>> • Changed the name of the JWK RSA exponent parameter from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an expiration parameter for keys. (The exp name is already used for this purpose in the JWT specification.)
> 
> "n" and "e" would be better than "mod" and "xpo".
> "n" and "e" are very widely used for the RSA modulus and public exponent.
> 
> s^e = m mod n
> 
> --
> James Manger
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Brian Campbell <[email-masked]>
Date: Wed, 17 Oct 2012 07:08:47 -0600

+1 (if a parameter name change is going to happen anyway)

On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS <
[email-masked]> wrote:

> >> • Changed the name of the JWK RSA exponent parameter from exp to xpo so
> as to allow the potential use of the name exp for a future extension that
> might define an expiration parameter for keys. (The exp name is already
> used for this purpose in the JWT specification.)
> >

---

From: <[email-masked]>
Date: Fri, 19 Oct 2012 08:49:40 +0200

I don't know why the exp in jwk needs to be changed. From a developer POW there is no need. You always know which "exp" is the right one.
I would reverse the change from exp to xpo. Developers don't need it and many did not update their implementation to incorporate the exp->xpo transition.

Actually I don't care (much) how the parameters are named. Although I would like to stick to the 3-letter scheme I am OK with the n,e proposal.
But please stop making breaking changes (especially renaming parameters which leads only to more work and no gain).

Case1: harm is already done -> stick with xpo and don't change AGAIN.
Case2: Most implementation haven't changed yet -> revert to exp
Case3: xpo is just stupid -> n,e is better -> another change -> Oh no -> revert to exp

Again: I suggest to revert to exp and make the implementers happy.

Axel

Cc'ing Nat because I don't want to give away his developer's emails without asking.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, October 17, 2012 3:09 PM
To: Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] xpo

+1 (if a parameter name change is going to happen anyway)
On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS <[email-masked]<mailto:[email-masked]>> wrote:
+1

--
Vladimir Dzhuvinov : www.NimbusDS.com<http://www.NimbusDS.com> : [email-masked]<mailto:[email-masked]>

-------- Original Message --------
Subject: Re: [jose] xpo
From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wed, October 17, 2012 12:15 am
To: "Manger, James H" <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>

+1

On Oct 16, 2012, at 6:55 PM, Manger, James H wrote:

>> * Changed the name of the JWK RSA exponent parameter from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an expiration parameter for keys. (The exp name is already used for this purpose in the JWT specification.)
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 19 Oct 2012 18:18:24 +1100

“exp” wouldn’t clash if we used some JSON structure in a JWK. For instance, separate the maths fields of the public key (n, e, …) from the administrative parts (key-id, certificate, usage…). Instead, JWK goes for a flat bucket for all a key’s info. Hence, we have potential problems with clashes of names from quite separate domains. We should fix the structure, instead of tinkering with the name.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, 19 October 2012 5:50 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] xpo

I don’t know why the exp in jwk needs to be changed. From a developer POW there is no need. You always know which “exp” is the right one.
I would reverse the change from exp to xpo. Developers don’t need it and many did not update their implementation to incorporate the exp->xpo transition.

Actually I don’t care (much) how the parameters are named. Although I would like to stick to the 3-letter scheme I am OK with the n,e proposal.
But please stop making breaking changes (especially renaming parameters which leads only to more work and no gain).

Case1: harm is already done -> stick with xpo and don’t change AGAIN.
Case2: Most implementation haven’t changed yet -> revert to exp
Case3: xpo is just stupid -> n,e is better -> another change -> Oh no -> revert to exp

Axel

Cc’ing Nat because I don’t want to give away his developer’s emails without asking.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, October 17, 2012 3:09 PM
To: Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] xpo

-------- Original Message --------
Subject: Re: [jose] xpo
From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wed, October 17, 2012 12:15 am
To: "Manger, James H" <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"

+1

---

From: <[email-masked]>
Date: Fri, 19 Oct 2012 11:46:52 +0200

Structure means “more bytes”. I guess that was the reason to go for xpo. (I cannot find the arguments on the mailing list)

I changed my mind: Although I don’t like xpo I think that instead of going back we should now live with xpo. Changing any implementation to understand xpo is not that much work.
And it is better to minimize breaking changes.

Axel

From: Manger, James H [mailto:[email-masked]]
Sent: Friday, October 19, 2012 9:18 AM
To: Nennker, Axel; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [jose] xpo

--
James Manger

Axel

-------- Original Message --------
Subject: Re: [jose] xpo
From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wed, October 17, 2012 12:15 am
To: "Manger, James H" <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"

+1

---

From: Michael Jones <[email-masked]>
Date: Mon, 22 Oct 2012 13:23:17 -0700

It seems the choice is between (mod, xpo) and (n, e).  A number of people have already expressed a preference for the latter.  What do others think? -- Mike
P.S.  I'm sending this message from this address because it bounced when I tried to send it from my regular e-mail address.  Please continue interacting with me at my regular e-mail address [email-masked]: [email-masked]
To: [email-masked]
Date: Fri, 19 Oct 2012 11:46:52 +0200
CC: [email-masked]
Subject: Re: [jose] xpo

Structure means “more bytes”. I guess that was the reason to go for xpo. (I cannot find the arguments on the mailing list) I changed my mind: Although I don’t like xpo I think that instead of going back we should now live with xpo. Changing any implementation to understand xpo is not that much work.And it is better to minimize breaking changes. Axel From: Manger, James H [mailto:[email-masked]] 
Sent: Friday, October 19, 2012 9:18 AM
To: Nennker, Axel; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [jose] xpo “exp” wouldn’t clash if we used some JSON structure in a JWK. For instance, separate the maths fields of the public key (n, e, …) from the administrative parts (key-id, certificate, usage…). Instead, JWK goes for a flat bucket for all a key’s info. Hence, we have potential problems with clashes of names from quite separate domains. We should fix the structure, instead of tinkering with the name. --James Manger From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, 19 October 2012 5:50 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] xpo I don’t know why the exp in jwk needs to be changed. From a developer POW there is no need. You always know which “exp” is the right one.I would reverse the change from exp to xpo. Developers don’t need it and many did not update their implementation to incorporate the exp->xpo transition. Actually I don’t care (much) how the parameters are named. Although I would like to stick to the 3-letter scheme I am OK with the n,e proposal.But please stop making breaking changes (especially renaming parameters which leads only to more work and no gain). Case1: harm is already done -> stick with xpo and don’t change AGAIN.Case2: Most implementation haven’t changed yet -> revert to expCase3: xpo is just stupid -> n,e is better -> another change -> Oh no -> revert to exp Again: I suggest to revert to exp and make the implementers happy. Axel Cc’ing Nat because I don’t want to give away his developer’s emails without asking.  From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, October 17, 2012 3:09 PM
To: Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] xpo +1 (if a parameter name change is going to happen anyway)On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS <[email-masked]> wrote:+1

-------- Original Message --------
Subject: Re: [jose] xpo
From: Richard Barnes <[email-masked]>
Date: Wed, October 17, 2012 12:15 am
To: "Manger, James H" <[email-masked]>
Cc: Mike Jones <[email-masked]>, "[email-masked]"
<[email-masked]>

+1

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2012 16:40:23 -0400

+1 for (n,e), with scoping to avoid conflict with other uses of those letters.

On Oct 22, 2012, at 4:23 PM, Michael Jones wrote:

> It seems the choice is between (mod, xpo) and (n, e).  A number of people have already expressed a preference for the latter.  What do others think?
>  
> -- Mike
> 
> P.S.  I'm sending this message from this address because it bounced when I tried to send it from my regular e-mail address.  Please continue interacting with me at my regular e-mail [email-masked].
> From: [email-masked]
> On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS <[email-masked]> wrote:
> +1
> 
> --
> _______________________________________________ jose mailing list [email-masked] https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Sun, 21 Oct 2012 04:57:27 +0000

-- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, October 19, 2012 2:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [jose] xpo

Axel

From: Manger, James H [mailto:[email-masked]]
Sent: Friday, October 19, 2012 9:18 AM
To: Nennker, Axel; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] xpo

--
James Manger

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, 19 October 2012 5:50 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] xpo

Axel

-------- Original Message --------
Subject: Re: [jose] xpo
From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wed, October 17, 2012 12:15 am
To: "Manger, James H" <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"

+1

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2012 16:51:33 -0400

> “exp” wouldn’t clash if we used some JSON structure in a JWK. For instance, separate the maths fields of the public key (n, e, …) from the administrative parts (key-id, certificate, usage…). Instea…

Yes.  This.  

Most of this WG's problems arise from using flat buckets.  Flat buckets don't hold water :)

--Richard

---

From: <[email-masked]>
Date: Mon, 22 Oct 2012 23:36:45 +0200

We are talking about two specs here, right?
https://tools.ietf.org/html/draft-ietf-jose-json-web-key
https://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms

There are "general" jwk parameters
alg, use, kid,
and algorithm specific parameters.
x,y,n,e

If two parties use a new (or old but non standard) alg with new parameter abc and cde then we would break that implementation if we later define abc or cde as top level fields.
Do we care about this or do we discourage this use case by potentially breaking them? (breaking is a feature from a security and standards pow?)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Jones
Sent: Monday, October 22, 2012 10:23 PM
To: [email-masked]
Subject: Re: [jose] xpo

-- Mike

P.S.  I'm sending this message from this address because it bounced when I tried to send it from my regular e-mail address.  Please continue interacting with me at my regular e-mail address [email-masked]<mailto:[email-masked]>.
________________________________
From: [email-masked]
To: [email-masked]
Date: Fri, 19 Oct 2012 11:46:52 +0200
CC: [email-masked]
Subject: Re: [jose] xpo
Structure means "more bytes". I guess that was the reason to go for xpo. (I cannot find the arguments on the mailing list)

I changed my mind: Although I don't like xpo I think that instead of going back we should now live with xpo. Changing any implementation to understand xpo is not that much work.
And it is better to minimize breaking changes.

Axel

"exp" wouldn't clash if we used some JSON structure in a JWK. For instance, separate the maths fields of the public key (n, e, ...) from the administrative parts (key-id, certificate, usage...). Instead, JWK goes for a flat bucket for all a key's info. Hence, we have potential problems with clashes of names from quite separate domains. We should fix the structure, instead of tinkering with the name.

--
James Manger

Axel

-------- Original Message --------
Subject: Re: [jose] xpo
From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wed, October 17, 2012 12:15 am
To: "Manger, James H" <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"

+1

_______________________________________________ jose mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Tue, 23 Oct 2012 08:32:38 +0000

Scoping would make sense if we anticipated there being many many key parameters in the future, such that future naming conflicts were likely.  In practice, there are all of eight key parameters defined at present ("alg", "crv", "x", "y", "mod", "xpo", "use", and "kid").  I've heard discussions of maybe one or two more that people might anticipate adding in the future (expiration time is the only one I can remember off the top of my head).  So at least within the next few years, the number might reach a dozen or so.  And we already have a registry defined that would avoid parameter conflicts.

Adding structure to avoid potential conflicts among at most a dozen or so parameter names seems like significant overkill.  In the spirit of keeping simple things simple, in practice, I'm sure that a flat structure will continue to work out just fine.

				Cheers,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Monday, October 22, 2012 1:52 PM
To: Manger, James H
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] xpo

Yes.  This.  

--Richard

---

From: Dirkjan Ochtman <[email-masked]>
Date: Tue, 23 Oct 2012 10:41:58 +0200

On Mon, Oct 22, 2012 at 10:23 PM, Michael Jones
<[email-masked]> wrote:
> It seems the choice is between (mod, xpo) and (n, e).  A number of people
> have already expressed a preference for the latter.  What do others think?

I recently implemented partial support for JWS/JWA/JWK in order to
write an identity provider for Mozilla Persona, and the usage of (n,
e) in their preliminary spec (based on an older draft of the JOSE
specs, IIUC) made it very easy to correlate those parameters to the
documentation for my cryptographic library. So +1 from me for (n, e).

Cheers,

Dirkjan

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 24 Oct 2012 10:47:44 +1100

Mike is right that with only a handful or so parameters we could muddle through with a flat structure. The fact that we have already had a clash ("exp") is annoying, and not a good sign about the flat structure, but we could muddle through anyway. A parameter registry is supposed to help.

But there are already other problems...
JWK [section 4. "JSON Web Key (JWK) Format"; section 6.1.1. "Registration Template"] says parameters should be registered; says different kinds of key can use the same parameter name for kind-specific parameters; and establishes a registry that assumes parameter names are unambiguous. Those three points cannot all work together.

For instance, an elliptic curve key can use "y" for the x-coordinate of a point; while a 
DSA key could use "y" for the public key (an integer). What goes in the registry?

The "exp" clash theoretically isn’t a clash anyway, since the JWK parameter registry is *separate* from the JWE/JWS header parameter registry. Of course we don't want different names for the same sort of metadata in JWS & JWK -- that would be annoying. This suggests we have arranged the registries incorrectly.

You can also see this issue in JWE & JWS. They share a common registry: "JSON Web Signature and Encryption header Parameters Registry" [JWS section 7.1]. JWS puts "kid" in this registry, pointing to JWS section 4.1.7. where it is defined as an identifier for the originator's key. JWE puts the same name "kid" in the same registry, but points it to JWE section 4.1.10. where it is defined as an identifier for the recipient's key. Ugh? What will go in the registry? What happens when an originator and recipient key are both involved?

Perhaps this mess can be sorted out by putting more care into which registries are defined and what details go into them. Perhaps a parameter registry that is common for JWE/JWS/JWK, but allows names to be registered that (instead of pointing to one definition for the parameter) mark that parameter as dependant on the value of, say, the "alg" value in the same context?

Actually, this sounds more complex than just using some structure in the messages.

--
James Manger

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mike Jones
> Sent: Tuesday, 23 October 2012 7:33 PM
> To: [email-masked]
> Subject: Re: [jose] xpo
> 
> Scoping would make sense if we anticipated there being many many key
> parameters in the future, such that future naming conflicts were
> likely.  In practice, there are all of eight key parameters defined at
> present ("alg", "crv", "x", "y", "mod", "xpo", "use", and "kid").  I've
> heard discussions of maybe one or two more that people might anticipate
> adding in the future (expiration time is the only one I can remember
> off the top of my head).  So at least within the next few years, the
> number might reach a dozen or so.  And we already have a registry
> defined that would avoid parameter conflicts.
> 
> Adding structure to avoid potential conflicts among at most a dozen or
> so parameter names seems like significant overkill.  In the spirit of
> keeping simple things simple, in practice, I'm sure that a flat
> structure will continue to work out just fine.
> 
> 				Cheers,
> 				-- Mike
> 
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [jose] xpo
> 
> 
> > "exp" wouldn't clash if we used some JSON structure in a JWK. For
> instance, separate the maths fields of the public key (n, e, ...) from
> the administrative parts (key-id, certificate, usage...). Instead, JWK
> goes for a flat bucket for all a key's info. Hence, we have potential
> problems with clashes of names from quite separate domains. We should
> fix the structure, instead of tinkering with the name.
> 
> Yes.  This.
> 
> > I don't know why the exp in jwk needs to be changed. From a developer
> POW there is no need. You always know which "exp" is the right one.
> > I would reverse the change from exp to xpo. Developers don't need it
> and many did not update their implementation to incorporate the exp-
> >xpo transition.
> >
> > Actually I don't care (much) how the parameters are named. Although I
> would like to stick to the 3-letter scheme I am OK with the n,e
> proposal.
> > But please stop making breaking changes (especially renaming
> parameters which leads only to more work and no gain).
> >
> > >> * Changed the name of the JWK RSA exponent parameter from exp to
> xpo so as to allow the potential use of the name exp for a future
> extension that might define an expiration parameter for keys. (The exp
> name is already used for this purpose in the JWT specification.)
> > >

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Oct 2012 06:41:58 +0000

Hi James,

In the JWK case you cite below, both uses of the name "y" would go into the registry.  This would not be a conflict, as their use is differentiated by the "alg" parameter value.  This is already the intent of the spec, but I'll be sure to re-read and review this language in the next round of revisions to make sure that this use of the registry is clearly called out as legal and intended.

Likewise, in the second case you cite, the JSON Web Signature and Encryption Header Parameters registry already makes it clear that "The same Header Parameter Name may be registered multiple times, provided that the parameter usage is compatible between the specifications."  There is no conflict.

We have no sets of algorithm combinations that take multiple independent keys as inputs, so there is no need for two "kid" parameters in any header.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Tuesday, October 23, 2012 4:48 PM
To: Mike Jones; [email-masked]
Subject: Re: [jose] xpo

For instance, an elliptic curve key can use "y" for the x-coordinate of a point; while a DSA key could use "y" for the public key (an integer). What goes in the registry?

--
James Manger

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Mike Jones
> present ("alg", "crv", "x", "y", "mod", "xpo", "use", and "kid").  
> I've heard discussions of maybe one or two more that people might 
> anticipate adding in the future (expiration time is the only one I can 
> remember off the top of my head).  So at least within the next few 
> years, the number might reach a dozen or so.  And we already have a 
> registry defined that would avoid parameter conflicts.
> 
> > Case3: xpo is just stupid -> n,e is better -> another change -> Oh 
> > no
> -> revert to exp
> >

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 24 Oct 2012 18:06:23 +1100

> In the JWK case you cite below, both uses of the name "y" would go into
> the registry.  This would not be a conflict, as their use is
> differentiated by the "alg" parameter value.  This is already the
> intent of the spec, but I'll be sure to re-read and review this
> language in the next round of revisions to make sure that this use of
> the registry is clearly called out as legal and intended.

Wow, strange registry.
P.S. The spec says "names that match other registered names in a case insensitive manner SHOULD NOT be accepted". I had been wondering why it wasn't "MUST NOT", now you are suggesting it is even looser than "MAY".

> Likewise, in the second case you cite, the JSON Web Signature and
> Encryption Header Parameters registry already makes it clear that "The
> same Header Parameter Name may be registered multiple times, provided
> that the parameter usage is compatible between the specifications."
> There is no conflict.

Identifying the originator's key and identifying the recipient's key are hardly "compatible" semantics.
Again, strange registry.

> We have no sets of algorithm combinations that take multiple
> independent keys as inputs, so there is no need for two "kid"
> parameters in any header.

The Crypto Message Syntax (CMS) has key agreement modes that involve identified originator and recipient keys so it is hardly impossible that JOSE might support something similar at some point.

--
James Manger