RE: draft-turner-caclearanceconstraints-01.txt

Stefan Santesson <stefans@microsoft.com> Thu, 23 October 2008 13:00 UTC

Return-Path: <owner-ietf-pkix@mail.imc.org>
X-Original-To: ietfarch-pkix-archive@core3.amsl.com
Delivered-To: ietfarch-pkix-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85843A6A3A for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 23 Oct 2008 06:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.545
X-Spam-Level:
X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt-Gj7MiMEVB for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 23 Oct 2008 06:00:30 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0B8A13A6C1A for <pkix-archive@ietf.org>; Thu, 23 Oct 2008 06:00:29 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NCRp8q004366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 05:27:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NCRpMC004365; Thu, 23 Oct 2008 05:27:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NCRc2d004337 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-pkix@imc.org>; Thu, 23 Oct 2008 05:27:49 -0700 (MST) (envelope-from stefans@microsoft.com)
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 23 Oct 2008 13:27:37 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Thu, 23 Oct 2008 13:27:37 +0100
From: Stefan Santesson <stefans@microsoft.com>
To: Santosh Chokhani <SChokhani@cygnacom.com>, "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Date: Thu, 23 Oct 2008 13:27:36 +0100
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AcktPo1xbBGJg+IZTZOD+0tgp11GwAAAKwnQAC8iOcABlZKT4AAD3NvgACVIDNA=
Message-ID: <9F11911AED01D24BAA1C2355723C3D32195A6F3728@EA-EXMSG-C332.europe.corp.microsoft.com>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <9F11911AED01D24BAA1C2355723C3D3218DDA55C66@EA-EXMSG-C332.europe.corp.microsoft.com> <FAD1CF17F2A45B43ADE04E140BA83D487A42B0@scygexch1.cygnacom.com> <48F35523.7000409@mitre.org> <FAD1CF17F2A45B43ADE04E140BA83D487A42FD@scygexch1.cygnacom.com> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <9F11911AED01D24BAA1C2355723C3D3218DDC3E0B3@EA-EXMSG-C332.europe.corp.microsoft.com> <FAD1CF17F2A45B43ADE04E140BA83D487A47D0@scygexch1.cygnacom.com>
In-Reply-To: <FAD1CF17F2A45B43ADE04E140BA83D487A47D0@scygexch1.cygnacom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Santosh,

> One answer to your question will be that this can be sorted out during
> the comment period.

I have thought about that, but I would prefer not.
The reason is that this is a fundamental aspect of the standard and I want to see that you can build a reasonable solution to a reasonable problem before I would support to standardize it.

>
> But, specific answer to your question is that in all cases logical
> intersection of categories is computed.  Specific details beyond that
> will depend on how the categories are encoded.


I don't understand what you mean here. The current specification makes clear that the intersection logic can change in any way for each Policy ID.
There is no defined "default" logic and no way to tell if a PolicyID alters this logic.
As such I can't write a code that can perform the fundamental intersection logic of the protocol.
I would have to build a solution that allows every "user" to invoke custom code for every PolicyID.

That to me is a too complex response to this problem, especially since I don't think this problem should be handled in certificates at all.
And that if this would be done in certificates anyway, that we at least should skip the constraints logic.

I miss the balance discussion. Writing a new standard comes with a cost. We are potentially confusing the community with another specification. We potentially promote making PKI more complex. We potentially promote Certificates to be the right place to carry clearance information.

Just because something could be useful in some corner cases, does not make it the right thing to standardize.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-
> pkix@mail.imc.org] On Behalf Of Santosh Chokhani
> Sent: den 22 oktober 2008 18:26
> To: ietf-pkix@imc.org
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Stefan,
>
> One answer to your question will be that this can be sorted out during
> the comment period.
>
> But, specific answer to your question is that in all cases logical
> intersection of categories is computed.  Specific details beyond that
> will depend on how the categories are encoded.
>