Case sensativity: I think I’ve seen this same thread on this list many times over the past, well at least 7 years but probably more… sigh
I will add since I don’t see it specifically referenced and it is only 4 years old: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile - section 7.5 http://tools.ietf.org/html/rfc5280#section-7.5 "rfc822Name
choice, which is defined as type IA5String. To accommodate email addresses with internationalized domain names using the current structure, conforming implementations MUST convert the addresses into an ASCII representation.” And for what matches it is very
specific: "Two email addresses are considered to match if: 1) the local-part of each name is an exact match, AND 2) the host-part of each name matches using a case-insensitive ASCII comparison.” So to summarize, to the left of @ is considered a match if
an exact match, and to the right of @ can be a case-insensitive match.
Apple has been “conforming” since way before that was in the PKI certificate standard, so their basis in the original decision to be strict is just more reenforced by it. Here is a thread from 2007: http://lists.apple.com/archives/fed-talk/2007/Jul/msg00043.html
There are many others. This is not new and if the past it to repeat itself all the complaints will not make Apple budge on this… My professional advice is to deal with it and match case with accounts and certificates, or use a different non-Apple email client
for SMIME that allows for case insensitivity.
I will add, I think there are multiple arguments being made here involving PKI certificate standards, SMIME standards, email server / account configuration, and list-server compatibility.
As far as email servers / accounts: Since email is sent through email accounts configured on the servers (exchange for example), the email account and what is in the PKI certificate should match. If case sensitivity is optional for some aspects end-to-end
SMIME but required for others, then to be compatible with all, that would indicate the strictest common denominator is what is required for interoperability.
As for list servers that adulterate headers as to be sent from a list and not the original sender, that obviously is not configured to support SMIME... Yes people are attempting to use SMIME with a service that does not support it, most likely because
they have a policy to sign all messages or all messages with links yet the users still have a business case to use these legacy list servers. I think that is a completely different issue though, and not directly related to case sensitivity with email server
account and x509 Certificate Subject Alternative Name / RFC 822 Name. Discussions should not conflate the two issues.
I will add on this subject that the use of identity preferences to compensate for the email account / certificate case mismatch, it is not as simple as it sounds. If one tries to communicate on a thread for people with such mismatches, it requires manually
changing the account addresses that auto-populate when clicking reply-all, on every reply. It is extremely tedious and yes it could be used as a short-term mitigation, but I would not recommend subjecting users to such a process long term.
There are alternate SMIME capable email clients available if one does not wish to recognize this case sensitivity as implemented by Apple in their Mail clients.
Ridley DiSiena, CISSP
On Mar 29, 2014, at 12:17 AM, Henry B Hotz < email@hidden> wrote:
On Mar 28, 2014, at 10:52 AM, "Neely, Lee" < email@hidden> wrote:
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.
5321 says:
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
and extension name keywords) are not case sensitive, with the sole
exception in this specification of a mailbox local-part (SMTP
Extensions may explicitly specify case-sensitive elements). That is,
a command verb, an argument value other than a mailbox local-part,
and free form text MAY be encoded in upper case, lower case, or any
mixture of upper and lower case with no impact on its meaning. The
local-part of a mailbox MUST BE treated as case sensitive.
Therefore, SMTP implementations MUST take care to preserve the case
of mailbox local-parts. In particular, for some hosts, the user
"smith" is different from the user "Smith". However, exploiting the
case sensitivity of mailbox local-parts impedes interoperability and
is discouraged. Mailbox domains follow normal DNS rules and are
hence not case sensitive.
Without reading 5380 (+6818) on this point, I think some of the issues fall between standards. It seems clear that the people writing the mail standards feel it's a Really Bad Idea™ to make case matter in email addresses, but you'd bloody well better make it
*possible* to matter.
The care in the wording of the above spec suggests to me that there was some serious discussion of the issue. That suggests to me that someone wanting to change the spec will need to research the concerns of the people involved at the time and make sure they
are still satisfied by any new spec. It also means building consensus for new language will take a lot of effort. (-: Am I repeating T. Miller? ;-)
As for what Apple does: I think they are within the spec. However I also think most people think what Apple is doing is a Really Bad Idea™ because it "impedes interoperability".
---------
OK, I just went back and glanced through 5380 and found the following interesting sentence in the Security Considerations section:
Implementers should not
include an email address in the emailAddress attribute if the email
server that hosts the email address treats the local-part of email
addresses as case sensitive.
If you feel like playing word games, then it says that you shouldn't put an emailAddress in a cert if you're sending mail to a Mac. Without reading the two referenced RFCs (or successors) I have no opinion on what it really, practically means.
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.
Yes. I expect that smart card PKI is generally not handled by the email or Mac platform departments. |-P
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
_______________________________________________
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
|