RE: draft-turner-caclearanceconstraints-01.txt

Tom Gindin <tgindin@us.ibm.com> Thu, 30 October 2008 01:11 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 4F0E33A68C5 for <ietfarch-pkix-archive@core3.amsl.com>; Wed, 29 Oct 2008 18:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 Ejrp8vrlpySZ for <ietfarch-pkix-archive@core3.amsl.com>; Wed, 29 Oct 2008 18:11:24 -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 58EF13A6862 for <pkix-archive@ietf.org>; Wed, 29 Oct 2008 18:11:22 -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 m9U0Zb1m097345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 17:35:37 -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 m9U0ZbWZ097344; Wed, 29 Oct 2008 17:35:37 -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 e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U0ZPK8097309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Wed, 29 Oct 2008 17:35:36 -0700 (MST) (envelope-from tgindin@us.ibm.com)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9U0ZMuU005936 for <ietf-pkix@imc.org>; Wed, 29 Oct 2008 20:35:22 -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 m9U0ZKDo077398 for <ietf-pkix@imc.org>; Wed, 29 Oct 2008 20:35:22 -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 m9U0ZDgu014622 for <ietf-pkix@imc.org>; Wed, 29 Oct 2008 20:35:13 -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 m9U0ZDi8014618; Wed, 29 Oct 2008 20:35:13 -0400
In-Reply-To: <FAD1CF17F2A45B43ADE04E140BA83D48849DB7@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: <OF8DE9C859.27141592-ON852574F1.00605DB0-852574F2.00033BF5@us.ibm.com>
Date: Wed, 29 Oct 2008 20:35:18 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 10/29/2008 20:35:19, Serialize complete at 10/29/2008 20:35:19
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:

        Since criterion D is explicitly dependent on 
SecurityCategory.Type, only a few examples will fit into the final version 
of this draft.  I don't think you need an exhaustive catalogue of its 
possibilities to go forward.  BIT STRING probably deserves an explicit 
rule of its own, namely the logical AND of the the two values, considering 
the shorter one as padded with zeroes.  Enumerated integers, and string 
values which are intended as effectively enumerated sets, cannot be 
subjected IMHO to rules which are both elaborate and standardized. 
Character strings considered as opaque values, or object ID's considered 
as such, are processed by the default of binary equality.

                Tom Gindin





"Santosh Chokhani" <SChokhani@cygnacom.com> 
Sent by: owner-ietf-pkix@mail.imc.org
10/29/2008 08:54 AM

To
<ietf-pkix@imc.org>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Tom,

Thanks.

A, B, and C is what I have planned for.

D is the area, I need to decide what types of values to support.  Some
of the times, values may be bit string or enumerated integers and hence
binary comparison may not be valid.

-----Original Message-----
From: Tom Gindin [mailto:tgindin@us.ibm.com] 
Sent: Tuesday, October 28, 2008 8:15 PM
To: Stefan Santesson
Cc: ietf-pkix@imc.org; Santosh Chokhani
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Stefan, Santosh:

        I would like to put forward a set of processing rules which
might 
actually be implementable for the "intersection" problem here:
A)      The intersection of two SecurityCategory entries with different 
SecurityCategory.Type is empty
B)      The intersection of two SecurityCategory entries with the same 
Type and Value is an entry with that Type and Value
C)      Any relying party unfamiliar with a given SecurityCategory.Type 
SHOULD treat the intersection of two SecurityCategory entries with that 
Type and different Value as being empty
D)      A relying party familiar with a given SecurityCategory.Type MAY 
process the intersection of two SecurityCategory entries with that Type 
and different Value according to customized rules for that type
        One customized type which I would suggest is "prefixable OID".
The 
intersection of two values of this type is the longer of the two if the 
shorter one is its leading binary substring, and is empty otherwise.

                Tom Gindin





Stefan Santesson <stefans@microsoft.com> 
Sent by: owner-ietf-pkix@mail.imc.org
10/24/2008 10:00 PM

To
Santosh Chokhani <SChokhani@cygnacom.com>, "ietf-pkix@imc.org" 
<ietf-pkix@imc.org>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Santosh,

What you suggest comes closer to the exercise I think need to be done 
before we decide what to do with this.

To standardize constraints with undefined processing rules feels to me 
like wanting to have one's cake and eat it too.
I think it is absolutely necessary to limit the logic so that an 
implementation can process any legal data within it. Otherwise the basic

idea with having a standard seems a bit lost.

Now, processing all data does not mean that you know the meaning of all 
data, but at least you should be able to process it and hand it over to 
the next layer.

I would also like to have some rationales clarified, but I will ask for 
that in a separate thread.


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 24 oktober 2008 15:52
> To: ietf-pkix@imc.org
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Stefan,
>
> As stated in other strands of this thread, this will be handled by
> enhancing the I-D for a specific set of syntaxes of security
categories
> or by deprecating the security categories from the clearance
> constraints.  The latter can obviate the need for taking the
> intersection of security categories.
>
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-
> pkix@mail.imc.org]
> On Behalf Of Stefan Santesson
> Sent: Friday, October 24, 2008 9:27 AM
> To: Timothy J. Miller; Russ Housley
> Cc: ietf-pkix@imc.org
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Thanks for putting such good words to it :)
>
> Yes, that sounds very much like what I meant.
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: Timothy J. Miller [mailto:tmiller@mitre.org]
> > Sent: den 24 oktober 2008 15:23
> > To: Russ Housley
> > Cc: Stefan Santesson; ietf-pkix@imc.org
> > Subject: Re: draft-turner-caclearanceconstraints-01.txt
> >
> > Russ Housley wrote:
> >
> > > Where does the document say anything about mapping between
security
> > > policies?
> >
> > I don't think that's what he means.  I think what he's driving at
is:
> > how does a single vendor writing a single chaining library do it
such
> > that the code works under any arbitrary intersection logic the end
> user
> > may specify?
> >
> > Did I get that right, Stefan?
> >
> > -- Tim
>