RE: draft-turner-caclearanceconstraints-01.txt
Tom Gindin <tgindin@us.ibm.com> Fri, 24 October 2008 00:42 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 59A793A68B3 for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 23 Oct 2008 17:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level:
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 2z-VSAgbHC+Y for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 23 Oct 2008 17:42:00 -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 63CD83A67A8 for <pkix-archive@ietf.org>; Thu, 23 Oct 2008 17:41:58 -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 m9O0D48n054123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 17:13:04 -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 m9O0D48j054122; Thu, 23 Oct 2008 17:13:04 -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 e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O0Cq7p054109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Thu, 23 Oct 2008 17:13:03 -0700 (MST) (envelope-from tgindin@us.ibm.com)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9O0FOab000716 for <ietf-pkix@imc.org>; Thu, 23 Oct 2008 20:15:24 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9O0CUcO103522 for <ietf-pkix@imc.org>; Thu, 23 Oct 2008 20:12:30 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9O0CQCQ031852 for <ietf-pkix@imc.org>; Thu, 23 Oct 2008 20:12:26 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9O0CQM9031849; Thu, 23 Oct 2008 20:12:26 -0400
In-Reply-To: <FAD1CF17F2A45B43ADE04E140BA83D487A4864@scygexch1.cygnacom.com>
To: Santosh Chokhani <SChokhani@cygnacom.com>
Cc: ietf-pkix@imc.org
MIME-Version: 1.0
Subject: RE: draft-turner-caclearanceconstraints-01.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <tgindin@us.ibm.com>
Message-ID: <OF8A5580BB.950BB2EE-ON852574EB.0051D6D4-852574EC.00012779@us.ibm.com>
Date: Thu, 23 Oct 2008 20:12:28 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 10/23/2008 20:12:29, Serialize complete at 10/23/2008 20:12:29
Content-Type: text/plain; charset="US-ASCII"
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: This brings up another question. Does it make more sense for the intersection to be defined based on policyID or on SecurityCategory.Type? SecurityCategory.Type is far more likely to be reused, and a few syntax/intersection-semantic pairs could be predefined such as opaque string, opaque object ID, and object ID with prefix match. Since drafting this, I've noticed your comments about SecurityCategory. It is true that the "intersection rule" is the main thing in this draft which is more trouble than it's worth. Tom Gindin "Santosh Chokhani" <SChokhani@cygnacom.com> Sent by: owner-ietf-pkix@mail.imc.org 10/23/2008 09:16 AM To <ietf-pkix@imc.org> cc Subject RE: draft-turner-caclearanceconstraints-01.txt Tom, Thanks for your input. If this is adopted as a work item, we will consider your suggestion. Some of the things that come to mind are casting the security categories structure concretely or giving 1 or 2 examples. -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Wednesday, October 22, 2008 9:02 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org; stefans@microsoft.com Subject: RE: draft-turner-caclearanceconstraints-01.txt Santosh: I have to mainly agree with Stefan about this. I cannot see how to implement general purpose code to handle securityCategories without a rule governing policyID's whose security policy is unknown to the relying party. My own guess (although without much background in this area) is that the desired final condition in such a case is either for all securityCategories for such a policyID to be eliminated from effective-clearance, or for the Clearance containing such a policyID to be eliminated if any SecurityCategory values are encountered in the end-entity certificate. Such an algorithm could probably be implemented with an "SPI" interface, at least in Java. That's still a lot of work for this purpose, and defining default types of SecurityCategory with known intersection characteristics might be worthwhile. The current algorithm, with no defined handling for unknown policyID's, can't be implemented robustly. Tom Gindin "Santosh Chokhani" <SChokhani@cygnacom.com> Sent by: owner-ietf-pkix@mail.imc.org 10/22/2008 12:26 PM To <ietf-pkix@imc.org> cc 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. -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Wednesday, October 22, 2008 10:40 AM To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace Cc: ietf-pkix@imc.org Subject: RE: draft-turner-caclearanceconstraints-01.txt The major problem I have is that there is no set logic for the constraints processing. I have been told that there are current implementations of this and that this fact itself should prove that it is implementable. It is however my strong guess that current implementations work only because they assume no difference in calculating intersections of SecurityCategories for different known PolicyIDs. The problem comes when someone introduce a PolicyID which defines a different intersection logic or order of classes. The only way I can accept that Policy ID is to write new code. There is a huge difference between allowing inclusion of different policy OIDs, than to allow then to define individual path processing logic. Just imagine if every certificate policy OID was allowed to specify individual mapping logic (Like policy A is equal to policy B,C and D), and then expect the path processing code to learn the mapping logic for each and every Policy OID. I don't think anyone would consider that a good architecture and protocol design to standardize. But as far as I read it, this is precisely what the current CA clearance constraints proposal wants us to do. 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 Turner, Sean P. > Sent: den 14 oktober 2008 14:59 > To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace' > Cc: ietf-pkix@imc.org > Subject: RE: draft-turner-caclearanceconstraints-01.txt > > > > I just wanted to add that the ID does not address relationships between > security policies. It only addresses whether the EE's asserted > clearance is > within the issuer's allowed clearance set. > > spt > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani > Sent: Monday, October 13, 2008 10:33 AM > To: Timothy J. Miller; Carl Wallace > Cc: ietf-pkix@imc.org > Subject: RE: draft-turner-caclearanceconstraints-01.txt > > > Differences in various policies are articulated using the > security policy OID in the clearance structure that has been > accepted by the Internet Standards Community. > > In addition, clearance is a well defined mathematical concept > and formalized using lattice structure. Within a security > policy, Clearance consists of a hierarchical sensitivity level > and non-hierarchical category set. Two clearances within a > security can be ordered or can be incomparable based on simple > and well-defines mathematical rules. > > People in other parts of IETF are using these concepts to label > the data and make information flow decisions. > > Some pioneering work has been done in the technical community > (albeit not exposed to the IETF) in the area of comparing > clearances of two security policies. > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- > pkix@mail.imc.org] > On Behalf Of Timothy J. Miller > Sent: Monday, October 13, 2008 10:03 AM > To: Carl Wallace > Cc: ietf-pkix@imc.org > Subject: Re: draft-turner-caclearanceconstraints-01.txt > > Carl Wallace wrote: > > I vote yes to adopting this as a PKIX work item. Specification > details > > can be resolved after the draft is accepted as a working group draft. > > Can we even say for certain that clearance is a consistent > enough concept within and across jurisdictions to enable a > single logic for constraint processing? I'd argue not. > > E.g., RFC3281 talks about "the" basic clearance hierarchy, which > doesn't > > even exist. What's the relationship between NATO CONFIDENTIAL > and US UNCLASSIFIED CONTROLLED INFORMATION? How about US UCI > and US FOR OFFICIAL USE ONLY? US SECRET/NOFOREIGN? US TS/SCI > and TS/SAP? And that's without even getting into the obscure > corners of the US alone. > > What I'm trying to say is that classification is *not* a strict > hierarchy. It's semi-structured. We have trouble enough > figuring this stuff out in the real world without having to > write code for it. :) > > Presuming I have a vote, I vote no. > > -- Tim >
- draft-turner-caclearanceconstraints-01.txt Stephen Kent
- RE: draft-turner-caclearanceconstraints-01.txt Turner, Sean P.
- RE: draft-turner-caclearanceconstraints-01.txt Turner, Sean P.
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Reddy, Raksha Patel
- RE: draft-turner-caclearanceconstraints-01.txt Russ Housley
- Re: draft-turner-caclearanceconstraints-01.txt Kurt Zeilenga
- RE: draft-turner-caclearanceconstraints-01.txt Ashmore, Samuel R.
- Re: draft-turner-caclearanceconstraints-01.txt Stephen Farrell
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Denis Pinkas
- Re: draft-turner-caclearanceconstraints-01.txt Yoav Nir
- What are certificates fundamentally all about? [w… Stephen Wilson
- RE: draft-turner-caclearanceconstraints-01.txt Carl Wallace
- Re: What are certificates fundamentally all about… Timothy J. Miller
- Re: draft-turner-caclearanceconstraints-01.txt Timothy J. Miller
- RE: What are certificates fundamentally all about… Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- Re: What are certificates fundamentally all about… Stephen Wilson
- Re: What are certificates fundamentally all about… Stephen Kent
- RE: draft-turner-caclearanceconstraints-01.txt Turner, Sean P.
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Tom Gindin
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Russ Housley
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Tom Gindin
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- Re: draft-turner-caclearanceconstraints-01.txt Timothy J. Miller
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- Re: draft-turner-caclearanceconstraints-01.txt Timothy J. Miller
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Stefan Santesson
- RE: draft-turner-caclearanceconstraints-01.txt Tom Gindin
- RE: draft-turner-caclearanceconstraints-01.txt Santosh Chokhani
- RE: draft-turner-caclearanceconstraints-01.txt Tom Gindin