Subject: RE: Cert Attributes in CERTDIST

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Mon, 11 Oct 1999 12:48:25 -0700

Keyboard focus bug -- lets finish the message this time.

I do know that current clients exist in the market who only look at one
element (mine for one), however I don't believe that this should stand in
the way of creating a "correct" standard.

I agree that it makes sense to allow for the EE certificate to be optional
if it exists in the userCertificates property.  I think that the chain
certificates can be optional if  there are sufficent pointers in the
certificate to allow it to be found. (i.e. an AIA extension with an ldap
URI).

I will update the draft to this and post before the end of the week.

jim

-----Original Message-----
From: Jim Schaad (Exchange) 
Sent: Monday, October 11, 1999 12:46 PM
To: 'Walter Williams'; Russ Housley
Cc: [email-masked]; [email-masked]
Subject: RE: Cert Attributes in CERTDIST

I do know that current clients exist in the market who only look at one
element (mine for one), however I don't believe that this should stand in
the way of creating a "correct" standard.

I agree that it makes sense to allow for the EE certificate to be optional
if it exists in the userCertificates property.  I think that the chain
certificates can be optional if 

-----Original Message-----
From: Walter Williams [mailto:[email-masked]]
Sent: Sunday, September 12, 1999 7:30 PM
To: Russ Housley; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Cert Attributes in CERTDIST

Russ,

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: [email-masked] [mailto:[email-masked]]On
Behalf Of Russ Housley
Sent: Sunday, September 12, 1999 12:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Cert Attributes in CERTDIST

Jim:

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
attribute.

Thoughts?

Russ

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Mon, 11 Oct 1999 12:43:20 -0700

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:[email-masked]]
Sent: Thursday, September 16, 1999 9:51 AM
To: [email-masked]
Cc: [email-masked]
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.

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Mon, 11 Oct 1999 12:46:01 -0700

-----Original Message-----
From: Walter Williams [mailto:[email-masked]]
Sent: Sunday, September 12, 1999 7:30 PM
To: Russ Housley; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Cert Attributes in CERTDIST

Russ,

Walt Williams
GTE Internetworking

-----Original Message-----

Jim:

Thoughts?

Russ