Re: delegating SSL certificates
[EMAIL PROTECTED] writes: I would think this would be rather common, and I may have heard about certs that had authority to sign other certs in some circumstances... The desire to do it isn't uncommon, but it runs into problems with PKI religious dogma that only a CA can ever issue a certificate. For example I proposed this on the PKIX working group nearly a decade ago, specifically the ability for end entities with signing certs to issue their own encryption certs, since there's absolutely no need to involve a CA in this. I've still got the draft online at http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt. The WG chair's response was we don't want to turn X.509 into PGP, and that was the end of it. The grid computing folks eventually got something through in the form of proxy certificates for the Globus GSI, but that probably isn't what you're looking for. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: delegating SSL certificates
[EMAIL PROTECTED] wrote: So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. You only think this is bad because you believe CAs add some value. SSH keys aren't signed and don't expire. Is that bad? -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RNG for Padding
We had many discussions about this 15 years ago You usually have predictable plaintext. A cipher that isn't strong enough against a chosen/known plaintext attack has too many other protocol problems to worry about mere padding! For IPsec, we originally specified random padding with 1 trailing byte of predictable trailing plaintext (the amount of padding). Together with the (encapsulated) protocol number, that actually made 2 bytes of predictable trailing plaintext. Due to my work in other groups, everything that I've specified afterward uses self-describing-padding. That is, the last byte indicates how much padding (just as before), but each byte of the padding indicates its position in the padding sequence. 0 ::= never used. 1 ::= 1 byte of padding (itself) 1 2 ::= 2 bytes of padding ... The original impetus was hardware manufacturers of in-line cipher devices, that don't usually have a good source of randomness. Also, this provides a modest amount of integrity protection. After decryption, the trailing padding must be the correct sequence. Of course, this should be in addition to integrity protection over the whole packet! Additionally, this avoids a possible covert channel for compromised data, whether by accident (revealing a poor RNG or the current state of the RNG), or trojan process communication. Note that I've said avoids, as varying the amount of padding would give a lower bandwidth channel for the latter. When designing, it's always best to defend in depth. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Sat, Feb 23, 2008 at 05:09:29AM +1300, Peter Gutmann wrote:
There were commercial products that did this available some years
ago, they hooked into the Windows auth using a custom GINA DLL
(GINA = the Windows extensible login/authentication mechanism,
think PAM for Windows) and locked the machine when you moved away
from it. They failed in the marketplace, there was no interest in
them from users (or at least several of them failed, some may
still be around).
[...]
Saw an interesting free software example of this the other day (not
for Windows, of course) using loss of signal from a particular
bluetooth device (mobile phone, et cetera) to lock your machine or
run other designated commands:
http://sourceforge.net/projects/blueproximity/
It also supports *unlocking* on approach, but that's a bad idea
unless they can start providing a client to run on the token
device (maybe using asymmetric key crypto to sign and verify a
challenge string instead of just looking for the device's BT
address).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: delegating SSL certificates
So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. You only think this is bad because you believe CAs add some value. Presumably the value they add is that they keep browsers from popping up scary warning messages. There are all sorts of reasonable arguments to be made that the browsers are doing the wrong thing (and the way that Microsoft prevents you from ever deleting any of their preinstalled CA certs is among the wrongest.) Nonetheless, unless we can persuade all the users in question to adjust their browsers, which is always a losing battle, it's easier just to pay the $15 protection money and get a CA signature. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: delegating SSL certificates
On Mar 16, 2008, at 12:32 PM, Ben Laurie wrote: [EMAIL PROTECTED] wrote: So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. You only think this is bad because you believe CAs add some value. SSH keys aren't signed and don't expire. Is that bad? Agred - that (signing) in itself not important - however in a (large) corporate environment overall plain keys does force one to re-invent the same kind of CA and/or CRL wheel with respect to the expiring and the lack of a managed authority. I recently came across two installations where ssh public keys where used to great avail (combined with a command= construct which would launch various curses/IBM tn3270 user interfaces), in one case combined with a commercial product where a x509 on a chipcard would login and 'unlock' a users windows home directory/registry. This system had been going on for many, many years and had seen several OS migrations. With the advent of faster moving windows/laptops - a lot keys had been 'lost'. Some due to real loosing of a laptop; most due to automated upgrades wiping the users transients home-directory/registry. After a bit of scripting it seemed that for every key which had been used in the last few weeks; a little over 8 keys where 'dormant'. A manual quick sample confirmed that most of those where associated with lost/retired equipment (hire/fire was a well controlled HR process). Looking at an authorized keys file revealed little - as few, if any, comments where filled out. Couple of things suprized me, and/or where a serious of an eye opener to me: A Even very experienced sysadmins can make the conceptual error that an old 'public key' is not 'dangerous' _because_ it is public. Therefore you do not need to keep careful track of them or be 'super diligent' when managing your key files. B The very nature of the ssh public key (esp. when generated in an environment where the comment field is not easily attributed to a specific user; e.g. on windows some tools just put the text 'Generated by SShKey.exe' in that field) is very hard to manage - and really assumes a 1:1 mapping of a unix account to a real person. C The lack of expiry _combined_ with the lack of easily 'documenting' an ssh key (i.e. the full key or even the fingerprint or bubblebabble of the ssh pub key is a bit painful when you need to cross a cut-and-paste barrier) easily creates and environment where the keys start to lag behind or where the pain combined with false security due to the 'A' misconception starts to conspire against you. And as an aside - as one of the organisations already had a PKI rolled out into every nook and cranny - so using the Roumen Petrof patches which add x509 to openssh* - has helped solve some of the worse excesses virtually overnight. So I'd argue that while x509, its CA's and its CRL's are a serious pain to deal** with, and seem add little value if you assume avery diligent and experienced operational team -- they do provide a useful 'procedural' framework and workflow-guide which is in itself very valuable, relatively robust and are a little bit organisationally inherently fail-safe. The latter as you are forced to think about expiry of the assertions, what to do when a CRL is too old and so on. Or perhaps we're comparing apples and oranges; ssh is just a pure pub/ priv key pair -- whereas x509 is a management framework in which you happen to also have embedded and manage a pub/priv key pair along with a whole lot of other things. However - as firewalls and hardening of the far-outer perimeter is increasingly becoming ineffective, as you increasingly look at fine grained controls close to the user and (end) applications -- we do need to come to grips (much) better with the distributed management tools which let us map those controls to the desired social/ organisational model they are functioning within. Thanks, Dw. *: http://www.roumenpetrov.info/openssh/ (and I'd love those in openssh itself, and in solaris please :) **: not in the least as they force you to tackle nasty organisational questions such as who is really responsible for what; rather than let it fester it into some ops-team 'we always did it like that' fudge. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [mm] delegating SSL certificates
Dirk-Willem van Gulik wrote: So I'd argue that while x509, its CA's and its CRL's are a serious pain to deal** with, and seem add little value if you assume avery diligent and experienced operational team -- they do provide a useful 'procedural' framework and workflow-guide which is in itself very valuable, relatively robust and are a little bit organisationally inherently fail-safe. The latter as you are forced to think about expiry of the assertions, what to do when a CRL is too old and so on. I think there's a large gulf between the use case where the relying party and the CA are the same entity, and where they do not even have a contractual arrangement. CAs within a corporate environment may well be a good idea in some cases, indeed. As you know, we've been pushing on this idea at the Apache Software Foundation for some time now, hindered only by our laziness :-) -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
