All-
I was questioning Apple’s decision to consider the left, or Local part of the Email Address as case-sensitive, so I spent time following the RFCs.
I did some checking, and Apple may be allowed to use a case-sensitive check for the left side of an email address. I followed the RFC’s back to try and figure out the
requirements.
I started with RFC 5751, http://tools.ietf.org/html/rfc5751- the
S/MIME standard - it points to RFC 5750 (S/MIME 3.2) which references RFC 5280 – X.509 standard which references RFC
2821 – which ultimately states the Local-part of the SMTP email address May be case sensitive. _SO_ Apple is following the allowances of RFC 2821.
Darn it. I’m an OLD SMTP, UUCP prior to that, user and always thought the entire SMTP mailbox was (supposed to be) case-insensitive.
It would help if we could toggle that decision to be case sensitive as folks are InCoNsistEnt with the use of case with email accounts, and other factors, such as GSA
creating PIV certificates in all UPPER case, are out of our control and we still need things to work.
Lee
Lee Neely, CISSP, CISA, CISM, CRISC, CCUV
Lawrence Livermore National Laboratory
Cyber Security Program, OMBUDS
7000 East Ave L-315
Livermore, CA, 94551
In RFC 5750, Section 3 I find the following:
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.
Reading on -
In RFC 5750, Section 4.4.3
4.4.3.
Subject Alternative Name
The subject alternative name extension is used in S/MIME as the
preferred means to convey the email address(es) that correspond(s) to
the entity for this certificate. Any email addresses present MUST be
encoded using the rfc822Name CHOICE of the GeneralName type as
described in [KEYM],
Section 4.2.1.6. Since the SubjectAltName type
is a SEQUENCE OF GeneralName, multiple email addresses MAY be present.
KEYM is a reference to RFC 5280-
In RFC 5280, Section 4.2.1.6:
When the subjectAltName extension contains an Internet mail address,
the address MUST be stored in the rfc822Name. The format of an
A Mailbox has the form "Local-part@Domain". Note that a Mailbox has
no phrase (such as a common name) before it, has no comment (text
surrounded in parentheses) after it, and is not surrounded by "<" and
">". Rules for encoding Internet mail addresses that include
internationalized domain names are specified in Section
7.5.
So, I went to Section 4.1.2 of RFC 2821 and found:
Mailbox = Local-part "@" Domain
Local-part = Dot-string / Quoted-string
; MAY be case-sensitive
Fed-Talk Listers,
Recently I have not had the cycles to respond to and comment on some recent email thread on this list, but I hope to be able to address some misconceptions and statements made recently in hopes to help folks avoid
problems and help folks be more productive by doing the right thing.
The only way I have found to be able to address a long thread in a single response is to take things point for point and comment accordingly. Hopefully that will be helpful for folks, if not, hit the delete button
and move on blissfully.
On Mar 13, 2014, at 11:30 AM, Rowe, Walter <email@hidden> wrote:
We have our PIV certs populated in AD. I have the OS X Smartcard Services installed and enabled on an OS X 10.9.2 laptop bound to AD. I can successfully log into OS X with my PIV card. I can
create new email messages with click the digital signature button to successful send digitally signed emails. I can’t click the encryption button. It is is grayed out.
I read in Apple Mail Help that I need the personal certificate for each recipient in my Keychain to send them encrypted messages. Can Apple Mail not get those certificates from AD?
Apple Mail can pull S/MIME certificates from the GAL for encrypting messages
to recipients *IF* you have the Mac bound to AD and you have Keychain Access -> Preferences -> “Search directory services for certificates" checked. There are and always have been some other key issues that seem to trip folks up here on why they cannot sign
their own messages and cannot encrypt a message to someone. Keep in mind that Mail will request and use only a valid certificate.
Issues that cause failures in Singing & Encrypting Mail
-
Trust failures
-
Failed acquisition of the Trust Chain
-
Failed Trust of any of the certificates in the Chain
-
Expiration / Revocation of the certificate
-
Email Address / RFC822Name Mismatch
-
Case-sensitive for local-part: email@hidden
≠ email@hidden
-
Mismatched email address: email@hidden
≠ email@hidden
The use of a Smart Card to digitally sign your email messages has no connection to whether you can encrypt a message to someone. The
above conditions hold true for both signing the message as well as encrypting the message to the recipient(s).
If you are using Outlook or maybe even the old Entourage for S/MIME on the Mac, be aware of the issues related to unfortunate creation and use of the Microsoft Keychains:
Microsoft_Intermediate_Certificates
Microsoft_Entity_Certificates
If these keychains exist on your system Outlook/Entourage have historically, ONLY looked inside these keychains when attempting to resolve generating the Trust Path and validation on the certificates
in use. There were also historically some unfortunately ties to Messenger with these keychains, but if you do not use these other services, the best way to resolve the problem is simply to move the contents of those two keychains into a user’s keychain and
delete those two from the system. Be careful with this suggestion if you are using other MS services which, as I noted, may have direct dependencies on their existence.
Speaking of dependencies, There is an old Keychain “X509Anchors” located at /System/Library/Keychains/X509Anchors that
exists solely on the file system because of dependancies by some of the MS Applications but should NEVER be added to the Keychain list which you would see in Keychain
Access or view via: security list-keychains
Hopefully, everyone can indulge me for a brief moment on what I would call “out of control PKI misuse in the US Federal Government”. Let me use an example of a recent message I was copied on
from the DoD CIO as an example:
<image002.jpg><image004.jpg>
It was clearly allowed and processed on a Windows machine that was conveniently configured to just ignore the fundamentals of S/MIME.
On OS X, we correctly notify the user that there is an issue with the signature.
but this is where several folks point and say OS X doesn’t know how to properly handle S/MIME and certificate validation — to which of course I discuss with them the contents of this email thread.
:-)
I have previously mentioned and noted the same situation with messages that are sent out from "DISA Ft Meade FSO Mailbox IASE Mailing List” with email address of email@hidden
but digitally signed by a responsible individual with his CAC containing an S/MIME Signing Certificate with an RFC822Name of email@hidden.
Where on God’s Green Earth does this make any sense ?
PKI works and we can all have trust in it when systems follow standards, but I would challenge anyone to prove how this can be construed as following the standards.
And lets not get started on good old “Name Suppression” … :-)
On Mar 13, 2014, at 3:50 PM, William Cerniuk <email@hidden<mailto:email@hidden>
wrote:
A couple of things.
1 - Apple Mail is a little slow on the uptake. It can take a long time to recognize that you have the smart card installed
2 - Relaunching Apple Mail will frequently encourage it to look for the certs and find them
3 - the installer, as it is, puts all the files in the system and they conflict with one another (need to trim)
I will send you the installer I built to get around the problem in a moment if you are willing to test. Otherwise you can hand trim if you like.
1- Apple Mail is not seeing the event that a new keychain (ie. smart card) has recently been added (pcsc/ccid issues)
2- Relaunching Mail requests an updated Keychain listing which then can include a newly inserted smart card
3- Curious what installer puts all the files in the system and they conflict with one another.
What installer are you providing
and what problem are you trying to get around ?
On Mar 14, 2014, at 10:08 AM, "Levine, Jason (NIH/NCI) [E]” <email@hidden> wrote:
With all these folks who are reporting that it works for them, I buckled down to do some more testing this morning, and damn if I just can’t get it to work at ALL. I’ve tried on 10.9.2 and 10.9.redacted;
I have PKard 1.5 as my underlying PIV-enabling layer, and I definitely have the relevant Keychain Access checkbox checked that is supposed to search the directory for certs. But the only recipients I’m able to encrypt email to in Mail.app are those for whom
I already have certs in my keychain. (And I know my PIV is working fine otherwise, because (a) I’m able to SIGN email just fine, and (b) I can use it in other places, like decrypting email and signing into cert-enabled websites.)
Check the points I noted above and note that encrypting messages to others has no connection to your use of a Smart Card. You can encrypt messages selectively to individuals without you having
to digitally sign the message.
On Mar 24, 2014, at 8:58, Carib Mendez <email@hidden> wrote:
When encrypting mail, Apple Mail requires that the email address of the recipient EXACTLY matches the email address in the certificate, including CASE. We have a huge issue in that our security office issues CAC with
the email address all lowercase (as it should be) but our Help Desk creates the email account mixed case.
This is actually not a problem with the case on the server. When creating the email Account on OS X, simply place the correct case of the email address from the cert on the card into the configuration
and you will be fine. The client is then able to ensure and exact match regardless of how the case is on the server.
On Mar 26, 2014, at 1:18 PM, "Walls, Bryan K. (MSFC-EO50)" <email@hidden> wrote:
….
But, today, clearly case insensitivity has won.
Has won what ? I guess you realize I would disagree about this point. :-)
No one would expect that if they signed up for email@hidden, that email sent sent to email@hidden would
be going to a completely different person. Users would be outraged. And returning that email@hidden is an invalid address wouldn't be better. All typical users
would consider that behavior broken.
The historical basis is case-sensitive file systems on which mail servers ran at one point - case sensitive file-systems are still in use worldwide for various reasons.
Seems to me the RFC should be changed. The tricky part of the discussion would be non-English character sets and what case insensitivity means with that taken into account.
Exactly! Folks on this list unfortunately forget sometimes that there are other character sets and languages used around the world. You point would be valid if everything used ASCII characters for everything. Lets move beyond our belief that everything in
the world is in English and everything is in ASCII and then people may have a different opinion on this issue.
For folks following this far and still wanting to break PKI on OS X, keep in mind that you can use "Identity Preferences” to override the standards and use this mismatch of certificate
RFC822Names and email addresses in use. I have spoken of "Identity Preferences” before so will not go into it for this thread.
- Shawn
________________________________________
Shawn Geddis
Security Consulting Engineer
Apple Enterprise Division