Re: and constrained subordinate CA costs?
Erwann ABALEA [EMAIL PROTECTED] writes: On Fri, 25 Mar 2005, Florian Weimer wrote: * Adam Back: Does anyone have info on the cost of sub-ordinate CA cert with a name space constraint (limited to issue certs on domains which are sub-domains of a your choice... ie only valid to issue certs on sub-domains of foo.com). Is there a technical option to enforce such a policy on subordinated CAs? Yes, the nameConstraints extension. But nobody checks it, and since this extension MUST be critical as per RFC3280, it invalidates the CA certificate that includes it, making it useless, for now. Not necessarily, some implementations also ignore the critical flag, so the cert is treated as valid, although the entire extension is ignored. However a corollary of this is that because of the hit-and-miss nature of support for the extension, you can't rely on it unless you carefully control all of the software that's used to process certs and make sure that it handles everything correctly. (Even if your app supports name constraints, there are some rather arcane matching rules in the spec that a number of apps get wrong, so there's a whole range of behaviours that you can encounter when you put a nameConstraints extension in a cert). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
how email encryption should work
-- In my blog http://blog.jim.com/ I post how email encryption should work I would appreciate some analysis of this proposal, which I think summarizes a great deal of discussion that I have read. * The user should automagically get his certified key when he sets up the email account, without having to do anything extra. We should allow him the option of doing extra stuff, but the default should be do nothing, and the option to do something should be labelled with something intimidating like Advanced custom cryptographic key management so that 99% of users never touch it. * In the default case, the mail client, if there are no keys present, logs in to a keyserver using a protocol analogous to SPEKE, using by default the same password as is used to download mail. That server then sends the key for that password and email address, and emails a certificate asserting that holder of that key can be reached at that email address. Each email address, not each user, has a unique key, which changes only when and if the user changes the password or email address. Unless the user wants to deal with advanced custom options, his from address must be the address that the client downloads mail from as it normally is. * The email client learns correspondent's public keys by receiving signed email. It assigns petnames on a per-key basis. A petname is also shorthand for entering a destination address (Well it is shorthand if the user modified it. The default petname is the actual address optionally followed by a count.) * The email client presents two checkboxes, sign and encrypt, both of which default to whatever was last used for this email address. If several addresses are used, it defaults to the strongest that was used for any one of them. If the destination address has never been used before, then encrypt is checked if the keys are known, greyed out if they are unknown. Sign is checked by default. * The signature is in the mail headers, not the body, and signs the body, the time sent, the sender's address, and the intended recipient's address. If the email is encrypted, the signature can only be checked by someone who possesses the decryption key. * If the user is completely oblivious to encryption and completely ignores those aspects of the program, and those he communicates with do likewise, he sends his public key all over the place in the headers, signs everything he sends, and encrypts any messages that are a reply to someone using similar software, and neither he nor those he corresponds with notice anything different or have to do anything extra other than that when he gets unsigned messages, or messages with an key different from the previously used key, a warning comes up an unobtrusive and easily ignored warning if he has never received a signed message from that source, a considerably stronger warning if he has previously received signed mail from that source. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG gOiN3HXQALAQHbKEOYdu/aZClRbPTEfjzyLpGAMx 4dJddm3vIwGuBnfc933djUV6zT4DWvM26KobmzFyC - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how email encryption should work
Hi James, I read that last night, and was still musing on it... James A. Donald wrote: -- In my blog http://blog.jim.com/ I post how email encryption should work I would appreciate some analysis of this proposal, which I think summarizes a great deal of discussion that I have read. * The user should automagically get his certified key when he sets up the email account, without having to do anything extra. We should allow him the option of doing extra stuff, but the default should be do nothing, and the option to do something should For clarity reasons, I think you mean that the default should be to not invoke the 'extra stuff' on automagic creation, rather than do nothing which is in fact what users get today - nothing. be labelled with something intimidating like Advanced custom cryptographic key management so that 99% of users never touch it. Concur. The notion that a user needs a cert from anyone else for the purpose of email is wrong; this doesn't mean denying them so they can take part in corporate nets for example, but that ordinary users in ordinary email will not get much benefit from certs signed by other agents. * In the default case, the mail client, if there are no keys present, logs in to a keyserver using a protocol analogous to SPEKE, using by default the same password as is used to download mail. That server then sends the key for that password and email address, and emails a certificate asserting that holder of that key can be reached at that email address. Each email address, not each user, has a unique key, which changes only when and if the user changes the password or email address. Unless the user wants to deal with advanced custom options, his from address must be the address that the client downloads mail from as it normally is. I would put this in the extra stuff category, and not in the default category. The reason is that it creates a dependency on a server that might not exist and even if a good idea, will take a while to prove itself. * The email client learns correspondent's public keys by receiving signed email. The problem I've discovered with this is that the signing of mail is (I suggest) not a good idea unless you have a good idea what the signature means. I've not seen anywhere where it sets out what a signature means for S/MIME. For OpenPGP the signature is strictly undefined by the code, so that's a better situation - it means whatever you want it to mean. Which means that most people under most circumstances should not send most emails out signed. Which sort of makes signed emails a poor carrier pigeon for a key exchange. (I don't have a solution to this - just pointing out what I see as a difficulty. The workaround is that the user turns off signing and has to send an explicit blank signed email as a key exchange message. Clumsy.) (One possibility is to put the cert in headers.) It assigns petnames on a per-key basis. A petname is also shorthand for entering a destination address (Well it is shorthand if the user modified it. The default petname is the actual address optionally followed by a count.) Yes this would help a lot. Any petname set should be displayed distinctly from the default name. (Oh, as a nitpick, a default address is not a petname, it's just a default name. A petname has to be set by the user to exist.) * The email client presents two checkboxes, sign and encrypt, both of which default to whatever was last used for this email address. If several addresses are used, it defaults to the strongest that was used for any one of them. If the destination address has never been used before, then encrypt is checked if the keys are known, greyed out if they are unknown. Sign is checked by default. Right, the UI could do a lot to show what is possible by shading the various email addresses or adding little icons to indicate their encryptability state. * The signature is in the mail headers, not the body, and signs the body, the time sent, the sender's address, and the intended recipient's address. If the email is encrypted, the signature can only be checked by someone who possesses the decryption key. I had an entertaining read of the paper on Naive Sign Encrypt last night. There are a lot of issues in how signatures are combined with encryption, I don't think this is a solved issue by any means when it comes to email. * If the user is completely oblivious to encryption and completely ignores those aspects of the program, and those he communicates with do likewise, he sends his public key all over the place in the headers, signs everything he sends, and encrypts any messages See caveat about signing above. I certainly agree that any message that can be encrypted should be encrypted. If you thought that
Re: Secure Science issues preview of their upcoming block cipher
Dan Kaminsky wrote: Have you looked at their scheme? http://www.securescience.net/ciphers/csc2/ Secure Science is basically publishing a cipher suite implemented by Tom St. Denis, author of Libtomcrypt. Aha! I seem to recall on this very list about 2 years back, Tom got crucified for trying to invent his own simple connection protocol. He withdrew from doing useful work in creating a new crypto protocol because of criticism here, and the world is a poorer place for it. I'd be interested to hear why he wants to improve on AES. The issue with doing that is that any marginal improvements he makes will have trouble overcoming the costs involved with others analysing his work. Using AES is just efficient, it allows us all to say, right, ok, next question in 2 seconds and then easily recommend his product. Still, even if he hasn't got any good reasons, I'd still support his right to try. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Net fingerprints combat attacks
http://news.bbc.co.uk/2/low/technology/4380189.stm The BBC Tuesday, 29 March, 2005, 08:17 GMT 09:17 UK Net fingerprints combat attacks Eighty large net service firms have switched on software to spot and stop net attacks automatically. The system creates digital fingerprints of ongoing incidents that are sent to every network affected. Firms involved in the smart sensing system believe it will help trace attacks back to their source. Data gathered will be passed to police to help build up intelligence about who is behind worm outbreaks and denial of service attacks. Tracing attacks Firms signing up for the sensing system include MCI, BT, Deutsche Telekom, Energis, NTT, Bell Canada and many others. The creation of the fingerprinting system has been brokered by US firm Arbor Networks and signatures of attacks will be passed to anyone suffering under the weight of an attack. Increasingly computer criminals are using swarms of remotely controlled computers to carry out denial of service attacks on websites, launch worms and relay spam around the net. We have seen attacks involving five and ten gigabytes of traffic, said Rob Pollard, sales director for Arbor Networks which is behind the fingerprinting system. Attacks of that size cause collateral damage as they cross the internet before they get to their destination, he said. Once an attack is spotted and its signature defined the information will be passed back down the chain of networks affected to help every unwitting player tackle the problem. FINGERPRINT USERS * Asia Netcom (Asia) * Bell Canada *BT (UK) * Energis (UK) *Deustsche Telekom (Germany) *EarthLink (US) *ITC DeltaCom(US) *MCI (US) * Merit Network (US) * NTT (Japan) *ThePlanet (US) *Verizon Dominicana *WilTel Communications (US) Mr Pollard said Arbor was not charging for the service and it would pass on fingerprint data to every network affected. What we want to do is help net service firms communicate with each other and then push the attacks further and further back around the world to their source, said Mr Pollard. Arbor Network's technology works by building up a detailed history of traffic on a network. It spots which computers or groups of users regularly talk to each other and what types of traffic passes between machines or workgroups. Any anomaly to this usual pattern is spotted and flagged to network administrators who can take action if the traffic is due to a net-based attack of some kind. This type of close analysis has become very useful as net attacks are increasingly launched using several hundred or thousand different machines. Anyone looking at the traffic on a machine by machine basis would be unlikely to spot that they were all part of a concerted attack. Attacks are getting more diffuse and more sophisticated, said Malcolm Seagrave, security expert at Energis. In the last 12 months it started getting noticeable that criminals were taking to it and we've seen massive growth. He said that although informal systems exist to pass on information about attacks, often commercial confidentiality got in the way of sharing enough information to properly combat attacks. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
