I am not a regular participant on this mailing list, and therefore lack the
history behind this draft. However, as editor of X.509, I'm wondering why
this draft invents new data structures for requirements that, after a very
quick review, I think that X.509 already has standardized structures to
support. From a 509 perspective, I certainly want to understand any
shortcomings that specification has with respect to meeting the needs of the
applications that use public-key certificates.
Regarding SMimeCapabilities themeselves; was the supportedAlgorithms
attribute from 509 considered? If so, were there specific shortcomings that
it had? Note that it is defined in X.509 as an attribute. Attributes can be
stored in
directories as part of entries (with or without being digitally signed
and/or encrypted), they can be transferred in application protocols, they
can be included in public-key and attribute certificates.
Regarding the requirement to tie a set of supported algorithms to a specific
certificate; the construct defined in the Internet draft is semantically an
attribute certificate. Was an X.509 attribute certificate considered and
rejected? If so, what were its deficiencies? Note that there are a number of
ways to identify the holder of an X.509 attribute certificate. One of those
is the hash of a public-key certificate. An attribute certificate that
contained the hash of a public-key certificate and the supportedAlgorithms
attribute seems to provide the functionality you're looking for. If you want
a construct that includes several iterations (i.e. the set of algorithms
for each public-key certificate), then the X.509 construct
attributeCertificateAttribute seems to provide this because it is a
multivalued attribute that contains values of the attributeCertificate
construct. Again, these can be stored in directories, stored in files,
transferred in application protocols etc.
Regarding PKI path construction; this is an area where a number of different
groups seem to be active. I'm curious why there would be an smime specific
mechanism for this anyway, when if there really is a problem, its probably
not unique
to smime. PKIX seems like a better place to solve this problem. I'm not sure
I really understand your proposed solution. Are you focused only on
hierarchies or also addressing networked trust models? Why store the path
with the subject's domain when its the relying party's domain where the
information is needed. Why associate it with a user certificate at all,
since the same path (less the user cert) can be reused for any user certs
signed by the same CA? X.509 has a standard attribute called pkiPath that I
think may satisfy the requirement. This attribute contains a sequence of
CA-certificates and its intent is that it stores paths that are frequently
used by the relying parties within the community of a given CA. As such, it
can be used to reduce the number of network connections and directory (or
other protocol) requests to external domains. It is intended to be an
optional facility that may be useful in some environments, but not necessary
in others.
With respect to all of these, my view is that, if directories are being used
as repositories for the information, then ALL public-key certificates issued
to a user be stored in the userCertificate attribute of their directory
entry. This eliminates the need for specialized application-specific tools
on the relying party side to find application specific data. If there are
enhanced mechansims that provide potential efficiencies in an application
specific environment these
should be optional enhancements and not eliminate the fundamental
interoperability requirement to store information in a common place. I hold
the same view with respect to the pkiPath attribute. If stored in a
directory it should not eliminate the need to store information as defined
in X.509 and profiled by PKIX in the crossCertificatePair and caCertificate
attributes.
I apologize in advance if, due to my lack of knowledge of the history of
this spec, I'm asking questions that have been previously dealt with and
closed, but felt I should at least ask, in the capacity of X.509 editor.
FYI, if anyone needs to see the X.509 spec, they can obtain it in Word or
pdf format from the following:
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/
This text has been approved by ITU and is the 2000 edition of X.509,
although many of things I mention were in the 1997 3rd edition text as well.
Sharon
Sharon Boeyen
Entrust Technologies
sharon(_dot_)boeyen(_at_)entrust(_dot_)com