Kyle Hamilton wrote: >(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 don't completely get this. If we are talking about soft tokens of the kind implemented in Mozilla, PKI-using services rely on keys stored in containers using obfuscation and optional weak passwords as the only protection. IMO, this trust in client code is above the level of trust that PIN policy support requires since the former enables key theft. >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. The "big picture" of this project is establishing a practical HW-crypto solution based on mobile phones with consumers/citizens as primary target. I'm not aware of anything similar going on elsewhere unless you consider EU eID projects as "practical". I don't because these schemes are based on an all-mighty CA while my scheme is based on a world of competing technlogies and issuers. Unlike the existing schemes, KeyGen2 supports inside-of-container- generation-attestation which I consider a valid requirement, otherwise HW-crypto is a waste since the service cannot verify that a key really is in HW. >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. If you look closely on <keygen>, generatecRMFRequest and CertEnroll, certificate request is redundant (is thrown away by the CA), it is really a key generation response you need and is implemented in KeyGen2. >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. According to a recent discussion in PKIX the only safe way dealing with certificates is treating them as blobs because a lot of CAs do not use proper DER encoding. Anders 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 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
