RE: draft-turner-caclearanceconstraints-01.txt

["Santosh Chokhani" <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, October 22, 2008 9:02 PM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
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" <[e-mail]> 
Sent by: [e-mail]
10/22/2008 12:26 PM

To
<[e-mail]>
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:[e-mail]] 
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [e-mail]
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: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Turner, Sean P.
> Sent: den 14 oktober 2008 14:59
> To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> Cc: [e-mail]
> 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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> Sent: Monday, October 13, 2008 10:33 AM
> To: Timothy J. Miller; Carl Wallace
> Cc: [e-mail]
> 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: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Timothy J. Miller
> Sent: Monday, October 13, 2008 10:03 AM
> To: Carl Wallace
> Cc: [e-mail]
> 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
>