Subject: Policy-Discussion
List archive
- From: "Kyle Hamilton" <aerowolf AT gmail.com>
- To: Policy-Discussion <cacert-policy AT lists.cacert.org>
- Subject: Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification
- Date: Mon, 20 Feb 2006 07:29:38 -0700
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kGWCAqSacRk2qenvvcDCFUql6T6NDO4ObMTFZ08bWXUo6nPS0WPyBv+uW+tK1Do2T/I7HQ2KyDsY2FLYSdI/o5YYV4U43ZiFSWOLkB6x7eWWZOvXSpY7bkJgd9grtWTWjwdNDJlLZ4oMfRmt1883fCh6WX8qGVIskLT0781awi0=
- List-archive: <http://lists.cacert.org/cgi-bin/mailman/private/cacert-policy>
- List-id: Policy-Discussion <cacert-policy.lists.cacert.org>
On 2/20/06, Ian G
<iang AT systemics.com>
wrote:
> Kyle Hamilton wrote:
> > This makes me wonder if it would be possible to have a key generator
> > somewhere that would split it into a 2/4 share scheme before ever
> > letting it leave the box -- preferably one that would do all the
> > encryption necessary to send via S/MIME to each of the employees, as
> > well as talking to the SMTP server to do so.
>
> Right, lots of musings on that general problem!
>
> In essence the reason the problem exists in the
> first place is that the PKI architecture tries
> to centralise the root system. If it were
> possible to add multiple signatures - like in
> the OpenPGP system - then things would be a lot
> more tractable. We'd simply suggest that CAcert
> have a root signing key at each one of its 4
> separated locations, and the certs would not be
> valid until 3/4 signatures were attached.
The problem is not the PKI system, it's X.509. I started a blog at
http://practicecrypto.blogspot.com/ where I muse on the problem.
> (My understanding is that in x.509 it is simply
> impractical if not technically impossible to
> implement multiple root signing. Please
> correct me if I'm wrong, as it would solve a
> *lot* of issues!)
Actually, it would be possible, it's just that nothing would recognize
the format at the current moment. (Then again, Deutsche Post seems to
be having that kind of issue as well -- they're giving out stuff that
just doesn't make any sense until you drill down into it.)
What's needed is something like an X.509v4, which would describe an
ASN.1 structure basically like this:
SEQUENCE OF X.509v3Certificates
Remember, in X.509 as defined by the ITU, there was no such thing as a
"certificate extension", nor was there anything defining a certificate
revocation -- determination of expiration was supposed to be handled
by an X.500 directory lookup. X.509v2 had to be created to define a
CRL, and X.509v3 (PKIX) described the format to embed certificate
extensions (OIDs) into the structure, and have the entire structure
signed.
Small wonder that I'm designing such a beast (something to accomplish
what v4 needs to do -- though I think I'm supposed to create a new
format and identify it with an OID at the beginning of the structure
instead of defining a new version of the X.509 format) for a piece of
software I'm working on.
-Kyle H
(incidentally... I. Hate. DER.)
- [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Philipp Gühring, 02/18/2006
- <Possible follow-up(s)>
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Philipp Gühring, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Kyle Hamilton, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Philipp Gühring, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Kyle Hamilton, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Ian G, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Kyle Hamilton, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Philipp Gühring, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Kyle Hamilton, 02/20/2006
- RE: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Lambert.Hofstra, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Kyle Hamilton, 02/20/2006
- RE: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Peter Williams, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Duane, 02/20/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Kyle Hamilton, 02/21/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Duane, 02/21/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Philipp Gühring, 02/21/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Ian G, 02/21/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Philipp Gühring, 02/21/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Duane, 02/21/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Kyle Hamilton, 02/21/2006
- Re: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Duane, 02/20/2006
- RE: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Lambert.Hofstra, 02/20/2006
- RE: [CAcert-Policy] [FIRSTREVIEW] Configuration Control Specification, Lambert.Hofstra, 02/20/2006
Archive powered by MHonArc 2.6.16.