RE: Support for X.841

Hi Jim,

The SFL and Access Control Library (ACL) do not currently support X.841
(see below for more details).  Currently, there are no specific plans to
enhance the SFL and ACL to support X.841.  Do you have a specific
requirement to support X.841?  If so, please let me know (off the list)
so that we can discuss the possibility of enhancing the SFL and ACL to
support X.841 (and associated specifications).  

The SFL builds and processes signedData content types that can include
the RFC 2634 ESSSecurityLabel signed attribute, but the SFL itself does
not perform any access control processing of the ESSSecurityLabel.  The
ASN.1 syntaxes for the RFC 2634 ESSSecurityLabel and X.841
ConfidentialityLabel are similar, but different.  The most significant
difference is that the security-policy-identifier is optional in X.841,
but not optional in RFC 2634.  Also, there are differences in the length
constraints for the security-classification, PrivacyMark utf8String, and
SecurityCategories SET OF components.  The SFL would need to be enhanced
to fully support the ASN.1 encoding and decoding of X.841
ConfidentialityLabels.  

An application could provide an ASN.1 encoded X.841 ConfidentialityLabel
to the SFL as an "unknown" signed attribute.  The SFL will build and
process signedData content types that can include unknown signed
attributes. 

The Access Control Library (ACL) determines if a subject's
authorizations (contained in an X.501 Clearance attribute contained
within an X.509 attribute certificate or X.509 public key certificate)
allow the subject to access data labeled with specific sensitivity
values included in an RFC 2634 ESSSecurityLabel.  The ACL can be used to
meet the Partition Rule Based Access Control (PRBAC) processing
requirements specified in the "SDN.801 MISSI Access Control Concept and
Mechanisms" document.  The ACL implements the RFC 2634 ESSSecurityLabel
and SDN.801 Security Policy Information File (SPIF).  The ASN.1 syntaxes
for the SDN.801 SPIF and X.841 SPIF are significantly different.  The
ACL would need to be enhanced to fully support the ASN.1 encoding and
decoding of X.841 SPIFs.

Also, the ACL implements the SDN.801-specified syntaxes (and associated
semantics) to be used as the value for each SecurityCategory SEQUENCE
populated in X.501 Clearance attributes, RFC 2634 ESSSecurityLabels and
SDN.801 SPIFs.  In order for the ACL to implement securityCategories in
conjunction with X.841 ConfidentialityLabels, X.501 Clearance attributes
and X.841 SPIFs, then the syntaxes and semantics of those security
categories would need to be specified.  This will have a significant
impact on the scope of the ACL changes required to support X.841
processing. 

===========================================
John Pawling, [email protected]
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Jim Craigie [mailto:[email protected]]
Sent: Monday, April 08, 2002 5:50 PM
To: Pawling, John
Cc: [email protected]
Subject: Support for X.841


Do you have any immediate plans to add support for X.841 to the SFL
Access Control Library? If so, by when?

Jim



-----------------------------------------------------------------------

Clearswift monitors, controls and protects all its messaging traffic in
compliance with its 
corporate email policy using Clearswift products. Find out more about
Clearswift, its 
solutions and services at http://www.clearswift.com

************************************************************************
********************************
This communication is confidential and may contain privileged
information intended solely 
for the named addressee(s). It may not be used or disclosed except for
the purpose for 
which it has been sent. If you are not the intended recipient, you must
not copy, distribute 
or take any action in reliance on it. Unless expressly stated, opinions
in this message are 
those of the individual sender and not of Clearswift. If you have
received this communication
in error, please notify Clearswift by emailing [email protected]
quoting the sender and
delete the message and any attached documents. Clearswift accepts no
liability or 
responsibility for any onward transmission or use of emails and
attachments having left the 
Clearswift domain.