(Note: this is almost completely off-topic as relates to the OP's message.)
"REAL programmers do everything they can to point out flaws of things that don't meet their needs, but are easier to use, older, more-debugged, and sufficient for those cases that don't require the ability to trust code running on the client machine to implement the policy that the server asks for." i.e., just because they don't meet YOUR needs of today doesn't mean they don't meet MINE. And the requirements you have are more in line with requiring DRM (and thus "Trusted Computing" where the user of the machine doesn't have access to the trusted platform module) than anything that can be implemented in user-land, anyway. If I understand what you've been working with, you're encoding key generation/request parameters into XML to be handled by the client. If you're doing XML for the parameters-provision, why not break the certificate request into XML too? Oddly enough, there is an ITU standard for this -- it's called XML Encoding Rules for ASN.1, or XER. I'm actually surprised nobody's started using XER for certificate storage/examination. Since DER is a means of encoding ASN.1 structures into the minimum number of bits, and since XER is an alternate encoding mechanism (though arguably into the MAXIMUM number of bits) for the same data, it would work -- yes, the signature is calculated over the DER encoding of the data, but that can be reconstituted from the XER. (My understanding is that this is part of what certificate validation is supposed to handle anyway -- all the information split out and stuck in a database, then reconstituted/revalidated as necessary.) Yes, we'd need special tools to verify the signature, but we already need special tools to parse DER. It would be a net win for debuggability and understanding what is in each certificate without having to load our DER parser every time we want to look at it. -Kyle H On Sun, Dec 28, 2008 at 6:47 AM, Anders Rundgren <anders.rundg...@telia.com> wrote: > I wouldn't spend much work on <keygen> and crypto.generateCRMFRequest > because they don't match today's needs anyway. You cannot even as an > issuer control PIN code settings (policy) unless you have a pre-configured > crypto > container, i.e. these mechanisms are tools for toy PKIs. > > Serious PKIs use smart cards and physical card/key/certificate distribution > because the on-line alternatives are more or less useless in addition to being > completely non-standard. The coming HTML5 standards work does not > even *try* to address this mess. I think they did the right thing; PKI > standards > in browsers reached an "all-time-high" already 10 years ago. > > PKIX are not aware of the problem because PKIX don't do browsers, > they do ASN.1. > > Anders > > ----- Original Message ----- > From: "Michael Ströder" <mich...@stroeder.com> > Newsgroups: mozilla.dev.tech.crypto > To: <dev-tech-crypto@lists.mozilla.org> > Sent: Sunday, December 28, 2008 13:38 > Subject: Re: Security-Critical Information (i.e. Private Key) transmittedby > Firefox to CA (i.e. > Thawte) during X.509 key/cert generation > > > Nelson B Bolyard wrote: >> I also think we need a page or two on developer.mozilla.org that fully >> documents both the <keygen> tag and the crypto.generateCRMFRequest method. > > +1 > >> The existing documentation is very incomplete. The <keygen> tag, for >> example, accepts many more arguments than are now publicly documented. > > Which arguments are that? > > Ciao, Michael. > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
