Re: Security-Critical Information (i.e. Private Key) transmittedbyFirefox to CA (i.e. Thawte) during X.509 key/cert generation
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
Re: Security-Critical Information (i.e. Private Key) transmittedbyFirefox to CA (i.e. Thawte) during X.509 key/cert generation
On 29/12/08 08:26, Anders Rundgren wrote: The big picture of this project is establishing a practical HW-crypto solution based on mobile phones with consumers/citizens as primary target. Big picture: Yes, that's about where we are heading. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmittedbyFirefox to CA (i.e. Thawte) during X.509 key/cert generation
Anders Rundgren wrote: Michael Ströder wrote: Anders Rundgren wrote: I wouldn't spend much work on keygen and crypto.generateCRMFRequest because they don't match today's needs anyway. Your comment is not relevant in this context. Off course the *existing* implementation of keygen and crypto.generateCRMFRequest should be fully *documented* as Nelson suggested. Maybe, maybe not. Oh, come on! Like it or not: People are using that stuff and S/MIME. So it should be documented in detail how it works. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmittedbyFirefox to CA (i.e. Thawte) during X.509 key/cert generation
Kyle Hamilton wrote, On 2008-12-29 01:08: On Sun, Dec 28, 2008 at 11:26 PM, Anders Rundgren wrote: [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. 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. 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). NSS has a rather strict DER decoder. So certs that don't conform to DER are not very likely to be usable by NSS. But some of the requirements of the IETF RFCs go beyond the requirements of DER, and NSS enforces many (most?) but not all of those additional requirements. For example, the certificate serial number is a DER INTEGER (primitive ASN.1 types are always spelled in all CAPS), and DER INTEGERs can be positive, negative or zero. NSS is happy with any correctly DER encoded integer, and doesn't reject negative values (the RFC explicitly allows this, IIRC). On other other hand, NSS does strictly enforce the rule that serial numbers must be unique, and NSS requires that no two different certs share the same serial number. The entire point of DER is that there's one-and-only-one true encoding. (That's what separates DER from BER.) Well, yes and no. One area where that falls apart is Directory Names (DNs, a.k.a. Distinguished Names). ASN.1 defines numerous different overlapping character sets, and the X.50x definition of DNs allows most attributes to be encoded in any of the character sets that are capable of encoding them. So, given an attribute value that consists entirely of ASCII alphanumeric characters, there are numerous different ways to encode it, all valid. That defeats the one true encoding idea. RFC 3280 attempted to solve that problem by requiring that one particular encoding (UTF8) be used in any attribute that X.50x permits to be encoded in any of several character sets. RFC 3280 said that conformant implementations may ASSUME that attributes encoded in different character sets are encodings of different values, and NSS does exactly that. But now RFC 5280, the successor to RFC 3280, allows the use multiple character sets again, and seems to require conformant implementations to be able to compare and match attributes even in different character sets. So the one true encoding idea is thoroughly ruined in the world of X.509 certificates, IMO. In any case, NSS does not yet claim conformance to RFC 5280, and probably will not for quite some time. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security-Critical Information (i.e. Private Key) transmittedbyFirefox to CA (i.e. Thawte) during X.509 key/cert generation
Michael Ströder wrote: Anders Rundgren wrote: I wouldn't spend much work on keygen and crypto.generateCRMFRequest because they don't match today's needs anyway. Anders, does the word keygen trigger an automatic response in your news bot? ;-} Well, some 1000h into its successor have left some traces :-) :-) Your comment is not relevant in this context. Off course the *existing* implementation of keygen and crypto.generateCRMFRequest should be fully *documented* as Nelson suggested. Maybe, maybe not. I assume that private key transfer is only allowed (if possible at all) for encryption keys. It seems to me that this is a rather useless function since most organizations are more concerned about sent data than received ditto. I.e. key escrow doesn't work very well for organizations which is why Outlook has an entirely different approach to message escrow which actually works (clear-text message logging in parallell to encrypted messaging). If the fear is rather that the CA could impersonate a user, it can do that without notifying the user with warning dialogs. If the goal is rather providing encryption key backup for consumers, I guess we are back to the question if S/MIME encryption is for real or not. Based on actual usage by consumers this issue is already settled. That is, if private key transfer actually is enabled the correct solution [IMO] is not to dicument it, but to disable it. 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
Re: Security-Critical Information (i.e. Private Key) transmittedbyFirefox to CA (i.e. Thawte) during X.509 key/cert generation
Anders Rundgren wrote, On 2008-12-28 07:52: [...] most organizations are more concerned about sent data than received [...] This is one reason (out of many) that Mozilla's S/MIME mail clients require that the sender be an implicit recipient of any encrypted messages sent. It ensures that the sender's private key is also able to decrypt the messages he sends. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
