RE: draft-turner-caclearanceconstraints-01.txt

[Stefan Santesson <[e-mail]>]

Russ,

Nowhere.

That was a hypothetical example of something that would be equally hard to implement if it was added into current path processing.
I was just trying to make a point :)


Let me see if I can clarify.

The current syntax includes SecurityCategory

     SecurityCategory ::= SEQUENCE {
       type      [0]  IMPLICIT OBJECT IDENTIFIER,
       value     [1]  ANY DEFINED BY type
     }

    - securityCategories provides additional authorization information.


So the semantics of the ClassList and Security category is defined by the policyID, and it is extensible.

     - policyId identifies the security policy to which the clearance
      relates.  The policyId indicates the semantics of the classList
      and securityCategory fields.



In the path processing logic I'm supposed to calculate the intersection of clearance of the certificates in the path

   Assuming a certification path consisting of n certificates, the
   effective-clearance for the subject of the end certificate is the
   intersection of Clearance in the subject certificate, Authority
   Clearance Constraints, if present, in trust anchor and all Authority
   Clearance Constraints present in intermediate certificates.


Now how do I calculate this intersection? Well 4.1.1.3 gives us the answer, but in short it requires me to process values of unknown semantics, unless I know the policyId.
I.e.:

       -- Calculate securityCategories intersection in accordance with
          guidelines associated with the security policy represented by
          the policyID.



That logic may also define mappings. E.g. the semantics for a given SecurityCategory may be equal to another SecurityCategory. There is at least nothing suggesting that this is not allowed.
All in all, I may need new code for each policyId, unless I know them beforehand and the semantics they define.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: den 23 oktober 2008 16:20
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
> Stefan:
>
> Where does the document say anything about mapping between security
> policies?
>
> Russ
>
> At 10:40 AM 10/22/2008, Stefan Santesson wrote:
>
> >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
> > >
>