Re: [mm] delegating SSL certificates
On Mar 16, 2008, at 7:52 PM, Ben Laurie wrote: 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. I think you are hitting a key point here. In a way - a CA (or some sub- CA) is less of an authority and more of a, ideally, somewhat consistent organizational realm. 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 :-) And at the same time we need to learn to, or be weaned away from, the hardened shell perimeter ideas, that of a single super reliable root - and start to see a CA as something like one of the Kerberos KDC's we trust, just a NIS+ server we like, etc. Dw - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RNG for Padding
Mr Pink writes: > In Applied Crypto, the use of padding for CBC encryption is suggested > to be met by ending the data block with a 1 and then all 0s to the end > of the block size. > > Is this not introducing a risk as you are essentially introducing a > large amount of guessable plaintext into the ciphertext. > > Is it not wiser to use RNG data as the padding, and using some kind of > embedded packet size header to tell the system what is padding? Back in 2001, there was a discussion of the general issue of altering data structures to avoid known plaintext on sci.crypt, under the subject of "Known Plaintext Considered Harmless". A surprising diversity of opinions were expressed. http://groups.google.com/group/sci.crypt/browse_thread/thread/f1aae3a2d10dbcd4?tvc=2&q=known+plaintext+considered+harmless Hal Finney - 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 Apple's Mail.app checks certs on SSL-based mail server connections. It has the good - but also bad - feature that it *always* asks for user approval if it gets a cert it doesn't like. One ISP I've used for years (BestWeb) uses an *expired* self-signing cert. The "self-signed" part I could get around - it's possible to add new CA's to Mail.app's list. But there's no way to get it to accept an expired cert automatically. So ... every time Mail.app starts up, it complains about the cert and asks me to approve it. This stalls Mail's startup, and it fails to pick up mail - from any server - until I tell it, OK, yes, go ahead. The cert has now been expired for over 2 years. (You might well wonder why, if you're going to use a self-signed cert, you *ever* let it expire - much less cut one, like theirs, with a 1-year lifetime. Since all you're getting with a self-signed cert is "continuity of identity", expiration has no positives, just negatives. Perhaps they were planning to go out of business in a year? :-) ) I've been in touch with BestWeb's support guys repeatedly. Either they just don't understand what I'm talking about, or I'll finally get someone to understand, he'll ask me for details on which cert is expired, I'll send them - and then nothing will happen. Clueless. Just to add to the amusement, *some* of their services - Web mail, and through it tuning of their spam filters - are accessible *only* through HTTP, not HTTPS. These use the same credentials Perhaps I should just go with the flow and use unencrypted connections. (Or get over my inertia, stop trying to get them to fix things, and drop my connections to them at the next renewal) -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: delegating SSL certificates
On Mar 17, 2008, at 10:06 AM, Leichter, Jerry 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. | | Presumably the value they add is that they keep browsers from popping | up scary warning messages Apple's Mail.app checks certs on SSL-based mail server connections. It has the good - but also bad - feature that it *always* asks for user approval if it gets a cert it doesn't like. Fixed in Leopard. Certificate handling in general appears to be better -- although I can't be sure Tiger didn't let you fiddle with fine-grained entitlements as to when to trust a cert. -wps - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
