[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SKSML Was: Signing and Encrypting with the same key?
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. >>> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]