RE: [Fed-Talk] Re: Help with actual & "certified" email address mismatch (CAC)
RE: [Fed-Talk] Re: Help with actual & "certified" email address mismatch (CAC)
- Subject: RE: [Fed-Talk] Re: Help with actual & "certified" email address mismatch (CAC)
- From: "Miller, Timothy J." <email@hidden>
- Date: Thu, 22 Jul 2010 16:00:43 -0400
- Acceptlanguage: en-US
- Thread-topic: [Fed-Talk] Re: Help with actual & "certified" email address mismatch (CAC)
>Uri, unfortunately, your needs are completely counter to the basic rules
>of validation that govern signing and encryption. One of the most basic
>tenets of this validation is that an email address is an exact match for
>a certificate's embedded email address -- so in the case of signing, the
>email has to come from that address, and in the case of encryption, the
>email has to go to that address.
>Without this basic tenet, the actual security of that validation falls
>apart, because someone else could sign an email but then forge its
>headers to purport to be from me, or could encrypt an email using a cert
>that has nothing to do with the recipient's.
Not true; or at least, that's not the whole story.
RFC5750, S/MIME Version 3.2 Certificate Handling:
"""
Using Distinguished Names for Internet Mail
End-entity certificates MAY contain an Internet mail address as
described in [KEYM], Section 4.2.1.6. The email address SHOULD be in
the subjectAltName extension, and SHOULD NOT be in the subject
distinguished name.
Receiving agents MUST recognize and accept certificates that contain
no email address. Agents are allowed to provide an alternative
mechanism for associating an email address with a certificate that
does not contain an email address, such as through the use of the
agent's address book, if available. Receiving agents MUST recognize
email addresses in the subjectAltName field. Receiving agents MUST
recognize email addresses in the Distinguished Name field in the PKCS
#9 [PKCS9] emailAddress attribute:
pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }
Note that this attribute MUST be encoded as IA5String and has an
upper bound of 255 characters. The right side of the email address
SHOULD be treated as ASCII-case-insensitive.
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.
A receiving agent SHOULD display a subject name or other certificate
details when displaying an indication of successful or unsuccessful
signature verification.
All subject and issuer names MUST be populated (i.e., not an empty
SEQUENCE) in S/MIME-compliant X.509 certificates, except that the
subject distinguished name (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.
"""
Upshot: A sending MUA should make them match, but it's not required. Receiving MUAs have to check for a match, but are not required to *act* on a mismatch, but are further encourage to provide alternate mechanisms.
Note: RFC "SHOULD" clauses have specific meaning defined in RFC2119:
"""
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
"""
So it would be perfectly within spec for a receiving MUA to ignore the subjectAltName extension in an S/MIME signing certificate and instead match the signing certificate against certs the MUA has stored for example, in the address book under the sender's email address(es).
-- Tim
>-----Original Message-----
>From: fed-talk-bounces+tmiller=email@hidden [mailto:fed-
>talk-bounces+tmiller=email@hidden] On Behalf Of Levine,
>Jason (NIH/NCI) [E]
>Sent: Thursday, July 22, 2010 2:35 PM
>To: email@hidden
>Subject: [Fed-Talk] Re: Help with actual & "certified" email address
>mismatch (CAC)
>
>Uri, unfortunately, your needs are completely counter to the basic rules
>of validation that govern signing and encryption. One of the most basic
>tenets of this validation is that an email address is an exact match for
>a certificate's embedded email address -- so in the case of signing, the
>email has to come from that address, and in the case of encryption, the
>email has to go to that address.
>
>Without this basic tenet, the actual security of that validation falls
>apart, because someone else could sign an email but then forge its
>headers to purport to be from me, or could encrypt an email using a cert
>that has nothing to do with the recipient's.
>
>
>I think I understand that you wish to override this tenet of the
>validation process by manually associating email address A with a cert
>that has an embedded address NOT-A... but I'd imagine that it's a rare
>product which allows that to happen, since it'd then diminish the
>security of the process, and serve as a potential attack vector (via
>social engineering or other hacks which would insert overrides that
>would seamlessly claim security when none existed). In the end, I'd ask
>why the gentleman's email addresses don't match -- why he has a CAC card
>with a different address than the one he sends from/receives to. That's
>really the part of this that's broken, not the UI or functionality of
>the mail agent at your end.
>
>Jason
>
>
>> I?m using Mac OS X 10.6.4 (all the latest patches), installed CACNG-
>0.96. For email I use Apple Mail 4.3 (1081) and MS Entourage 13.0.5
>(100510).
>>
>> My Mac recognizes CAC, sees certificates on it, etc. I successfully
>used it to authenticate to US AF Portal.
>>
>> Now I need to exchange email with a gentleman (either we both use CAC
>cards, or only he does: I have other ? soft ? certificates on my Mac
>that I can and often do use for email security).
>>
>> His actual email address is: email@hidden
>> His CAC-based cert says: email@hidden
>>
>> My needs are:
>>
>> 1. Verify signature on John.Doe?s email that comes from his real
>address but is signed by his CAC identity
>> 2. Send email to email@hidden (his actual/real email
>address) ? yet have it encrypted to his CAC identity.
>>
> _______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Fed-talk mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>
>This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden