Mark,
The ISIS/MTTv2 standard consists of six parts, see
http://www.secorvo.de/publikat/mttspc20.zip.
The one most applicable to S/MIME is surely "Profiles for Certificates
and CRLs". It describes on 45 pages whata certificate needs to contain
and where. Same for CRLs.
I translate for you the first few paragraphs of the summary:
Q> The stucture of the present document essentially follows that of PKIX
Q> document "Cerificate and CRL Profile" [PKIX-PRO 98], which specifies
Q> a profile for an internet-PKI. [...]
Q>
Q> The profiles are based on the current standard X.509v3 [ITU-T X.509
Q. 97], while the v1.1 standard is based on X.509v1. The current
Q> standard allows to insert an unlimited number of additional fields in
Q> a certificate (certificate extensions) and in CRLs. Therefore, for
Q> interop's sake, a suitable selection needs to be carried out. The
Q> profiles serve primarily this purpose.
Q>
Q> Certificates and CRLs need to include all essential information that
Q> is needed for validity checks of digital signatures and keys. Hence
Q> there exists a close relationship between said information and the
Q> validity model(?) used.
Q>
Q> The validity model contained in the present document defines under
Q> which circumstances a digital signature will be considered valid.
Q> This ensures that all MailTrusT components employ the same check
Q> procedures.
Q>
Q> A prerequisite for validity checks is the presence of all needed
Q> certificates and CRLs. Obtaining these objects will generally depend
Q> on information contained in the certificates. This is also covered by
Q> the present document.
Q>
Q> The spec is divided into the following chapters:
Q> 2. definitions
Q> 3. certificate formats: A profile is defined for certifiates in a
Q> MailTrusT PKI.
Q> 4. CRL format: A profile is defined for CRLs in a MailTrusT PKI
Q> 5. validity model
Q> 6. check of certificate path
IIRC, this doc needs to concern itself with such seemingly trivial
things as "where do I find the email address to which this certificate
is bound?" for a given certificate...
Whoa. You've changed the subject here.
The question of how an application (in this case S/MIME) interfaces to
security credentials is important. When employed in conjunction with soft
certificates (a string of bits encoding a certificate and a private key),
the application needs to perform crypto processing either directly, or via
a collocated crypto library. When employed in conjunction with hard
certificates (smart cards), certificate based crypto processing is by
definition performed on the smart card. The private key never leaves the
card, and data to be encrypted/decrypted using that key is instead
streamed through the smart card. The good news is that a standard has been
defined that provide a common interface (PKCS13) to hard certificates and
allows encryption/decryption and other associated functions (PIN
provision) to be performed. The major email vendors have either added or
are in the process of adding PKCS13 based hard certificate support to
their S/MIME products. There are of course other proprietary interfaces
available, both from smart card vendors, and the likes of Microsoft
(pccard) which muddy the waters. Also, and this is a much hornier problem,
an application (again S/MIME) that needs to verify a certificate provided
by a correspondent, has to verify that this certificate and any other
certificates employed to sign that certificate are correctly signed and
have not been revoked. The latter requires access to a suitably up-to-date
Certificate Revocation List (CRL). You are correct in stating that this
particular aspect of crypto technology is currently a mess, and as a
result, unless their crypto library supports CRL checking against some ad
hoc form of CRL repository, it doen't get done.
Nick
Nick Shelness
Independent Technology Consultant
Fellow - Differéntis Ltd.
Advisor - Oak Investment Partners
Contact Details
Office Tel: +44 (0) 1828 640 632
Office Fax: +44 (0) 1828 640 647
Internet email: nick(_at_)old-mill(_dot_)net
Short message: +44 7753 566460 or page(_at_)old-mill(_dot_)net
AOL instant messaging: NickShelness
MSN instant messaging: nh_shelness(_at_)hotmail(_dot_)com
Yahoo instant messaging: NickShelness
Snail mail: The Old Mill, Meigle, Perthshire, PH12 8TJ, UK