Re: SKSML Was: Signing and Encrypting with the same key?

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

To paraphrase the Public Review 02 specification (which should be
available on the OASIS site by the end of this week):

"..conforming implementations of the SKSML protocol MUST enclose all 
SKSML messages between participants in an SKMS, in the SOAP Body of a 
SOAP Envelope.  Additionally, the contents of the SOAP Body MUST be 
secured using digital signatures conforming to [XMLSignature] in the 
SOAP Header.  Specifically, the SOAP Header of the SOAP Envelope MUST 
enclose a Security element conforming to [WSS] with a ValueType 
attribute containing the value 
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3.";

Yes, all SKMS clients and servers are mandated to use a certain security
convention in SOAP, but the SKSML message is oblivious of its envelope. 
  Secondly, how the digital certificates are constructed, how the client
and server key-pairs are managed, how the PKI is setup, managed and
audited, is not in the SKSML protocol.

That is what I meant by "abstracting the security, implementation,
operations and audit" of an EKMI out of the protocol.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
> Arshad,
> 
> Pardon my ignorance but I do not see how you can "abstract out" security solutions in a concrete 
> SOAP specification, either it is there or it is not.  That is, with respect to the particular 
> question and the current draft, you have no real alternative except stating that client and servers 
> must be configured to support a common convention.  Which BTW may be exactly what you meant :-) 
> That KeyGen2 is a 6-pass protocol is for avoiding conventions since the entities involved typically 
> do not belong to the same "IT-domain".  E.g. a consumer with a mobile phone and his/her bank.
> 
> Regarding the separate key stuff, the current strategy is to support it in the protocol, but not in 
> the Open Source client-implementation since no compelling argument actually has been raised for 
> having multiple keys, while there is quite a bunch of arguments against such an arrangement.  How is 
> an SKSML server supposed to know what to encrypt with if you do not send the key in the request?  It 
> seems that an SKSML server must keep an encryption key database or be configured to use LDAP etc. 
> It seems like a more straightforward solution to transfer encryption keys explicitly and validate 
> them at receival in the same way as you do with signature and authentication keys.
> 
> I'm a bit puzzled regarding how you intend to bootstrap SKSML with PKI, if the figures with a myriad 
> of entirely different clients are still valid.  The reason I started the KeyGen2 effort is because 
> this is a veritable nightmare, particularly for mobile devices.  As a comparison I would like to 
> mention the fact that there are some 100M TPM chips out there in major laptops, but they are "mostly 
> of out work" because the bootstrapping issues haven't been fully addressed by the TPM designers.
> 
> 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 22:24
> Subject: Re: Signing and Encrypting with the same key?
> 
> 
> 
> 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.
>>>
>