Jim and Sharon,
The biggest concern I have is the duplication of certificates in directory and
finding certification path. The CertificateSet, which is required to be present
in SMimeCertificatePublish object, is a set of certificates that MUST be
present. It contains a "bucket-o-certs" for the user certificates and CA
certificates. If we could replace it with a pointer to the user certificate and
CA certificates it would solve this duplication problem. PKIPath couldn't be
used because it too is not a pointer. Could we use something like (hack my
ASN.1 as you please) the following instead of CertificateSet:
CertificatesForSMIME ::= SEQUENCE {
sMIMEUserCertificate CertificateIdentifier,
sMIMECACertificates SEQUENCE OF CertificateIdentifier }
CertificateIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
This would solve the problem of duplication and it would provide the certificate
path. This won't solve the problem of backwards compatibility though. So maybe
we could use the following instead of CertificateSet too:
CertificateForSMIME ::= CHOICE {
actualCertificates CertificateSet,
-- For backward compatibility with Netscape and Microsoft code
pointerToCertficates CertificatesForSMIME }
Thoughts?
Other issues:
- Using SMIMECapabilities instead of supportAlgorithms
To be honest I don't have a preference. supportAlgorithms is in X.500 but
SMIMECapabilities is in an RFC. Both are implemented.
- Using attribute certificates to bind algorithm instead of SMIMECapabilities
I think while it should be a goal to use attribute certificates to bind the
algorithms to the certificates I don't think we're there yet (some maybe but not
most). We probably don't want to wait for everbody to implement attribute
certificates before implementing this mechanism.
Cheers,
spt
Jim Schaad wrote:
Sharon,
There were a number of limitations that are in X509 that I was trying to
overcome with this draft:
The supportedAlgorithms field was not used for two reasons, first I did not
know about it when this started and secondly attribute certificates were not
defined at the time the problem was addressed, thus they were not a part of
every S/MIME application already. The use of the SignedData structure means
that we are re-using already existing code in every S/MIME application.
(The exact same mechinism is used for transfering the information when
sending a signed message between two entities.)
Given that we are living in an LDAP world rather than an X509 world, using
isser DNs of certificates to attempt to find an issuer certificate is an
extremely difficult problem. Add to this the questions of
companies/individuals not publishing intermeadiate CA certificates or making
them private (although the CRL might be available from a non-directory
location) and I don't know that in the internet world that the certificate
retrevial portion of path construction is viable.
While I agree that this problem might have been better considered in the
PKIX working group as the problem is universion, however the problem and the
solution was first found by S/MIME developers and the chair of the group
agreed that it was a reasonable problem to be put before the group.
Additionally, the solution used some items that were defined by the working
group in the S/MIME documents rather than in PKIX documents. Lastly, the
PKIX group is still very X509 directory centric in many of it's solutions
while the S/MIME working group is extremely LDAP centric. Thus what seems
to be a problem for the S/MIME working group might not be a problem for the
PKIX working group (such as finding CA certificates without an X509
directory).
Additionally please note that we have not solved the general path
construction problem, we have only made it easier (since the holder of the
certificate is in a better situation to build their own path) for the sender
to avoid the problem. In the event that the PKIX group came up with a
viable method of doing path discovery then this draft can be revised so that
the full path information was not required in the attribute even though
there are situations (i.e. offline or non-directory location of the
attribute) where it might be useful.
jim schaad
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Sharon
Boeyen
Sent: Friday, June 02, 2000 11:42 AM
To: 'ietf-smime(_at_)imc(_dot_)org'
Subject: SMIME cert dist draft and X.509
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