Udostępnij za pośrednictwem

Using S/MIME certificates for non-repudiation

  • Artykuł

Our current S/MIME certificate based on the User template allows users to both encrypt and sign email, I have however been tasked with making sure our S/MIME certificates comply with our organizational requirements for non-repudiation.

The current certificate based on the User template is being archived for data recovery purposes – but this basically makes the non-repudiation value of it questionable as the archival implies an extra copy of it exists.
How can we divide the usage of this single certificate into two separate S/MIME certs to comply with non-repudiation requirements without confusing the end-user?

Whether a certificate can be used for email signing as well as email encryption depends on the combination of the EKU (Enhanced Key Usage) and the KU (Key Usage) extensions in it.

There are typically two ways to implement S/MIME in a PKI environment;

  • A) use a single key pair which can do both email signing and email encryption

        *or*

  • B) use a dual key pair where one can only do email signing and the other can only do email encryption.

In either case, the private key must have the “Secure Email” extension OID (1.3.6.1.5.5.7.3.4) as an EKU, *and*

(for email signing):
- must have the Digital Signature or Non-Repudiation OID’s as a Key Usage.

(for email encryption):
-  must have the Key Agreement or Data Encipherment OID’s as a Key Usage.

In the scenario where you have an S/MIME cert based on the User template which has both the “Secure Email” EKU OID and the Digital Signature and Data Encipherment KU OID’s –the same certificate can be used for both signing and encrypting emails (i.e. scenario “A”).

This is the typical setup for S/MIME based on simplified manageability and compatibility (some older clients may not support dual key pairs for S/MIME).

The “B” scenario is however the more secure of the two as it allows you to archive the encryption certificate (for data recovery purposes) without archiving the signing certificate (for non-repudiation purposes).

Outlook supports both single and dual key pair methods for S/MIME – the requirements are basically for any application using S/MIME to ask for certificates that fulfill the criteria for the usage that is being attempted (i.e. signing or encryption respectively) and use the appropriate certificate for each.

However, if you have two certificates that fulfill the criteria then the user may be required to select which one to use for the operation – but with the right setup the user should have only one certificate that fulfills each function and that one would be automatically picked.

Further details:

Key Archival and Management in Windows Server 2003
http://technet.microsoft.com/en-us/library/cc755395(WS.10).aspx

1.3.2.1 Key Archival
http://msdn.microsoft.com/en-us/library/cc249760(v=prot.10).aspx

5.1.10 Key Archival Security Considerationshttp://msdn.microsoft.com/en-us/library/cc249759(v=prot.10).aspx

Key archival is for decryption keys only. The purpose of key archival is the prevention of loss of data.

Understanding Key Archival
http://blogs.technet.com/b/pki/archive/2009/08/07/understanding-key-archival.aspx

OAB certificate filtering
http://blogs.technet.com/b/exchange/archive/2005/07/25/408188.aspx

X509KeyUsageFlags enumeration
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379410(v=vs.85).aspx

Comments

  • Anonymous
    November 13, 2014
    Using S/MIME certificates for non-repudiation - AD Troubleshooting - Site Home - TechNet Blogs