Russ,
Thanks for your reply.
(...)
The major issue I see is to mandate the use of ISO Distinguished Name.
This is currently mandated for the issuer names. For leaf names the
situation is is little more complex as it will be explained later.
PKCS#7 version 1.5 and CMS refer to certificates by isser DName and serial
number. Thus, S/MIME certificates must have an issuer DName.
CMS is still under discussion I guess. Is PKCS#7 version 1.5 a reference
for S/MIME 3 ?
compatibility discussion with PKCS#7 v1.5 has been repeated many, many
times, so I will not repeat it again.
I understood that we had some freedom for S/MIME 3 (but not for S/MIME
2). Did I misunderstood ? I still do not see why *only* DNames should be
supported.
2.3 CertificateSet
(...)
"Receiving agents MUST support chaining based on the distinguished name
fields. Other methods of building certificate chains may be supported
but are not currently recommended."
Since the DNames are needed for PKCS#7 v1.5 and CMS, this seems like a
reasonable next step. Note that end entities do not have to have DNames.
They can use the more widely accepted RFC822 AltNames, or other names
formats. The issuer name in the end entity certificate must be a DName,
this will match the subject DName in the CA certificate. Chaining does not
invlove the end entity name.
In that case I do not see how security can be checked. Let us take a
simple example. My company is using E-mail addresses ending with
"bull.net". Your company is using E-mail addresses ending with
"spyrus.com". I would like to exchange E-mails with you. All the
certificates from my company are coming from a CA named
CA(_at_)bull(_dot_)net(_dot_) All
the certificates from your company are issued by a CA named
CA(_at_)spyrus(_dot_)com(_dot_) I may trust your CA to issue certificates for
Spyrus
users, but for Spyrus users only. In the same way I would guess that you
are ready to trust certificates issued by the Bull CA for Bull users,
but for Bull users only. A simple way to make chaining is to make sure
that the Bull CA only issue certificates ending with the same
hierarchical structure as its own name. The same would be valid for
Spyrus. Note that in that simple example I am using two trust points (or
root CAs).
Now could you explain how you can apply the previous trust model when
chaining does not involve the end entity name ?
My own understanding is that nothing would prevent a Bull CA to certify
a user from Spyrus (and the reverse) and that would not be automatically
discovered through the chaining mechanism. CAs cannot be trusted for
everything.
"Attribute certificates -- keep 'em or pitch 'em?"
The ISO document is not yet stable. I would prefer that we do not
include them for the time being but that we indicate that the support of
roles is to be considered.
I can support removing them from the CERT document, but I do not think that
we should eliminate them from the CMS document.
I will consider this when reviewing CMS.
Support for attribute certificates should be completely optional.
Yes.
Russ
Denis
--
Denis Pinkas Bull S.A.
mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21