Subject: draft-turner-caclearanceconstraints-01.txt

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Oct 2008 16:24:24 -0400

It appears to have been two months since there was any PKIX list 
discussion of this document. In Dublin it was agreed that we would 
conduct a straw poll on whether to adopt this as a WG item, but I 
failed to do so prior to leaving for a week-long meeting in NZ and 
3-week vacation in KE.  My bad.

So, I'd like to initiate a 1-week straw poll starting 10/3.

Sean, the minutes indicated that you would tell me what status you 
are seeking for the document, and I have no record of a message from 
you on that topic, so please provide that vital piece of info to the 
list before we start the poll.

Thanks,

Steve

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 1 Oct 2008 17:03:35 -0400

We would like the document to be a standards track document.
 
spt

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2008 4:24 PM
To: [email-masked]
Subject: draft-turner-caclearanceconstraints-01.txt

It appears to have been two months since there was any PKIX list discussion
of this document. In Dublin it was agreed that we would conduct a straw poll
on whether to adopt this as a WG item, but I failed to do so prior to
leaving for a week-long meeting in NZ and 3-week vacation in KE.  My bad.

Sean, the minutes indicated that you would tell me what status you are
seeking for the document, and I have no record of a message from you on that
topic, so please provide that vital piece of info to the list before we
start the poll.

Thanks,

Steve

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 3 Oct 2008 11:57:56 -0400

I vote yes for adoption as a WG item.
 
Also note that we requested standard track.
 
spt

  _____  

Thanks,

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Oct 2008 12:15:21 -0400

I also vote yes for adoption as a Standards Track WG item.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Turner, Sean P.
Sent: Friday, October 03, 2008 11:58 AM
To: [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

spt

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Kent
	Sent: Wednesday, October 01, 2008 4:24 PM
	To: [email-masked]
	Subject: draft-turner-caclearanceconstraints-01.txt

	It appears to have been two months since there was any PKIX list
discussion of this document. In Dublin it was agreed that we would
conduct a straw poll on whether to adopt this as a WG item, but I failed
to do so prior to leaving for a week-long meeting in NZ and 3-week
vacation in KE.  My bad.

	Sean, the minutes indicated that you would tell me what status
you are seeking for the document, and I have no record of a message from
you on that topic, so please provide that vital piece of info to the
list before we start the poll.

	Thanks,

	Steve

---

From: "Reddy, Raksha Patel" <[email-masked]>
Date: Fri, 3 Oct 2008 12:55:39 -0400

I also vote yes for this I-D to be adopted as a PKIX WG item.
 
Raksha Reddy

 
 
spt

	Thanks,

	Steve

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 3 Oct 2008 17:34:24 -0700

> So, I'd like to initiate a 1-week straw poll starting 10/3.

I support the WG picking this work item up, for eventual publication  
on the Standards Track.

-- Kurt

---

From: "Ashmore, Samuel R." <[email-masked]>
Date: Mon, 6 Oct 2008 12:57:29 -0400

I vote Yes for this document to be approved.
 
--Samuel Ashmore

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Turner, Sean P.
Sent: Wednesday, October 01, 2008 5:04 PM
To: 'Stephen Kent'; [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

spt

	Thanks,

	Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Oct 2008 15:53:04 +0100

I agree with taking this on.

>From a quick scan, I'd prefer if the algorithm was presented
in pseudo-code, I think that might be more useful.

Stephen.

Stephen Kent wrote:
> *Sean*, the minutes indicated that you would tell me what status you are
> seeking for the document, and I have no record of a message from you on
> that topic, so please provide that vital piece of info to the list
> before we start the poll.
> 
> Thanks,
> 
> Steve

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 7 Oct 2008 16:40:54 +0100

I vote NO to adopting this work as a PKIX work item.

I do vote for a continued debate on the rationale for this proposal but I have yet not seen any good motivation for doing this work.

The rational for my NO vote is:

1)      To start with, a certificate is a very bad place to manage clearance. I can at most agree to it's use in AA certificates but clearance is in its nature fundamentally different from Public Key certificates as the certificate is an assertion of an entity's key and identity, which is generic and static, while clearance is context specific and dynamic.

2)      If clearance would make it into certificates, then that should be more than enough that we reasonable could handle as a standard. To specify constraints for such information is to ask for big trouble.

Elaborating on the difficulties to specify clearance constraints I would like to highlight some quotes from the draft:

The draft is taking several shortcuts when it comes to clearance constraints processing.
The class list is specified but at the same time defined within the context of PolicyId. This means that there is no generic way to compare ClassList bits, This is highlighted by the following quote from 4.1.1.3:

       -- Calculate securityCategories intersection in accordance with

          guidelines associated with the security policy represented by

          the policyID.

So the logic for clearance constraints processing is performed per PolicyId but the logic may be different for every PolicyId.
In my world, this does not fly and is not implementable.

I also have a number of other problems:

*         This draft makes clearance processing authoritative over accepting certificate paths. I foresee problems with legacy implementations of PKI:

   If more than one entry with

   the same policyId is present in AuthorityClearanceConstraints

   certificate extension, the certification path is rejected.

*         This draft mandates processing of extensions in TA certificates (root) which can be argued to be incompatible with RFC 3280

Conclusion:
Before this work is accepted as work group item, it must show that clearance constraints processing is possible in a reasonable and meaningful manner, and hence is worth working on.
If we decide to work on this item, I foresee a major design commitment for the PKIX group and an even bigger commitment on behalf of implementers.
As such, I also encourage use cases that motivates the effort.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: den 1 oktober 2008 22:24
To: [email-masked]
Subject: draft-turner-caclearanceconstraints-01.txt

It appears to have been two months since there was any PKIX list discussion of this document. In Dublin it was agreed that we would conduct a straw poll on whether to adopt this as a WG item, but I failed to do so prior to leaving for a week-long meeting in NZ and 3-week vacation in KE.  My bad.

Sean, the minutes indicated that you would tell me what status you are seeking for the document, and I have no record of a message from you on that topic, so please provide that vital piece of info to the list before we start the poll.

Thanks,

Steve

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 10 Oct 2008 09:10:52 +0200

I support the NO vote from Stefan.

I concur that a certificate is not the right place to manage clearances.

Clearances constraints should be managed within validation policies rather than CA certificates.

This topic is related to draft-ietf-pkix-ta-mgmt-reqs-01.txt 
for which I have sent comments in response to the WGLC.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : Stephen Kent,[email-masked] 
Date : 2008-10-07, 17:40:54
Sujet : RE: draft-turner-caclearanceconstraints-01.txt

1)      To start with, a certificate is a very bad place to manage clearance. I can at most agree to it’s use in AA certificates but clearance is in its nature fundamentally different from Public Key certificates as the certificate is an assertion of an entity’s key and identity, which is generic and static, while clearance is context specific and dynamic.
·         This draft makes clearance processing authoritative over accepting certificate paths. I foresee problems with legacy implementations of PKI:
·         This draft mandates processing of extensions in TA certificates (root) which can be argued to be incompatible with RFC 3280

---

From: Yoav Nir <[email-masked]>
Date: Fri, 10 Oct 2008 22:17:09 +0200

+1

On Oct 7, 2008, at 5:40 PM, Stefan Santesson wrote:

> I do vote for a continued debate on the rationale for this proposal  
> but I have yet not seen any good motivation for doing this work.
>
> 1)      To start with, a certificate is a very bad place to manage  
> clearance. I can at most agree to it’s use in AA certificates but  
> clearance is in its nature fundamentally different from Public Key  
> certificates as the certificate is an assertion of an entity’s key  
> and identity, which is generic and static, while clearance is  
> context specific and dynamic.
> 2)      If clearance would make it into certificates, then that  
> should be more than enough that we reasonable could handle as a  
> standard. To specify constraints for such information is to ask for  
> big trouble.
>
> Elaborating on the difficulties to specify clearance constraints I  
> would like to highlight some quotes from the draft:
>
> The class list is specified but at the same time defined within the  
> context of PolicyId. This means that there is no generic way to  
> compare ClassList bits, This is highlighted by the following quote  
> from 4.1.1.3:
>
> So the logic for clearance constraints processing is performed per  
> PolicyId but the logic may be different for every PolicyId.
> ·         This draft makes clearance processing authoritative over  
> accepting certificate paths. I foresee problems with legacy  
> implementations of PKI:
>
> ·         This draft mandates processing of extensions in TA  
> certificates (root) which can be argued to be incompatible with RFC  
> 3280
>
>
> Conclusion:
> Before this work is accepted as work group item, it must show that  
> clearance constraints processing is possible in a reasonable and  
> meaningful manner, and hence is worth working on.
> If we decide to work on this item, I foresee a major design  
> commitment for the PKIX group and an even bigger commitment on  
> behalf of implementers.
> failed to do so prior to leaving for a week-long meeting in NZ and 3- 
> week vacation in KE.  My bad.
>
> Scanned by Check Point Total Security Gateway.
>

---

From: Stephen Wilson <[email-masked]>
Date: Sat, 11 Oct 2008 09:15:32 +1100

Stefan Santesson wrote (quoted in reverse):
> 2) If clearance would make it into certificates, then that should 
> be more than enough that we reasonable could handle as a standard. To 
> specify constraints for such information is to ask for big trouble.

I suspect you're right about that -- too much to bear in a standard.

However I don't agree that:

> 1) ... a certificate is a very bad place to manage 
> clearance. [Clearance] is in its nature fundamentally different from Public 
> Key certificates as the certificate is an assertion of an entity’s key and 
> identity, which is generic and static ... 

Back in March at the NIST IDtrust2008 conference I presented a paper 
called "Public Key Superstructure" in which I argued for an adjusted 
view of what public key certificates are "fundamentally" all about.  I 
submit that the view that PKCs are purely an assertion of an entity’s 
key and [generic and static] identity has led to most of the historic 
problems with PKI, because it predicts a single all-purpose generic 
certificate and in the process, overloads a single "identity".

My paper on these issues is at 
http://middleware.internet2.edu/idtrust/2008/papers/07-wilson-public-key-superstructure.pdf

In line with contemporary thinking about identity plurality (as per e.g. 
The Laws of Identity) I think it's more powerful to construct multiple 
PKCs with each representing a different identity in a particular context.

Then you can subtly adjust the conception of a PKC as being "an 
assertion of an entity’s key and a RELATIVELY STATIC identity IN A 
DEFINED CONTEXT".  A flexible interpretation of "identity in a defined 
context" embraces things like my identity as an chartered engineer, my 
identity as a business owner, my identity as a health insurance 
subscriber, my identity as a bank account holder.  In each of these 
scenarios, it would be very powerful for me to carry a separate 
dedicated certificate with which to sign specific types of transactions 
(e.g. engineering test reports, tax returns, health insurance claims, 
and payment instructions respectively).  That is, four different 
certificates all independently registered and managed, tightly coupled 
to regular customer relationship management processes, probably carried 
on separate smartcards.

In my Public Key Superstructure paper I argued that it might be clearer 
to refer to these 'identities' as "Relationships"; in practice, the 
relationship is vouched for by an RA that has some connection to the 
Subject.  The Policy OID suffices to uniquely point to a comprehensive 
definition of exactly what that relationship is, the processes that 
underpin it, the context in which the relationship is meaningful and, by 
extension, the applications for which the PKC is meaningful.

To illustrate the point, I don't actually see any reason in principle 
why a PKC could not be used to assert my identity (or relationship) as 
'a person cleared to Top Secret' so long as that relationship is 
relatively long lived; say a few months.  Path validation is a cinch: 
the relationship I would have express in my PKC is with a particular 
vetting agency, which would appear in the path, with a Policy OID in the 
Subject PKC that specifies the clearance protocol.  The Public Key of 
the vetting agency -- or a higher Root Key -- would be the trust anchor 
needed in a whole class of applications processing my digital signature 
applied to Secret documents.

Cheers,

Stephen Wilson
Managing Director
Lockstep Technologies

Phone +61 (0)414 488 851

www.lockstep.com.au/technologies
-------------------
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase    2008
  * AusIndustry COMET Grant Recipient  2007
  * ICT Secrets of Innovation Finalist  2007
  * Anthill / PwC Cool Company Finalist  2007
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.

---

From: "Carl Wallace" <[email-masked]>
Date: Sat, 11 Oct 2008 09:07:17 -0400

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.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Tuesday, October 07, 2008 11:41 AM
To: Stephen Kent; [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

I do vote for a continued debate on the rationale for this proposal but
I have yet not seen any good motivation for doing this work.

1)      To start with, a certificate is a very bad place to manage
clearance. I can at most agree to it's use in AA certificates but
clearance is in its nature fundamentally different from Public Key
certificates as the certificate is an assertion of an entity's key and
identity, which is generic and static, while clearance is context
specific and dynamic.

Elaborating on the difficulties to specify clearance constraints I would
like to highlight some quotes from the draft:

The draft is taking several shortcuts when it comes to clearance
constraints processing.

The class list is specified but at the same time defined within the
context of PolicyId. This means that there is no generic way to compare
ClassList bits, This is highlighted by the following quote from 4.1.1.3:

*         This draft makes clearance processing authoritative over
accepting certificate paths. I foresee problems with legacy
implementations of PKI:

*         This draft mandates processing of extensions in TA
certificates (root) which can be argued to be incompatible with RFC 3280

Conclusion: 

If we decide to work on this item, I foresee a major design commitment
for the PKIX group and an even bigger commitment on behalf of
implementers.

 

Stefan Santesson

Senior Program Manager

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: den 1 oktober 2008 22:24
To: [email-masked]
Subject: draft-turner-caclearanceconstraints-01.txt

Thanks,

Steve

---

From: "Timothy J. Miller" <[email-masked]>
Date: Mon, 13 Oct 2008 08:40:06 -0500

> to regular customer relationship management processes, probably carried 

We have that; it's called SPKI/SDSI.  :)

> applied to Secret documents.

However, that's a *lot* of work, infrastructure, and code needed to 
communicate an attribute the relying party can more simply look up in a 
directory at the time of the transaction, or that the relying party can 
have communicated to it as part of an authorization token (InfoCard, 
OpenID, SAML, WS-*, etc.).

These schemes have the advantage of accommodating both static, 
relatively static, and highly dynamic attributes, *plus* supports 
non-person attributes such as environment level, current threat posture, 
etc.

In short, you have to have the directory anyway for at least some 
attributes, so it's simpler in the long run to stuff *all* the 
attributes in there.

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Mon, 13 Oct 2008 09:03:15 -0500

> 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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 13 Oct 2008 10:22:59 -0400

There are many ways to promulgate privileges and authorizations.  Two of
these methods are public key certificates and attribute certificates.

The I-D deals with how to process the clearance information in a chain
of public key and attribute certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Timothy J. Miller
Sent: Monday, October 13, 2008 9:40 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: What are certificates fundamentally all about? [was:
draft-turner-caclearanceconstraints-01.txt]

Stephen Wilson wrote:

> assertion of an entity's key and a RELATIVELY STATIC identity IN A 

etc.

-- Tim

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 13 Oct 2008 10:32:41 -0400

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Timothy J. Miller
Sent: Monday, October 13, 2008 10:03 AM
To: Carl Wallace
Cc: [email-masked]
Subject: Re: draft-turner-caclearanceconstraints-01.txt

-- Tim

---

From: Stephen Wilson <[email-masked]>
Date: Tue, 14 Oct 2008 03:19:04 +1100

Timothy J. Miller wrote:
>> dedicated certificate with which to sign specific types of 
>> transactions (e.g. engineering test reports, tax returns, health 
>> insurance claims, and payment instructions respectively).  That is, 
>> four different certificates all independently registered and managed, 
>> tightly coupled to regular customer relationship management processes, 
>> probably carried on separate smartcards.
> 

Not too sure if your smiley was a 'knowing' cheeky smiley?!  In "Public 
Key Superstructure" I address SPKI and argue that it's not really simple 
enough.  I believe SPKI retains at its core the orthodox misconception 
that authentication and authorisation should be constructed on the back 
of a single superior identification.

>> vetting agency, which would appear in the path, with a Policy OID in 
>> the Subject PKC that specifies the clearance protocol.  The Public Key 
>> of the vetting agency -- or a higher Root Key -- would be the trust 
>> anchor needed in a whole class of applications processing my digital 
>> signature applied to Secret documents.
> 

The directory is fine if the transactions are only ever processed in 
real time -- that is, you're never interested in checking an old 
signature on a transaction from months or years ago.  In that sort of 
case, what method exists for freezing the state of an attribute-rich 
directory for all time, so that all conceivable relying parties can at 
any time down the track look up the attribute of interest for all senders?

The very cool and unique thing about PKCs when attributes are in the 
certificate is that they bake the attributes into each transaction, such 
that you only need a CRL [or delta CRLs] to check a transaction, no 
matter how old it is.  Even long after all PKCs have expired.

This longevity is not important for all transaction settings, so I agree 
that the attribute-rich directory is sometimes a better fit.  But in 
e-health, digital mortgages, electronic trade documentation, pension 
funds management, insurance and similar fields, you cannot beat 
PKCs-with-included-attributes for elegance and efficient processing.

Cheers,

Stephen Wilson
Lockstep.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Oct 2008 12:12:19 -0400

At 8:40 AM -0500 10/13/08, Timothy J. Miller wrote:
>>DEFINED CONTEXT".  A flexible interpretation of "identity in a 
>>defined context" embraces things like my identity as an chartered 
>>engineer, my identity as a business owner, my identity as a health 
>>insurance subscriber, my identity as a bank account holder.  In 
>>each of these scenarios, it would be very powerful for me to carry 
>>a separate dedicated certificate with which to sign specific types 
>>of transactions (e.g. engineering test reports, tax returns, health 
>>four different certificates all independently registered and 
>>managed, tightly coupled to regular customer relationship 
>>management processes, probably carried on separate smartcards.
>

No, it's called not VeriSign :-).

I authored a paper in 1997 that made the same argument as Stephen 
Wilson did (maybe it's a Stephen thing). Moreover, there is a report 
published in 2003 by the National Academies Press ("Who Goes There? 
Authentication Through the Lens of Privacy?") that also observes that 
an individual does not have just one identity, and thus we ought not 
assume that a single cert will suffice to identify/authorize an 
individual.

Moreover, arguments that clearances are not sufficiently long-lived 
to be put into certs do not match lots of experience.  Basic 
clearance info (vs. compartments) tends to be very stable, for 
multiple years, in the the U.S. DoD.  They have issued certs 
containing clearance info for a while, and not found that clearance 
changes create undue CRL activity. They have issued certs with more 
than just basic clearance info, e.g., to secure phones and data 
encryption devices, and those too have proved to be long-lived. So we 
ought not waste time debating this aspect of the proposal, because 
there is enough experience to resolve these specific arguments.

Steve

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 14 Oct 2008 08:58:36 -0400

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: [email-masked] 
[mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Monday, October 13, 2008 10:33 AM
To: Timothy J. Miller; Carl Wallace
Cc: [email-masked]
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-----

> 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.

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.  :)

-- Tim

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 22 Oct 2008 15:40:15 +0100

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

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Turner, Sean P.
> Sent: den 14 oktober 2008 14:59
> To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> Cc: [email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 22 Oct 2008 12:26:09 -0400

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:[email-masked]] 
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [email-masked]
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

> [email-masked]]

---

From: Tom Gindin <[email-masked]>
Date: Wed, 22 Oct 2008 21:01:45 -0400

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" <[email-masked]> 
Sent by: [email-masked]
10/22/2008 12:26 PM

To
<[email-masked]>
cc

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

Stefan,

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Stefan Santesson
Senior Program Manager

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 23 Oct 2008 13:27:36 +0100

Santosh,

> One answer to your question will be that this can be sorted out during

I have thought about that, but I would prefer not.
The reason is that this is a fundamental aspect of the standard and I want to see that you can build a reasonable solution to a reasonable problem before I would support to standardize it.

> will depend on how the categories are encoded.

I don't understand what you mean here. The current specification makes clear that the intersection logic can change in any way for each Policy ID.
There is no defined "default" logic and no way to tell if a PolicyID alters this logic.
As such I can't write a code that can perform the fundamental intersection logic of the protocol.
I would have to build a solution that allows every "user" to invoke custom code for every PolicyID.

That to me is a too complex response to this problem, especially since I don't think this problem should be handled in certificates at all.
And that if this would be done in certificates anyway, that we at least should skip the constraints logic.

I miss the balance discussion. Writing a new standard comes with a cost. We are potentially confusing the community with another specification. We potentially promote making PKI more complex. We potentially promote Certificates to be the right place to carry clearance information.

Just because something could be useful in some corner cases, does not make it the right thing to standardize.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Santosh Chokhani
> Sent: den 22 oktober 2008 18:26
> To: [email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 23 Oct 2008 09:16:59 -0400

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:[email-masked]] 
Sent: Wednesday, October 22, 2008 9:02 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Santosh:

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

To
<[email-masked]>
cc

Subject

Stefan,

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Stefan Santesson
Senior Program Manager

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 23 Oct 2008 09:20:25 -0400

Stefan,

I realize that a generic structure for security categories can not be
implemented.

I hope you see the point that without casting the security categories
more concretely, I can not provide more detailed pseudo-code than saying
that take a set theoretic intersection.

If the work item is taken up, we would definitely look at option of
casting the security categories structure concretely or giving couple of
examples for different structures. 

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, October 23, 2008 8:28 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Santosh,

I have thought about that, but I would prefer not.
The reason is that this is a fundamental aspect of the standard and I
want to see that you can build a reasonable solution to a reasonable
problem before I would support to standardize it.

> will depend on how the categories are encoded.

I don't understand what you mean here. The current specification makes
clear that the intersection logic can change in any way for each Policy
ID.
There is no defined "default" logic and no way to tell if a PolicyID
alters this logic.
As such I can't write a code that can perform the fundamental
intersection logic of the protocol.
I would have to build a solution that allows every "user" to invoke
custom code for every PolicyID.

That to me is a too complex response to this problem, especially since I
don't think this problem should be handled in certificates at all.
And that if this would be done in certificates anyway, that we at least
should skip the constraints logic.

I miss the balance discussion. Writing a new standard comes with a cost.
We are potentially confusing the community with another specification.
We potentially promote making PKI more complex. We potentially promote
Certificates to be the right place to carry clearance information.

Just because something could be useful in some corner cases, does not
make it the right thing to standardize.

Stefan Santesson
Senior Program Manager

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Oct 2008 10:20:20 -0400

Stefan:

Where does the document say anything about mapping between security policies?

Russ

At 10:40 AM 10/22/2008, Stefan Santesson wrote:

>I have been told that there are current implementations of this and 
>that this fact itself should prove that it is implementable.
>policy OIDs, than to allow then to define individual path processing logic.
>
>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.
>
>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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 23 Oct 2008 15:51:18 +0100

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.:

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

> From: Russ Housley [mailto:[email-masked]]
> Sent: den 23 oktober 2008 16:20
> To: Stefan Santesson
> Cc: [email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 23 Oct 2008 16:41:47 -0400

Stefan,

If this work item is taken up, another option we should consider under
casting the categories structure is to deprecate the security
categories.  While we can not change the ASN.1 of the existing clearance
structure, security category deprecation can be achieved using one of
the following means:

1.  We can reject the certificate if categories are present in the
clearance constraints
2.  We can ignore the categories in the clearance constraints
3.  We can define a new structure for the clearance constraints so that
the clearance constraints only contain the classification levels and do
not contain categories.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Thursday, October 23, 2008 9:20 AM
To: [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Stefan,

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, October 23, 2008 8:28 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Santosh,

Stefan Santesson
Senior Program Manager

---

From: Tom Gindin <[email-masked]>
Date: Thu, 23 Oct 2008 20:12:28 -0400

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

10/23/2008 09:16 AM

To
<[email-masked]>
cc

Subject

Tom,

Thanks for your input.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 9:02 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Santosh:

                Tom Gindin

To
<[email-masked]>
cc

Subject

Stefan,

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Stefan Santesson
Senior Program Manager

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 24 Oct 2008 08:06:56 -0400

Tom,

I been thinking the same thing.  The OID in the type field should
dictate how to compute the intersection.

I am also thinking that we can define these for couple of types such as
use in some systems today and an approach this group may want to take
align with other work in the categories in IETF.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Thursday, October 23, 2008 8:12 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        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

To
<[email-masked]>
cc

Subject

Tom,

Thanks for your input.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 9:02 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Santosh:

                Tom Gindin

To
<[email-masked]>
cc

Subject

Stefan,

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Stefan Santesson
Senior Program Manager

---

From: "Timothy J. Miller" <[email-masked]>
Date: Fri, 24 Oct 2008 08:22:54 -0500

> Where does the document say anything about mapping between security 

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

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 24 Oct 2008 14:26:45 +0100

Thanks for putting such good words to it :)

Yes, that sounds very much like what I meant.

Stefan Santesson
Senior Program Manager

> From: Timothy J. Miller [mailto:[email-masked]]
> Sent: den 24 oktober 2008 15:23
> To: Russ Housley
> Cc: Stefan Santesson; [email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 24 Oct 2008 09:51:31 -0400

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Friday, October 24, 2008 9:27 AM
To: Timothy J. Miller; Russ Housley
Cc: [email-masked]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Stefan Santesson
Senior Program Manager

---

From: "Timothy J. Miller" <[email-masked]>
Date: Fri, 24 Oct 2008 10:10:47 -0500

> intersection of security categories.

IMHO, picking a couple of examples for category intersection doesn't 
solve the problem for coders, and might well be taken as implying that 
the examples are the only possibilities.

If these are the two options then I'd vote for going beyond deprecation 
and define clearance constraints *only* for sensitivity.  The constraint 
algorithm then becomes the much simpler task of finding the minimum 
value of classList in the chain.

-- Tim

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 24 Oct 2008 11:24:30 -0400

Tim,

An example of ANY is Algorithm Identifier which appears in Signature,
SIGNED MACRO, and SPKI.

So, there is a precedence for it.

I was hoping to define 2-3 specific structures: An existing one in use;
one we all agree on if this I-D is adopted as work item; and an optional
one that may be useful to what folks ate doing for NFS.  2 and 3 could
be combined. 

For deprecation approaches, see my post from Thursday October 23 from a
strand on this thread.

-----Original Message-----
From: Timothy J. Miller [mailto:[email-masked]] 
Sent: Friday, October 24, 2008 11:11 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: draft-turner-caclearanceconstraints-01.txt

-- Tim

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 25 Oct 2008 03:00:41 +0100

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

> Sent: den 24 oktober 2008 15:52
> To: [email-masked]

---

From: Tom Gindin <[email-masked]>
Date: Tue, 28 Oct 2008 20:14:36 -0400

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 <[email-masked]> 
Sent by: [email-masked]
10/24/2008 10:00 PM

To
Santosh Chokhani <[email-masked]>, "[email-masked]" 
<[email-masked]>
cc

Subject

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 29 Oct 2008 08:54:13 -0400

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:[email-masked]] 
Sent: Tuesday, October 28, 2008 8:15 PM
To: Stefan Santesson
Cc: [email-masked]; Santosh Chokhani
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Stefan, Santosh:

        I would like to put forward a set of processing rules which
might 
        One customized type which I would suggest is "prefixable OID".
The 

                Tom Gindin

To

Subject

Santosh,

Stefan Santesson
Senior Program Manager

> > > Where does the document say anything about mapping between
security
> > > policies?

---

From: Tom Gindin <[email-masked]>
Date: Wed, 29 Oct 2008 20:35:18 -0400

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

10/29/2008 08:54 AM

To
<[email-masked]>
cc

Subject

Tom,

Thanks.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Tuesday, October 28, 2008 8:15 PM
To: Stefan Santesson
Cc: [email-masked]; Santosh Chokhani
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Stefan, Santosh:

                Tom Gindin

To

Subject

Santosh,

Stefan Santesson
Senior Program Manager

security