[Note: I joined the list very late in the game, and didn't see the original message. This is my reaction to seeing it now, and my thoughts on the concepts involved -- please feel free to bring me in-line with the actual objectives.]
On 4/20/05, Tyler Close <[EMAIL PROTECTED]> wrote: > On 4/18/05, Tyler Close <[EMAIL PROTECTED]> wrote: > > If Firefox will let us have encryption and key exchange > > without any annoying dialog, we can layer on our own accreditation > > mechanism > > Who is in charge of making this decision? What can I do to further > deployment of Frank's suggestion of making an https connection with an > unknown CA have the same UI features as an http:// connection? > > Tyler So, let me see if I understand this... You want to set it up so that if a certificate isn't found, it searches the CA root certificate for a specific OID, and if that OID is found either interrupts the current window, pops up another window, or gives an option to pop up another window to an https://-like (i.e., encrypted, identified via a specific extension on the site cert signed by the unknown certificate) URL to the CA's introduction facility? This would require two new OIDs allocated for Mozilla extensions: a) CA introduction service location (in the CA's certificate) [non-critical] b) CA introduction service authorization (in the Service web site's certificate) [critical? Meaning, an implementation that doesn't understand it won't be able to use it for identity?] As well as allowing for third-party certificates, would this idea theoretically involve the use of a browser extension for verifying, validating, or checking the status against the CA's model? If so, who would it be signed by? A signature from the CA certificate, identifying it as (the one? one of many?) "official integration extension"? A signature by a subordinate authority (maybe a user's certificate?) granted the authority to make that policy decision on behalf of the CA? That would involve at least one more, possibly two more new OIDs: c) authorized to sign official certificate extension for CA integration [ if a CA doesn't have it, embedded in its own certificate, would it be safe to assume that there is no CA integration? Or would it be incumbent on the key to prove that the CA really did sign it, that there may have been a policy change after the CA itself was brought operational? ] d) software certificate OID "official certificate extension for CA integration" [critical?] Hmm. Maybe the concept of "on behalf of" should also be investigated as a possible direction. (The idea was published as an RFC -- they're called "proxy certificates", and talked about in RFC3820 -- but I have not checked to see if any working implementations were ever created.) If there was a trusted introducer of some kind, it could express (in yet another extension or set of extensions) the precise trusts that it's granting. These ideas, of course, change the idea of a certificate from 'identity' to 'security principal', with transience of trust. And these ideas could also have security flaws in their implementations, much less their designs. But, I think I'd rather like to see it anyway -- at worst, it would bring about increased visibility of possible bugs. At best, it could be an alternative to the offline-CA mechanism we currently have. Cordially, Kyle Hamilton _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
