[117483] in cryptography@c2.net mail archive
Re: [mm] delegating SSL certificates
daemon@ATHENA.MIT.EDU (Dirk-Willem van Gulik)
Tue Mar 18 13:59:39 2008
Cc: Cryptography <cryptography@metzdowd.com>
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
To: Ben Laurie <ben@links.org>
In-Reply-To: <47DD6C56.5070607@links.org>
Date: Mon, 17 Mar 2008 00:24:26 +0100
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 majordomo@metzdowd.com
