Kent commented on Kyle Hamilton's remarks... #>Using the same key across multiple places may not seem to be #>something which has turned out to be a problem in practice, in that #>TLS sites use the same keys across every client. However, it's a #>major reason why client-side authentication isn't accepted by the #>individual consumer. # #most folks believe that client certs are not widely used because of #the added hassle to issue them, poor cert management tools for users #who need to use the certs, and associated private keys, across #multiple machines, and the inertia associated with moving away from #passwords.
This is actually a fascinating question, and one where the answer you get for "Why don't people deploy client certs?" varies from person to person. I attempt to capture a little of that in a talk I did a week or so ago at Internet2/ESNet Joint Techs in Baton Rouge: "Client Cert Deployment Models and Hardware Tokens/Smart Cards" http://pages.uoregon.edu/joe/client-cert-models/jt-louisiana.pdf It wasn't possible to do an exhaustive analysis of that question in a 20 minute slot, but you can at least get an idea of what we're seeing... #>This means that we can't rely on a single certified public key. We #>can't even rely on knowing ahead of time how many keys we need to #>enroll. We can't accept constant DNs. We can't accept static keys. #>We can't accept static certifications. # #I agree that users ought to have multiple keys/certs, and have done #so in papers and talks since 1997. I don't see how this relates to #constant names, static keys or static certification. FWIW, even the Feds issue multiple certs, if only because some need to be non-repudiable (e.g., for signing) while others need to be escrowed for potential recovery (or authorized monitoring) of encrypted content (at least in a Federal environment). That said, given my druthers, I'd prefer a single client cert to use for MOST purposes, just as I prefer to use a single PGP/GPG key -- it's easier, and reduces correspondent confusion. #>As a result, we need certifications to be API-enrollable. The API #>must allow the user to able to specify what aspects of his certified #>identity are placed into the certificate. Certifications should be #>a marginal cost item (a penny or two), because there is something of #>a queue for the certifier token service. They should not be free, #>but they shouldn't be expensive either. I'd also argue that there's a discontinuity in potential cert prices: you can have free certs, and you can have not free certs, but you probably can't have really really cheap certs (e.g., in the couple of cent range) for all the reasons that micropayments have traditionally been tricky online, to say nothing of customer expectations ("Hey buddy, I paid a dime for that cert, I want to see some SERVICE when I have a problem!") I'd also assert that the cost of the cert is trivial relative to the cost of the secure storage device that might hold the cert (e.g., a USB format hard token, or a smart card and reader). #there are other models of cert issuance that might yield free certs, #with limits on the context in which each cert is used. such limits #help protect user privacy, because a user need not employ the same #cert with a lot of different services. but, any model that requires #user to have a number of certs must contend with the user interface #problems to which I alluded above. I concur that multiple certs equal user confusion unless you can really make it pretty darn clear (e.g., jsmith+sign...@example.com or jsmith+encrypt...@example.com, for example). If I want non-attributability, I'm not sure that I want to be using a cert at all #>We should focus on providing as many chains of authority as are #>necessary to ensure security. Perhaps enroll new keys using both a #>personal enrollment key and a device enrollment key, so that it's #>possible to identify which device was compromised? # #we don't require the same level of security for all transactions. if #we assume that the cost to issue a credential may be proportional to #the assurance associated with its issuance (which may not be true in #all cases), then we might have very cheap, maybe free credentials for #many transactions, and better ones, perhaps more expensive ones, for #a more limited set of transactions. One size need not fit all re #issuance. But it is nice if one format can be used to reduce costs #for CAs and RPs. An interesting approach, BTW, is the one that CILogon takes, leveraging federated authentication to mint certs for secure access to cyber infrastructure -- see http://www.cilogon.org/ for more information about this approach, if interested. Regards, Joe _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
