Russ Housley wrote:
S/MIME WG Participants:
These three documents seem to be in very good shape. I have previously
announced last Call for ESS, and a new version has been released to
incorporate the comments. I am now announcing Last Call for MSG and CERT.
None of these documents will be progressed to the IESG until CMS has
completed Last Call. At that time, CMS, ESS, MSG, and CERT will be
forwrded to the IESG together.
Russ
S/MIME WG Chair
I have a few problems with cert (draft-ietf-smime-cert). The document
refers to X.509 certificates instead of PKIX certificates.
Basically PKIX is a super set of X.509. I would prefer that we only use
and refer to the PKIX documents i.e. [KEYM] "Internet Public Key
Infrastructure X.509 Certificate and CRL Profile", Internet-Draft
draft-ietf-pkix-ipki-part1 and take advantage of the new capabilities
that have been added in PKIX, basically the use of Alternate names.
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.
There is no rational provided in the document to explain why this choice
has been made.
Let us now look at the details.
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."
This is where in the document chaining of issuer DNs is mandated.
As it will be explained later chaining can be done through naming
constraints within certificates or through local naming constrains.
Since the first one is not mandated and the second one is not described,
it is unclear how agent CAN support it.
Allowing other forms of name for CAs would be adequate. The X.400 naming
scheme which is also X.521 based has not been a success and leads to
names that are difficult to read/write and communicate. I would rather
prefer S/MIME to be a success. :-)
3. Distinguished Names in Certificates
3.1 Using Distinguished Names for Internet Mail
(...)
" All subject and issuer names MUST be populated (i.e. not an empty
SEQUENCE) in S/MIME-compliant v3 X.509 Certificates, except that the
subject DN in a user's (i.e. end-entity) certificate MAY be an empty
SEQUENCE in which case the subjectAltName extension will include the
subject's identifier and MUST be marked as critical."
This is where the subject name is mandated to be a DN, and then not
mandated. :-)
What is the "subject's identifier" is the second case ? What is the
relationship with an Internet mail address ?
3.2 Required Name Attributes
"Receiving agents MUST support parsing of zero, one, or more instances
of each of the following set of name attributes within the
Distinguished Names in certificates."
Is there no attributes required for sending agents ?
(...)
4.2 Certificate Chain Validation
"In creating a user agent for secure messaging, certificate, CRL, and
certificate chain validation SHOULD be highly automated while still
acting in the best interests of the user. Certificate, CRL, and chain
validation MUST be performed as per [KEYM] when validating a
correspondent's public key."
A better reference would be needed. The section is called : 6
Certificate Path Validation.
4.4 X.509 Version 3 Certificate Extensions
Wouldn't it be more appropriate to refer to [KEYM] "Internet Public Key
Infrastructure X.509 Certificate and CRL Profile", Internet-Draft
draft-ietf-pkix-ipki-part1 instead of X.509 Version 3 ?
4.4.1 Basic Constraints Certificate Extension
(...)
"Certificates SHOULD contain a basicConstraints extension".
Since basicConstraints extensions are hard to handle, it is a reasonable
choice.
However indications should be given to apply external naming constraints
otherwise implementors could end up with insecure implementations: if
you trust two (or more) CAs and have no naming constraints (either local
or embedded within the certificates) then any of the CAs could certify
any end user. :-(
We need to give guidance since we should not mandate a single root
self-certificate in a client workstation.
To this respect I do not see why the use of DNs offers a major advantage
over RFC822 names.
The use of DNs presents some properties that can be seen as both an
advantage and a disadvantage:
1) when DNs are used and many attributes are used, from the certificate
you can make sure you correspond with the right individual. The drawback
is to loose privacy. Another drawback is the size of the certificate
(especially if you want to have it a smart card).
2) when DNs are not used, you would need another mechanism to make sure
you correspond with the right individual, i.e. make some kind of look up
in a server that you can trust. You may have more privacy, the size of
the certificate is reduced.
I would think that both models make sense, but more text to explain it
would be adequate.
C. Needed changes
"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.
Note: I will be away most of next week and unable to follow this thread.
So don't be surprised if there is no response from me until next Friday.
:-(
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