Thanks for your thoughts Nelson. There's one big problem with this idea of a certificate extension for additional signatures, which I hadn't thought of before (Thanks to Paul H for spotting it!)... For the additional signature(s) to become especially useful, the primary signature on the certificate would need to be substantially broken (e.g. by a pre-image attack on the hash algorithm). But if this happened, it is likely that the CA would revoke the certificate. Once the certificate is revoked, it's...errr...revoked. The additional signature(s) extension would simply be ignored.
On Monday 19 January 2009 22:07:46 Nelson B Bolyard wrote: > Rob Stradling wrote, On 2009-01-14 03:24 PST: > > To the NSS developers: If there existed a standardized certificate > > extension in which a CA could put additional signatures using different > > algorithms, do you think you'd consider adding support for it to NSS? > > Yes, I think the NSS team would consider it, if it really was a standard, > at least an IETF RFC. > > > If yes, might you do this before it was widely supported by CAs, or do > > you think you'd wait for the majority of CAs to start using it first? > > I think that largely depends on who does the work. > > If someone contributed a patch to NSS that implemented it, and was quite > complete (including changes to test tools and test scripts), and didn't > require much work at all to go in, I think it might go in basically as > soon as it was standard. The contribution of the Japanese Camellia cipher > was an example of a very well done contribution that went right in. > > But if the NSS must develop it, or if a contributed patch is incomplete > or requires a lot of work that the contributor is unwilling or unable to > do, then prioritizing and scheduling that work involves factors such as > the priorities of the sponsors of NSS development. > > Looking at the new developments in standards of the last few years, we > see a list of standardized features that are thought to be important by > various members of the crypto community, but which are not yet available > in NSS. To name just a few, there are TLS 1.2, AES GCM, OCSP stapling, > server support for SNI. Together they constitute a pretty large back log > of development waiting to be done. Another new proposal would contend with > those for resources. > > Not all of the features that have been added to NSS in the last few years > have been widely adopted by the applications that use NSS. Consequently, > the sponsors are now evaluating possible future developments based on their > projections for the demand of application developers for those features. > I think that says that if they see a groundswell of demand from the > application developers for a new feature such as multiple signatures in a > certificate, they might go for it, but otherwise, it is likely to languish, > IMO. _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
