Eric Rescorla <e...@rtfm.com> writes: >We've talked several times about designing some sort of TLS delegation >mechanism. A few of us got together and put together some initial thoughts >about the options at: >https://www.ietf.org/id/draft-rescorla-tls-subcerts-00.txt
That's going to be a tricky one. The PKIX standing committee has always rigidly (and in some cases I'd say rabidly) opposed anything that would allow end users to bypass CAs (in one case the WG chair killed a proposal for delegated certs with the comment "we don't want to turn X.509 into PGP"). Admittedly PKIX is now defunct, but there are still enough PKIX members in the IETF that it could be tricky getting anything done. Another issue is how you're going to do it. You really need to have an EE able to use a standard cert to issue short-term certs for high-exposure environments, so only the high-risk key needs to be online. One of the proposals for this (which I have a link to, since I wrote it in this case) was: https://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt This talks about all of the issues involved. The alternative is to use a cert to sign "credentials", whatever form that may take. That's going to get ugly since you're now introducing something that's in effect a certificate, but isn't called a certificate (yes, you can whittle it down a bit, but eventually you'll want to add more features, and end up reinventing certs). I would go for delegated certs, since 99% of the work is already done for you (formats, data types, how to process them, code to handle them, etc). Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
