Tony:
Nice suggestion. I think we should do it.
Russ
Blake:
The absence of an rfc2822 e-mail address in the certificate should not be
considered a "failure" since its absence must have been permitted by the
certificate issuer - and we assume (!) that certificates are issued
according to issuer policy.
The current text (which you quoted) could be incomplete. My interpretation*
of the middle sentence of this paragraph is that the check is only mandatory
if the address is present (so a comparison to an absent/"blank" field is not
mandatory). The following sentence then suggests what action to take if the
check/comparison fails. Since if the comparison is not done, it will not
fail, one could interpret that no indication is required if the address is
absent from the cert.
The paragraph following the quoted one addresses the display of the signer's
identity:
A receiving agent SHOULD display a subject name or other certificate
details when displaying an indication of successful or unsuccessful
signature verification.
Should this be stronger in cases where the certificate has an absent rfc2822
field (and no check against the From: header field was done)?
Maybe adding the sentence between these two paragraphs:
"Receiving agents which do not perform the foregoing check due to the
absence of an address in the certificate MUST display the subject name
from the certificate when displaying an indication of successful or
unsuccessful signature verification."
-leaving the following paragraph as a SHOULD, strongly encouraging
additional information to be displayed in this and all other cases.
Tony
* I interpret the phrase: "if mail addresses are present in the
Certificate" to be a qualifier for the "MUST" in this sentence.
| -----Original Message-----
| From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Blake
Ramsdell
| Sent: July 31, 2003 12:53 AM
| To: 'Russ Housley'; jimsch(_at_)exmsft(_dot_)com;
ietf-smime(_at_)imc(_dot_)org
| Subject: RE: RFC2632bis and subjectAltName
|
|
|
| > -----Original Message-----
| > From: Russ Housley [mailto:housley(_at_)vigilsec(_dot_)com]
| > Sent: Tuesday, July 29, 2003 4:36 PM
| > To: jimsch(_at_)exmsft(_dot_)com; 'Blake Ramsdell';
ietf-smime(_at_)imc(_dot_)org
| > Subject: RE: RFC2632bis and subjectAltName
| >
| > I understand that non-email applications of CMS and the
| > associated MIME
| > types need other address forms. But, RFC2632bis does not tell an
| > implementor what to do fir S/MIME (which is an email
| > application) if the
| > certificate does not contain an email address.
|
| I'm still not clear whether S/MIME means "secure MIME used
| anywhere MIME can be used, such as XMPP or BEEP" or S/MIME
| means "secure MIME used for interpersonal email messaging".
| Depending on the answer, you will get different answers if
| it's necessary to clarify any language about the absence of
| email addresses in the certificate.
|
| The relevant text about current processing rules seems to be:
|
|
| Sending agents SHOULD make the address in the From or Sender
| header in a mail message match an Internet mail address in
| the signer's certificate. Receiving agents MUST check that
| the address in the From or Sender header of a mail message
| matches an Internet mail address, if present, in the signer's
| certificate, if mail addresses are present in the
| certificate. A receiving agent SHOULD provide some explicit
| alternate processing of the message if this comparison fails,
| which may be to display a message that shows the recipient
| the addresses in the certificate or other certificate details.
|
|
| So if there are not any email addresses found in the
| certificate, this is a mismatch (blank from the certificate
| doesn't match nonblank from the From or Sender), and you
| should go crazy insane and show a hex dump of the certificate.
|
| We could clarify that "failure" includes the case where there
| are zero email addresses in the certificate...
|
| Blake
|