Sarbanes-Oxley Was: [pki-tc] Extranet S/MIME?

["Anders Rundgren" <anders.rundgren@telia.com>]

Arshad,

 

I must confess that I was not aware of the fact that signing an e-mail also sends along an "associated" encryption certificate.  I assume that this is an undocumented "feature" and not a part of the S/MIME standard?

 

Anyway, when you refer to the security issue that David raise, I doubt that we are in full agreement.  That is, it all depends on what we mean by "security".

 

I personally find it odd that enterprises (including my own), keep highly confidential company data on servers that usually can be accessed by more than one person, but that the very same enterprise would support the idea that business communication should be entirely private in spite of (hopefully) being a part of the organization's life.  This is in my opinion a sign of a "security mismatch", here not even considering viruses etc.

 

The key escrow scheme that David mentioned is not only a prerequisite, it is also a source of considerable costs and hassles.  In addition, key escrow only supports inbound messages, leaving the enterprise in a potentially bad situation with respect to outgoing messages.

 

---

I guess it would be pretty embarrassing to ask an external business party to escrow a message from one of your own employees, in the case you suspected (you can only guess) it contained some information that you need to see.  Is this even in accordance with regulations like Sarbanes-Oxley?

---

 

Due to this, I believe that message encryption a la S/MIME should generally be avoided as it suffers from weaknesses that no directory or key management schemes seem likely to ever be able to cope with.  In addition, there are serious other "gaps" like: http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf

 

Transport encryption like featured in browsers OTOH, is already used by the entire Internet community, comprising of a BILLION+ of relying parties.  That's the difference between a "community-scale" security solution like S/MIME (in e-mail), and an "Internet-scale" security solution.

 

It is a bit unfortunate that the US public sector have settled on a community-based security solution as the public sector by definition is designed to serve the entire society.  Their Scandinavian counterparts have due to this taken another route, and I believe that they in spite of being late and under-financed, will eventually be more successful in deploying secure services based on PKI.

 

Anders Rundgren

PKI Architect etc. (working for a major computer security company but the views expressed here are my own and does not necessarily represent that of my employer)

 

----- Original Message -----

From: "Arshad Noor" <arshad.noor@strongauth.com>

To: "Skyberg, David" <dskyberg@rsasecurity.com>

Cc: <licather@wellsfargo.com>; <pki-tc@lists.oasis-open.org>

Sent: Friday, January 07, 2005 03:14

Subject: Re: [pki-tc] Extranet S/MIME?

Comments embedded, David.

Arshad Noor
StrongAuth, 
Inc.


Skyberg, David wrote:
> Two comments.  First, 
exchanging keys by sending signed emails only
> works in single key 
systems.  For enterprises, I would recommend a dual
> key system so 
that encryption keys can be escrowed to safeguard the
> availability of 
corporate IP.
> 
The first part of your comment is not true, 
David.  Even with
dual-key systems, the act of signing a message will 
always
send out the encryption certificate to the recipient.  I 
have
successfully tested signing a message in Outlook & 
Netscape
Messenger with signing certs from a dual-key based PKIs, and
when 
when you respond from another PC (using Thunderbird or
Netscape - Outlook has 
some issues with it that are tied to
Exchange Servers, but which can still be 
addressed) you can
indeed, encrypt the message back to the sender.

I 
agree with you about dual-key PKI's; that is our standard
implementation 
practice for all the PKI's we've executed.

> Second, you really need 
to check the IT security constraints of the
> partner enterprises.  
Some enterprises do not allow encrypted email
> through because of the 
obvious security risks.  See Anders' email for
> ways around that 
issue that do not entail deploying PKI to the end user.
> 
<soapbox>
This is a current failing of the infrastructure.  If 
PKI's were
generally used, mail-servers would have the ability to 
filter
based on signed messages, and allow only messages from 
trusted
certs/CA's to enter the network.  (You can still do this 
today
with some programmable MTAs).

If the resources that're going 
towards solving the "phishing"
problem were to be redirected towards building 
large scale
trust networks, many of the current security ills that we 
see
on the Internet today, could be addressed without band-aids.
But then 
again, I'm preaching to the choir, aren't I? 
:-)
</soapbox>


> 
>>-----Original 
Message-----
>>From: Arshad Noor 
[mailto:arshad.noor@strongauth.com]
>>Sent: Wednesday, January 05, 2005 
6:12 PM
>>To: licather@wellsfargo.com
>>Cc: pki-tc@lists.oasis-open.org
>>Subject: Re: [pki-tc] Extranet 
S/MIME?
>>
>>Catherine,
>>
>>Encryption in 
S/MIME works counter-intuitively to what one expects -
>>the decryption 
of encrypted S/MIME messages does not require the
>>sender to have a 
digital certificate at all (he/she does need to
>>have the RECIPIENT's 
certificate though, to encrypt the message in
>>the first place).  
The recipient need only have the private key to
>>their encryption 
certificate to decrypt the S/MIME contents.
>>
>>If your goal 
is only encrypted S/MIME, then you do need to setup a
>>repository 
(typically, an LDAP directory) where the encryption cert
>>of the 
recipient is available to senders.  If setting up such 
a
>>repository is not feasible, an alternate way to ensure that 
senders
>>have the recipients' encryption certificate is to have the 
recipients
>>send a digitally signed e-mail to all senders.  This 
automatically
>>sends the the signers' digital certificates in the 
S/MIME object.
>>Compliant S/MIME tools - such as Netscape's Messenger, 
Outlook
>>Express, (haven't tested Thunderbird yet - but will probably 
work)
>>will automatically import the senders' digital certificates 
into the
>>local address book.
>>
>>The next time the 
sender wants to send the recipient an encrypted
>>message, the 
recipients' encryption cert will already be available
>>to them locally 
to perform the encryption, thus obviating the need
>>to access a 
repository for the encryption cert.
>>
>>Hope that 
helps.
>>
>>Arshad Noor
>>StrongAuth, 
Inc.
>>
>>licather@wellsfargo.com 
wrote:
>>
>>>Hi 
All,
>>>
>>>
>>>
>>>I'm seeking 
expert opinions and recommendations how to support
> 
> 
S/MIME
> 
>>>communications in an extranet. Specially, 
decrypting an encrypted
> 
> email
> 
>>>from 
another company, i.e., the recipient needs to get hold of 
the
>>>certificate of the email author's. Does that mean, there 
needs to be
> 
> an
> 
>>>extranet directory 
service to facilitate obtaining certificates? If
> 
> not,
> 
>>>what service needs to be setup to facilitate 
that?
>>>
>>>
>>>
>>>Thank you 
in advance,
>>>
>>>Catherine 
Li
>>>
>>>CAST PKI 
Development
>>>
>>>Wells Fargo 
Services
>>>
>>>Office:   
415.243.6228
>>>
>>>Fax:      
415.975.6780
>>>
>>>MAC:    
A0186-056
>>>
>>>Email:   licather@wellsfargo.com
>>>
>>>
>>>
>>>This message 
may contain confidential and/or privileged information.
> 
> 
If
> 
>>>you are not the addressee or authorized to receive 
this for the
>>>addressee, you must not use, copy, disclose, or take 
any action
> 
> based on
> 
>>>this message or any 
information herein.  If you have received this
>>>message in 
error, please advise the sender immediately by reply
> 
> 
e-mail
> 
>>>and delete this message.  Thank you for your 
cooperation.
>>>
>>
>>
>>To unsubscribe 
from this mailing list (and be removed from the roster
> 
> 
of
> 
>>the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/pki-
>>tc/members/leave_workgroup.php.
> 
> 


To unsubscribe from this mailing list (and be removed from the 
roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/leave_workgroup.php.