RE: draft-turner-caclearanceconstraints-01.txt

[Stefan Santesson <[e-mail]>]

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
>