re: draft-ietf-smime-cert1997-12-16 12:45:59
There are several issues to be addressed in this draft:
1) Should there be mandatory processing of email addresses in certificates 2) The processing descriptions must recognize that not only do receiving agents process certificates during signature validation, but sending agents process certificates used for encryption. 3) The current PKIX profile recommends that subject, if not null, contain a Directory Name; and that an email address, if present, be in subjectAltName. Rather than require an email address in the certificate, and require the matching of the email address and header information, I think that when a signature is declared valid, it is essential to present the owner names bound into the certificate, because it is from the certificate owner that the message originated, regardless of what is in the header of the message. This allows the choice of how to present the owner name in the certificate, where email address is only one of the possible choices. I recommend that the end of section 3.1 should read something like: "End-entity certificates MAY contain an Internet mail address as described in [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of thatspecification. If present, it SHOULD be in the subjectAltName field. Receiving agents MUST recognize email addresses in the subjectAltName field. Sending gents MAY make the address in the From header in a mail message match an Internet mail address in the signer's certificate. Receiving agents MAY check that the address in the From header of a mail message matches an Internet mail address in the signer's certificate. The signature validation function MUST make available the subject and subjectAltName when it reports a successful signature validation; the client receiving and presenting the results of the validation SHOULD present these names." This allows both human users and automated processes to make their own judgement as to validity based on the bound names. Note also that I have not specified any name processing for sending agents processing encryption certificates. It seems reasonable to inform a user about the owners of the certificates actually being used (as opposed to whom the message is addressed), but because of the unlimited number of recipients allowed, this could get very cumbersome. Section 3.2 no longer requires an email address in a certificate. It would read: "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. Guidelines for the inclusion, omission, and ordering of the name attributes during the creation of a distinguished name will most likely be dictated by the policies associated with the certification service that will certify the corresponding name and public key. CountryName StateOrProvinceName Locality CommonName Title Organization OrganizationalUnit StreetAddress PostalCode PhoneNumber EmailAddress All attributes other than EmailAddress are described in X.520 [X.520]. EmailAddress is an IA5String that can have multiple attribute values." Elliott Ginsburg MITRE Corporation Elliott N Ginsburg
|
|
||||||||||||||||