[Fwd: Re: Signing and Encrypting with the same key?]

[Arshad Noor <arshad.noor@strongauth.com>]

FYI.

-------- Original Message --------
Subject: Re: Signing and Encrypting with the same key?
Date: Tue, 04 Nov 2008 13:24:28 -0800
From: Arshad Noor <arshad.noor@strongauth.com>
Organization: StrongAuth, Inc.
To: Anders Rundgren <anders.rundgren@telia.com>
CC: Timothy J. Miller <tmiller@mitre.org>,  Peter Gutmann 
<pgut001@cs.auckland.ac.nz>, ietf-pkix@imc.org
References: <E1KwTQG-0003Ms-IF@wintermute01.cs.auckland.ac.nz> 
<B9A9F0E608D94D2CA899102A88789787@AndersPC> <490F05DC.6060909@mitre.org> 
<87FE58DD430A4A48B3B2A522F95DB5AF@AndersPC> 
<4910AC79.1030703@strongauth.com> 
<BF063727CD004F48A55526D90AABB206@AndersPC>

Hi Anders,

The reason we haven't mentioned it yet is because the TC is going
to begin the task of creating Implementation, Operations and Audit
Guidelines for EKMI only in 2009.  It is within these guidelines
where a recommendation for separating signing & encryption key-pairs
would be made.

The SKSML protocol focuses on the minimum necessary syntax to send
and receive messages related to symmetric-key management.  The
security, implementation, operations and audit of such Enterprise
Key Management Infrastructures must be capable of being abstracted
out of the protocol, layered and managed independently.  Which is
why there is no mention of separated key-pairs yet.  However, you
can expect to see it in the Guidelines next year.

Arshad Noor
StrongAuth, Inc.


Anders Rundgren wrote:
> Hi Arshad,
> I just skimmed through the non-normative spec and example and from that I could not see any
> mentioning of separate keys.
> 
> I digged a bit further but could still not find such references in:
> http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf
> 
> I don't know what you have planned, but IMO you need additional elements in the protocol (like 
> giving the client a place to put its encryption key), as well as a standard for how encryption and 
> signature keys link together otherwise the server cannot be sure that it is encrypting for the 
> client that authenticated.  All this is the reason why I'm not overly enthusiastic of having 
> multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard about 
> to date, have been based on flawed implementations, which is moderately interesting from a 
> *protocol-design* point-of-view:
> http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html
> 
> But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can 
> build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2 is 
> designed to cope with a fragmented world and thus sports a capability/policy negotiation facility.
> 
> Anders
> 
> ----- Original Message ----- 
> From: "Arshad Noor" <arshad.noor@strongauth.com>
> To: "Anders Rundgren" <anders.rundgren@telia.com>
> Cc: "Timothy J. Miller" <tmiller@mitre.org>; "Peter Gutmann" <pgut001@cs.auckland.ac.nz>; 
> <ietf-pkix@imc.org>
> Sent: Tuesday, November 04, 2008 21:11
> Subject: Re: Signing and Encrypting with the same key?
> 
> 
> Anders,
> 
> Just to clarify, the SKSML protocol does not mandate how the
> digital certificate of SKMS clients and servers should be
> constructed, or what the keyUsage extension should look like
> within such certificates.  We believe that that is an
> implementation detail of the PKI that supports the SKMS.
> 
> The SKMS only requires that every client and server have a
> signing key and an encryption key.  They can be the same
> key-pair or two different key-pairs, depending on the PKI
> certificate policy of the implementation site.
> 
> Within the open-source StrongKey software we have, we require
> two digital certificates to be configured for SKMS clients and
> servers, to separate signing and encryption uses.  The test
> certs we bundle with the FOSS, combines signing & encryption
> merely as a convenience for people "kicking the tires".
> 
> As a conservative practice, we recommend that PKIs separate
> the signing and encryption capability into different digital
> certificates.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> Anders Rundgren wrote:
>> Another reference is OASIS EKMI:
>> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>> From what I can deduct they indeed authenticate the requesting client through a signature and then
>> return the key by wrapping it by the public signature key.
>>
>