On Sun, Dec 28, 2008 at 11:26 PM, Anders Rundgren <anders.rundg...@telia.com> wrote: > Kyle Hamilton wrote: >>(Note: this is almost completely off-topic as relates to the OP's message.) > > 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.
You cannot trust client code to do what you ask it to do. You cannot trust client code to do what your security policy requires it to do. A client can take a request from a server to generate a key on a hardware token and perform the possibility entirely in software, and the server has no means of knowing about it. This is one of the largest, most annoying, and most severely damaging aspects of client-server programming. (We've been discussing this on the openssl lists lately -- the requirement that the client run code that does what the server expects it to is a DRM problem, in which modifications to the behavior of the code can disable the client application.) >>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. I'd love to have this world exist, but I'd also like to add the caveat that not every issuer should be required to be audited to financial-services grade. > 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. How is this attestation made? (I'm asking because I cannot find your KeyGen2 submission, since you withdrew it "[d]ue to IPR issues".) If you're working with TPMs and relying on configuration registers, they can be emulated. Everything can be emulated, really, and you're still relying on the client computer to do what the server expects. >>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. Not everything in a CSR is thrown away. Not everything in a CSR needs to be thrown away. Perhaps it does for financial-services CAs, but not for all CAs. Mozilla software isn't solely used as a platform for financial services. >> [suggestion of XER snipped] > > 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. And a lot of CAs do not abide by the requirement (from RFC 5280 nee 3280, but not RFC 2459) of a positive serial number, either (X.509 itself allows for 0, and openssl will implicitly use 00 with its 'x509' command). If they don't use proper DER encoding, conforming software is required to reject them. Mozilla reserves the right to reject CAs from the trust program if they issue nonconforming certificates, for example. The entire point of DER is that there's one-and-only-one true encoding. (That's what separates DER from BER.) -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
