Il 25/05/2012 10:59, Martin Paljak ha scritto: > Hello, > > On Wed, May 23, 2012 at 2:57 PM, NdK <ndk.cla...@gmail.com> wrote: >> I'm thinking to use one to store our internal root CA's key (4096bit >> RSA). [actually I'm thinking more about a "ring of roots", but that's >> another story] > Care to share the story? Yup. Sure. A bit OT, but I'll try to keep it terse.
It's just an idea, still have to test it. Might be that it pushes cert parsing "over its limits". I'm assuming the chain checking is stopped as soon as a trusted cert is found. It's based on good old FidoNet routing: - 3 'root' CAs - Every CA is root for only one of the other two - the 'root' CAs are equipotent. - there's no self-signed certificate - users choose to trust one, two or three of the 'root' CAs (the more the better and faster verifications). Say CAs are A, B, C. A's cert is signed by B, B's cert is signed by C and C's cert is signed by A. Worst case: the user chose to only trust B and connects to an intranet http server. He's presented a cert signed by C.C1s.C1www (C signed C1s' cert delegating 's'ervers and C1s signed C1www's cert delegating http servers certs issuance). Then cert chain is checked: site, C1www, C1s, C and finally A that, being signed by B validates all the chain. If the user chose to trust A and C too, then last two steps could be avoided, omitting costly verifications with large keys. This makes the system quite scalable, with a tradeoff between number of root certs to store and (computational and network) resources used to verify received certs. This schema 'requires' (unless you want to change all root-CAs certs quite often) quite a static root set, so it's not for "general" use (say between different CAs). But I think it could well accomodate our needs. Any evident pitfalls? BYtE, Diego. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
