RE: draft-turner-caclearanceconstraints-01.txt

["Carl Wallace" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Tuesday, October 07, 2008 11:41 AM
To: Stephen Kent; [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt



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: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: den 1 oktober 2008 22:24
To: [e-mail]
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.

 

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