On Thu, 24 Jul 2008 17:21:16 -0400 "Tom Scavo" <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 24, 2008 at 12:09 PM, Tim Freeman <[EMAIL PROTECTED]> wrote: > > On Wed, 23 Jul 2008 23:00:06 -0400 > > "Tom Scavo" <[EMAIL PROTECTED]> wrote: > > > >> An end-entity certificate signed by the meaningless CA > >> is no better than a self-signed certificate, but at least it doesn't > >> break GSI. > > > > What in GSI breaks? > > This, for example: > > http://bugzilla.globus.org/globus/show_bug.cgi?id=5543 > > Moreover, proxy path validation [RFC3820] requires that "valid paths > begin with the end entity certificate (EEC) that has already been > validated by public key certificate validation procedures in RFC 3280" > but as far as I can tell this precludes self-signed certificates. > > Note that RFC3280 has been obsoleted by RFC5280 but I don't think that > changes the basic requirement. Ah, thanks for answering. I indeed never tried to make a proxy off 'em. But at least there's a development trick for the mail archives, it comes in handy for hostcerts on test machines etc. (a version of this technique is also in use for some short term VMs that self-assert their host credentials). Thanks Tom, Tim > > > The basics at least seem to work, I haven't had problems > > dropping a self-signed cert into a client's trusted cert directory (done > > this > > with both C and Java in the past, maybe something is different now?). > > > > For example: > > <snip> > > Thanks for that tidbit (I'd hadn't realized that) but that behavior is > not specified, as is discussed in this thread: > > http://www.imc.org/ietf-pkix/mail-archive/msg04308.html > > Even if it were standard behavior, it doesn't satisfy the use case > that I mentioned previously, unfortunately. > > Tom
