[Top] [All Lists]

RE: Cert Attributes in CERTDIST

1999-09-12 19:31:57

One thought here is backwards compatability of existing s/mime aware
clients.  Some may have been written to check for the cert in only one of
the available attributes.  You don't want to change the directory in a way
which prevents an older client from seeing the certificate. (might though
give vendors a thrill to have to say: so sorry, but due to a standard change
we must force you to upgrade to support s/mime again)  Certificates are also
not very large (compaired with a .jpg picture of the directory entrant as a
comparitive example) and so the data bloat does not waste much drive space.
Of course, if all available clients look in both places, my statement is
pretty much a waste of good bandwidth.

Walt Williams
GTE Internetworking

-----Original Message-----
From: owner-ietf-smime(_at_)imc(_dot_)org 
Behalf Of Russ Housley
Sent: Sunday, September 12, 1999 12:35 PM
To: jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com
Cc: wpolk(_at_)nist(_dot_)gov; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Cert Attributes in CERTDIST


I must agree with many of the points that Dave Kemp made.  Is it worth
putting multiple copies of the same certificate into the Directory?  This
can lean to inconsistincies.

Maybe it would be better to follow the PKIX LDAP Schema and add an
S/MIME-specific attribute too the directory entry.  The binding you seek
could be achieved by putting a reference to a specific certificate that is
available in the userCertificate attribute inside the S/MIME-specific



<Prev in Thread] Current Thread [Next in Thread>