Subject: Policy-Discussion
List archive
Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC
Chronological Thread
- From: "Sam Johnston" <samj AT samj.net>
- To: Policy-Discussion <cacert-policy AT lists.cacert.org>
- Subject: Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC
- Date: Mon, 20 Oct 2008 11:08:32 +0800
- List-archive: <https://lists.cacert.org/cgi-bin/mailman/private/cacert-policy>
- List-id: Policy-Discussion <cacert-policy.lists.cacert.org>
On Fri, Oct 17, 2008 at 5:46 AM, IanG <iang AT cacert.org> wrote:
Right, so it seems premature to introduce it here anyway.
Right, chaining for us is more a logical grouping of certificates and a way for us to show users that the verification is being done by someone else (albeit to an acceptable pre-approved standard). It is also significantly more secure in that organisations know that they are the only ones issuing certificates under their sub-root so they can authenticate users simply by installing their sub-root into servers without having to worry about verifying the contents (eg O= field) which is inherently dangerous.
Sam
Peter Williams wrote:I don't think they are contemplating removing the existing ones,
> Is a subroot simply a first- or nth-level subordinate CA chained from a root?
>
> They are contemplating removing from the registry those roots that have subordinate CAs in their trust network?
exactly. Instead, they are contemplating policies that mean it is
not allowed, or it requires additional work, or something. What is
somewhat clear is that they are not happy with the obvious trick
that is being played; how they deal with it is totally unclear.
The Mozilla debates are public and Microsoft are apparently very tight lipped about their policies (ie we know nothing about them) so perhaps those introducing it into the debate could provide references?
The 'trick' you refer to is the issuance of a certificate to an organisation which can be used to issue other certificates containing whatever the organisation feels like. This is essentially the status quo today - we are effectively giving orgs access to our roots to mint certificates containing whatever they like.
(Also, to be fair, not everyone is unhappy. Some are happy ... and
the debate appears only to be in early stages, at least over at
Mozilla.)
Right, so it seems premature to introduce it here anyway.
> As that really doesn't make any sense, technically, it makes me wondering if subroot is something other than a simple subordinate CA, chained up to the root.It is that; the issue is not at the chaining level but at the
semantics and legal agreements level, and whether and how the
primary CA is responsible for the actions of the sub-CAs.
(At, least that's what it appears to be. I've seen a few expressed
opinions on this and the clarity & consistency level is not high.)
Right, chaining for us is more a logical grouping of certificates and a way for us to show users that the verification is being done by someone else (albeit to an acceptable pre-approved standard). It is also significantly more secure in that organisations know that they are the only ones issuing certificates under their sub-root so they can authenticate users simply by installing their sub-root into servers without having to worry about verifying the contents (eg O= field) which is inherently dangerous.
Sam
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, (continued)
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, maurice Kellenaers, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Philipp Dunkel, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Teus Hagen, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Teus Hagen, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, maurice Kellenaers, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Teus Hagen, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Philipp Dunkel, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Philipp Dunkel, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Peter Williams, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, IanG, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Sam Johnston, 10/20/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Peter Williams, 10/21/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Philipp Dunkel, 10/16/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Tomáš Trnka, 10/17/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Sam Johnston, 10/18/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Philipp Dunkel, 10/18/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Peter Williams, 10/18/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, IanG, 10/18/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Peter Williams, 10/19/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, IanG, 10/19/2008
- Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21 October 12pm UTC, Sam Johnston, 10/20/2008
Archive powered by MHonArc 2.6.16.