Re: [cryptography] PKI in practice: is there a list of (widely deployed) client-certs-issuing CAs?
A question for those who follow PKI usage trends. Is there a list of CAs that issue X.509 end-user certificates? Here is the rationale for the question: If an end-user has a certificate, he (more or less consciously) controls a private key. Suppose one deploys a web server that cares *only* about end-user public keys, e.g. it keeps track of end-user reputation and that's it for trust management. Then any type of certificate is good enough (self-signed, auto-issued, issued by a regular client-cert-issuing CA). This web server can have an immediate potential user base if it negotiates the TLS session with a long list of CA distinguished names (in the CertificateRequest message). The management tools for the contemplated web server scheme would include an issuer DN extraction utility from end-user or CA certificates so that the list may be augmented based on casual observations. Also, the SSL debugging tools will report the contents of CertificateRequest messages from public servers supporting client certs. Anyone went through such data collection before? Thanks in advance. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography Why not just send an empty list for certificate_authorities in the CertificateRequest? Most (all?) user-facing TLS clients will then presume the site has no restriction, and select from all of the available client certs that the user may have. Trying to stuff all the names - not to mention cross-signed intermediates, which are often necessary - and you're likely to blow out the record limits. Many TLS implementations, particularly TLS middleboxen, do not like fragmented handshake messages, so trying to stuff the Whole World into the request will likely break things considerably. I'm not sure how such a scheme would work for self-signed user certs, they inevitably would not match your pre-programmed list of DNs. See, for example, http://support.microsoft.com/kb/933430 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] An oldie but a goodie
In the 1980s DEC gave us crypt16, reducing password-guessing from 25 DES operations to a suffix search requiring only 5 DES operations. In the 1990s MS gave us LMHASH, reducing it to a single DES operation. Now, in 2012, the WiFi Alliance is proud to present WPS' wps_reg, which splits a 7-digit PIN into 4- and 3-digit halves, easily beating both DEC and MS broken auth-checking mechanisms: http://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/ The WiFi Alliance is hereby nominated for the Tenex Memorial Prize [*] for innovative design in authentication mechanisms. Peter. [*] The Tenex Memorial Prize dates back to the late 1960s, when this security bug was first introduced. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PKI in practice: is there a list of (widely deployed) client-certs-issuing CAs?
Follow-up on my own post below ... Thierry Moreau wrote: A question for those who follow PKI usage trends. Is there a list of CAs that issue X.509 end-user certificates? Here is the rationale for the question: If an end-user has a certificate, he (more or less consciously) controls a private key. Suppose one deploys a web server that cares *only* about end-user public keys, e.g. it keeps track of end-user reputation and that's it for trust management. Then any type of certificate is good enough (self-signed, auto-issued, issued by a regular client-cert-issuing CA). This web server can have an immediate potential user base if it negotiates the TLS session with a long list of CA distinguished names (in the CertificateRequest message). The management tools for the contemplated web server scheme would include an issuer DN extraction utility from end-user or CA certificates so that the list may be augmented based on casual observations. Also, the SSL debugging tools will report the contents of CertificateRequest messages from public servers supporting client certs. Anyone went through such data collection before? Thanks in advance. I got a few off-list messages. One pointed towards the TLS 1.1 provision for an empty list of client-certs-issuing CA in the CertificateRequest message (in which case the client may use any certificate, which is the intended purpose). This is a protocol relaxation from TLS 1.0. Another observation is that a major TLS *server* implementation truncates this list (from the operator-supplied configuration) to a much smaller size than the protocol limit. I don't know if this reflects some browser-client limitations as a TLS client entity. So, if I had a long list of distinguished names for client-certs-issuing-CA, I am not sure I could recommend to use it as a default configuration item. I guess it's preferable to focus on configuration management tools that ease the job of supporting a more specific server user base. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] data integrity: secret key vs. non-secret verifier; and: are we winning?
On Fri, Apr 27, 2012 at 9:15 AM, ianG i...@iang.org wrote: Easy. Take the hash, then publish it. The data can be secret, the hash need not be. That works for git. In particular what's nice about it is that you get copies of the hash stored all over. A similar approach can work for Tahoe-LAFS. If the clients remember the Merkle hash tree roots, you don't need to do any AE nor anything else to authenticate the data. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PKI in practice: is there a list of (widely deployed) client-certs-issuing CAs?
On 27/04/12 03:34 AM, Thierry Moreau wrote: A question for those who follow PKI usage trends. Is there a list of CAs that issue X.509 end-user certificates? Hmm client-certs as opposed to server-side certs. The answer is most but as it is a very low value faux-loss-leader business, nobody cares much about it, certainly not enough to track it as far as I know. Here is the rationale for the question: If an end-user has a certificate, he (more or less consciously) controls a private key. Suppose one deploys a web server that cares *only* about end-user public keys, e.g. it keeps track of end-user reputation and that's it for trust management. Then any type of certificate is good enough (self-signed, auto-issued, issued by a regular client-cert-issuing CA). Yes, this is what I do with a site of mine. Anyone with a client-cert can connect and play. That's it. You can read some sort of intro about the background here: http://wiki.cacert.org/Technology/KnowledgeBase/ClientCerts/theOldNewThing But what we lack is a how-to of all the decisions. This web server can have an immediate potential user base if it negotiates the TLS session with a long list of CA distinguished names (in the CertificateRequest message). ah. In my work, I have discovered that it is far better to turn off all decision making in the TLS/apache side, to simply set the cert request to optional and pass the result in variables to the application. SSLVerifyClient optional SSLOptions +StdEnvVars +FakeBasicAuth +ExportCertData SSLUserName SSL_CLIENT_S_DN_Email Then, in the application code, read all the cert variables and make an application level decision. The management tools for the contemplated web server scheme would include an issuer DN extraction utility from end-user or CA certificates so that the list may be augmented based on casual observations. Also, the SSL debugging tools will report the contents of CertificateRequest messages from public servers supporting client certs. Anyone went through such data collection before? Well, to the extent above. My db has a table for all certs, and a table for all users, with a join by cert identifiers between the two tables. Thanks in advance. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
