Re: [mm] delegating SSL certificates

2008-03-17 Thread Dirk-Willem van Gulik


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

2008-03-17 Thread Hal Finney
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=2q=known+plaintext+considered+harmless

Hal Finney

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: delegating SSL certificates

2008-03-17 Thread Leichter, Jerry
|  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

2008-03-17 Thread Bill Squier


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]