Re: X.509 Cert Extensions - Latest Draft from X9

Warwick,

I have eventually got round to looking at the ANSI
proposals for extensions to X.509 certificates.

I have one area of major concern with this proposal: how
clearances and privileges are handled.  I agree with the
need for some such fields but if the current approach is
adopted (even just in the ANSI banking arena) there will
come a point where there are likely to be problems as
outlined below


1) CLEARANCE AND PRIVILEGE UNRELATED?

In the ANSI X.9 proposed extension to the certificate
format there are two fields: privilege attribute and a
clearance level.  The two fields are unrelated.

Clearances can be viewed as a special case of privileges.
In any case, a hierarchical clearance is normally
associated with other privileges (e.g. membership of a
group, codeword) in commercial as well as governmental
systems.  Separating the two out is likely to lead to
significant difficulties.


2) CLEARANCE A KEY RELATED ATTRIBUTE ?

The privilege attribute is related to the key whilst the
clearance level is associated with the subject. Why is
this so?

Whilst a subject may be cleared to a high level he may
wish to be allocated keys which are only for use for low
level activities.


3) CLEARANCE AS A BIT STRING ?

Clearance is encoded as a bit string which means that any
combination of bits may be set.  What does it mean if the
top secret and unclassified bits are set but none in
between are set.  This would be better encoded as an
integer.  If a clearance band is to be specified (instead
of just "up to") then an optional minimal value could be
included.


4) CANADA PROTECTED C, B, A???????

Are you expecting ANSI / OIW to adopted Canadian specific
levels?  It is reasonable to allow nationally defined
clearance levels but a default international set of
clearance levels should be defined.


5) X.400 CLASSIFICATION LEVELS

Since X.400 and X.500 are likely to be used in
conjunction shouldn't the X.400 Security Label Security
Classifications be the starting point.


6) OBJECT IDENTIFIER FOR CLASSIFICATION SCHEME

It is agreed that no classification scheme will be
generally accepted.  Thus I would suggest that this
should be preceded by an object identifier (this could be
the same one as identifies the privilege marking scheme).


8) UN EDIFACT MESSAGE SECURITY CERTIFICATE?

In the UN EDIFACT message level security segments include
the definition of a certificate.  Whilst this is encoded
differently this carries the same information as an X.509
certificate except for a couple of exceptions.  Most
notably there is an "User Authorisation Level" field.
How does the proposed ANSI clearance and privilege
certificate extensions relate to this field?


9) OTHER AUTHORISATION FIELDS

A hierarchical clearance level and a privilege bit field
are only two ways of encoding authorisation information.
It is suggested that there is the ability to associate
authorisation information which is in a different form
with the clearance and privilege fields.


10) A SUGGESTED WAY FORWARD

I would propose that the existing clearance and privilege
fields proposed by ANSI are replaced by an X.509
extension field of the form:

PrimaryKeyAuthorisationInformation ::= {
   SYNTAX AuthInfo
   CRITICAL FALSE
   IDENTIFIED BY {oid to be assigned} }

(replace in SecondaryPublicKeyInfo privilegeAuthorityId
and privilegeFlags by
 "authorisationInformation    AuthInfo OPTIONAL")

AuthoInfo ::= SEQUENCE {
      definingAuthorityId   OBJECT IDENTIFIER,
      clearanceBand           ClearanceBand,
      privileges                  PrivilegeFlags,
      securityCategories     SET OF SecurityCategory}

ClearanceBand :: SEQUENCE {
     maxClearance   Clearance,
     minClearance   Clearance OPTIONAL }

Clearance ::= INTEGER {
         unmarked (0),
         unclassified (1),
         restricted (2),
         confidential (3),
         secret (4),
        top-secret (5) } (0 .. 255)

 -- Values 100 to 255 are reserved for private use

PrivilegeFlags ::= BIT STRING

Security-Category ::= SEQUENCE {
     type [0] SECURITY-CATEGORY.&id
({SecurityCategoriesTable}),
     value [1] SECURITY-CATEGORY.&Type
({SecurityCategoriesTable}, {(_at_)type}) }

SECURITY-CATEGORY ::= TYPE-IDENTIFIER
SecurityCategoriesTable SECURITY-CATEGORY ::= {...}

Nick Pope

Security & Standards
Chelmsford
U.K.

Tel: +44 245 495018
Fax: +44 245 494517