ietf-smime
[Top] [All Lists]

Re: Reference to Applicable Attribute Certificate(s) within the CMS

1998-05-01 02:28:21
How about the Privilege Attribute Certificate defined in ECMA 219
and implemented in the SESAME (http://www.esat.kuleuven.ac.be/cosic/sesame)
architecture ?

@MISC{ECMA21996,
  author = "{ECMA 219}",
  title = "{ECMA}-219 {S}ecurity in {O}pen {S}ystems -
              {A}uthentication and {P}rivilege {A}ttribute {S}ecurity
              {A}pplication with {R}elated {K}ey {D}istribution
{F}unctionality, 2nd {E}dition",
  note = "European Computer Manufacturers Association",
  month = "March",
  year = 1996
}

Mark

-----Original Message-----
From: Francois Rousseau <f(_dot_)rousseau(_at_)adga(_dot_)ca>
To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: donderdag 30 april 1998 22:57
Subject: Reference to Applicable Attribute Certificate(s) within the CMS


Refs: A. ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8: 1997,
Information Technology-Open Systems Interconnections - The Directory:
Authentication Framework
B. ANSI X.9.45, Enhance Management Controls Using Digital Signatures and
Attribute Certificates, November 1996 (Draft)
C. ISO/WD-15782-2, Banking - Certificate Management, Part 2: Attribute
Certificates, October 1997 (Draft)
D. PKCS #7: Cryptographic Message Syntax Standard, Version 1.5, Revised
November 1, 1993
E. "Cryptographic Message Syntax", draft-ietf-smime-cms-04.txt, Work in
Progress, March 1998

As part of a study for the Government of Canada (GoC) on its long term
requirements for an Electronic Authorization and Authentication (EAA)
framework, which would be based on Attribute Certificates as defined in
reference A, we also had to review the structure of digitally signed
business transactions.

References B and C, which are both based on reference D, were a good basis
for such a structure and seemed to provide a mean to convey Attribute
Certificates. However, both references B and C took the approach of
OPTIONALLY conveying Attribute Certificates in the
unauthenticatedAttributes field of each per-signer SignerInfo. CMS (ref E)
is taking instead a more elegant approach of collecting Attribute
Certificates and OPTIONALLY including them in the certificates field of the
SignedData along with public key certificates.

In the future GoC EAA framework, Attribute Certificates will form part of
the solution for controlling access to sensitive services, such as
disbursement of funds. If you assume the following model with these four
components: the Claimant, the Verifier, the Service and the Control policy.
To validate a service request (e.g. S/MIME message), the Verifier MUST
obtain some information including the Claimant's public key, the Claimant's
privilege, encoded in its Attribute Certificate, and the applicable Control
policy. However, as indicated above, public key certificates and Attribute
Certificates do NOT have to be included in the certificates field of the
SignedData. Because the issuerAndSerialNumber field of each per-signer
SignerInfo only specifies the signer's certificate (and thereby the
signer's public key) by issuer distinguished name and issuer-specific
serial number, when certificates are NOT included in the certificates field
of the SignedData, the issuerAndSerialNumber field only allows the
recipient of the SignedData to identify for each claimant the signer's
public key to use to validate the message. This implies there are currently
no mean within CMS to convey to the Verifier which Attribute Certificate
MUST be used for each Claimant.

Should not considerations be given within CMS to use the
authenticatedAttributes field under each per-signer SignerInfo to specify
through new CRITICAL attributes, the applicable claimant's Attribute
Certificate and the applicable Control policy that the Verifier MUST use to
validate the message?

Francois Rousseau
f(_dot_)rousseau(_at_)adga(_dot_)ca