Re: Clearance & CA Clearance Constraints Cert Ext ID

["Denis Pinkas" <denis.pinkas@xxxxxxxx>]

This thread is going so fast, that it is difficult to answer all the messages.

I picked this one from Stefan and I share some of his views:
a - Clearances are not best located in PKCs.
b - The constraints extension would be a big piece of code in the path processing code.

I saw other messages like : we are simply doing a copy and paste of what was specified in RFC 3281.
But the real issue is whether this makes sense.

My last talk at an RSA security conference was : 
Why are Attribute Certificates not yet in use today ?

I now have a question : Has anybody already implemented what was specified in RFC 3281, 
supporting the clearance attribute defined there ? What is any return from experience ?
Does that return state that the clearance attribute would better be placed in PKCs ?

Another major issue is that the definition of clearance originally made in X.501 
and copied in RFC 3281 is insufficient in practice.
See my earlier e-mail on that topic.

Denis

=============================================================================

>
>First I want to apologize for a somewhat late response to this issue. I have been away from work due to my mother's passing but I'm now fully back and operational.
>
>I'm somewhat surprised to see such overwhelming support for this draft. Personally I have some big concerns.
>
>Including authorization and clearance information in certificates is both tricky and dangerous. In my opinion certificates is the least suitable place for such information.
>Clearance is not just tied to a person, but to systems and I may have a wide range of clearances in different systems. Clearance may change very rapidly while certificates and more static declarations of the relationship between a person and a set of keys. So they do not naturally mix very well.
>
>Further, the extension of this draft affects path validation. This means that supporting this extension involves a HUGE commitment from product development compared to an extension that is only parsed locally in the relying party's application. An extension that is processed in path validation requires not only changes to the path validation algorithm. It will also require API changes to accommodate status and error codes as well as results.
>
>I don't find any motivation for this new standard that makes me believe that it is worth the effort and I therefore object to this being adopted as a PKIX work item.
>
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>> -----Original Message-----
>> From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-
>> pkix@xxxxxxxxxxxx] On Behalf Of Russ Housley
>> Sent: den 12 januari 2008 15:18
>> To: ietf-pkix@xxxxxxx
>> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>>
>>
>> While this extension is primarily useful to a Government/Military
>> environment, it does have some applicability to commercial
>> environments too.  This situation is demonstrated in RFC 3114.  I see
>> advantages to all of the potential users if this specification is
>> published on the IETF standards-track.
>>
>> I encourage the PKIX WG to accept this document.
>>
>> Russ
>>
>> At 04:00 PM 1/11/2008, Turner, Sean P. wrote:
>>
>> >Santosh Chokhani and I have produced an ID that defines an extension
>> that
>> >holds a subject's clearance. The ID also defines an extension called
>> >clearance constraints to limit the clearance values a CA should place
>> in
>> >subordinate certificates. Finally, it defines the certification path
>> >processing rules to determine the clearances for the subject of the
>> >certificate based on the clearance and clearance constraints asserted
>> in the
>> >certification path. The ID can be found at:
>> >
>> >http://www.ietf.org/internet-drafts/draft-turner-
>> caclearanceconstraints-00.t
>> >xt
>> >
>> >We're hoping that PKIX would be willing to adopt this as a work item.
>> >
>> >spt
>
>

Regards,

Denis Pinkas