Use of this element has what I consider to be a fatal flaw -- specifically
it is not protected in any way. There is nothing to prevent me from
changing the value that you see retrieved from the directory in such a way
to allow you to detect it. (consider changing the algorithms from 3DES to
RC2/40 for example). After all, as a rule one does not bother looking up
ones own data in a directory to see if it has been changed recently.
jim
-----Original Message-----
From: Russ Housley [mailto:housley(_at_)spyrus(_dot_)com]
Sent: Thursday, September 16, 1999 9:51 AM
To: jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Cert Attributes in CERTDIST
X.509-1997 defines the supported algorithm attribute. There seems to be a
lot of overlap.
Russ
= = = = = = = = = =
12.2.2.8 Supported algorithms attribute
A Directory attribute is defined to support the selection of an algorithm
for use when communicating with a remote end entity using certificates as
defined in this Directory Specification. The following ASN.1 defines this
(multi-valued) attribute:
supportedAlgorithms ATTRIBUTE ::= {
WITH SYNTAX SupportedAlgorithm
EQUALITY MATCHING RULE algorithmIdentifierMatch
ID id-at-supportedAlgorithms }
SupportedAlgorithm ::= SEQUENCE {
algorithmIdentifier AlgorithmIdentifier,
intendedUsage [0] KeyUsage OPTIONAL,
intendedCertificatePolicies [1] CertificatePoliciesSyntax OPTIONAL
}
Each value of the multi-valued attribute shall have a distinct
algorithmIdentifier value. The value of the intendedUsage component
provides an indication of the intended usage of the algorithm (see 12.2.2.3
for recognized uses). The value of the intendedCertificatePolicies
component identifies the certificate policies and, optionally, certificate
policy qualifiers with which the identified algorithm may be used.