[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi] Groups - SKSML-DRAFT7 Specification, XSD and sample instances(ZIP) (sksml-draft7.zip) uploaded
Maybe you need OO 3.0, Tomas. I last edited the document using 3.0, so perhaps there is a bug that causes OO 2.4 to incorrectly read TOCs. I also realized that I forgot to address the more important comment related to certificates. My apologies. The SKSML protocol does not specify which public-key to use to encrypt symmetric-keys on the server or the clients, because that is a site-implementation detail. A site implementing an SKMS can make its own determination how it wants to implement this part of the EKMI security. Some sites may want to choose a single transport certificate for all clients while others may choose individual ones. Some may choose to combine the signing and encryption capabilities into the same certificate while others may separate it. I don't believe the messaging protocol should specify this. However, in the StrongKey implementation, we force the requirement that the SKS server MUST have the encryption certificate in its database for each authorized client before it will transport the symmetric key to the requestor. This enforces the security policy that the SKS server only sends responses back to clients protected with a transport key it already knows about. Additionally, because all database records in the SKS database are digitally signed, an attacker attempting to replace this certificate directly in the DBMS, with one of their own, will fail to get the symmetric key because the signature will fail on the object; only the authorized Administrator through the console can modify objects in the DB and recreate a new signature on the DB object using the private key on the HSM on the server. So, while the WSS header does have the certificate in it, I need to review the WSS protocol to see if a site can dispense sending it around for the transport key; it may still be necessary for the signing certificate to be in the WSS header. I hope that answers the question. Arshad Tomas Gustavsson wrote: > > Yes I am using OpenOffice 2.4 on Ubuntu 8.04. On page 44 the heading says: > 2.1 Element <KeyClasses> and <KeyClass> > according to the TOC it should be 4.3 and on page 42. > > If I update the TOC it changes... > > The PDF is correct though, so I don't know what secret sauce OpenOffice > is drinking... > > /Tomas > > Arshad Noor wrote: >> Thanks for your comments, Tomas and for catching the errors. >> >> I'm not sure how you're seeing section numbers 1.3, 1.8, etc. >> since these examples are in Chapter 3. Additionally, section >> 4.5 is there; on page 44 as the TOC says so. >> >> Are you using OpenOffice 2.4 or 3.0 to see the editable version? >> Even the PDF looks correct to me in Acrobat Reader 8.1.2 (Linux). >> >> Arshad >> >> P.S. Everybody probably got the e-mail about the update I made >> to DRAFT7, but if not, here it is again: >> >> http://www.oasis-open.org/committees/document.php?document_id=29997 >> >> >> Tomas Gustavsson wrote: >>> >>> Hi Arshad, I have a few very small comments. >>> >>> First a few editorial comments: >>> ----- >>> 1.3 >>> Strange sentence: >>> The client application (linked to the call SKCL) will an API method >>> within the SKCL for the appropriate symmetric key. >>> -> >>> The client application (that has been linked to the SKCL) will call >>> an API method within the SKCL for the appropriate symmetric key. >>> >>> Chapters: >>> 1.8 Response with multiple new symmetric keys >>> 1.1 Response with an SKS error ?? >>> >>> Actually chapter numbering is completely off, I was trying to find >>> "4.5 Element <SymKeyResponse"" from the table of contents, but it is >>> not to be found. >>> >>> 1.1 Response with a pending Request ID >>> Sentence cut: >>> "Alternatively, when the" >>> ----- >>> >>> And last a small comment, I followed your discussion with Anders >>> Rundgren and it's kind of related. >>> ----- >>> There is no specification which public key is used to encrypt the >>> symmetric key returned in the <SymKey> type. Is it the "ValueType >>> attribute containing the value >>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3."; >>> from the <SymKeyRequest>? >>> >>> This puts some limitations on this certificate, i.e. KeyUsage >>> digitalSignature, keyEncipherment, but these limitations I understand >>> is part of the profile as you have explained to Anders, which is fine >>> with me. >>> >>> Some words of specifying with what you encrypt the SymKey is needed I >>> think. >>> ----- >>> >>> Regards, >>> Tomas >>> >>> arshad.noor@strongauth.com wrote: >>>> Hi folks, >>>> >>>> My apologies for taking some time to finish this, but there were far >>>> more >>>> ripple effects with the inclusion of support for asynchronous >>>> messaging and >>>> the Standard Error Codes. However, the Public Review 02 >>>> Specification is >>>> complete. >>>> >>>> Here is a synopsis of the changes: >>>> >>>> This version includes the following changes: >>>> >>>> 01) Created the SymkeyWorkInProgressType to support asynchronous >>>> requests >>>> and responses between SKCLs and SKS servers. While the SKSML >>>> request >>>> >>>> will still be enclosed in a SOAP element with a digital >>>> signature, the >>>> >>>> request may now be sent over other protocols besides HTTP (such >>>> as SMTP). >>>> 02) Created a SymkeyRequestID element and >>>> SymkeyRequestIDType to allow >>>> the >>>> client and server to track an asynchronous request and response. >>>> 03) Created the RequestCheckIntervalType to allows the SKS >>>> server to tell >>>> clients how frequently they may poll a server on a >>>> work-in-progress request. >>>> 04) Modified SymkeyType to include the SymkeyRequestID >>>> element to >>>> correlate >>>> symkey responses with requests on the client side. >>>> 05) Modified SymekyError to include the SymkeyRequestID element >>>> to correlate errors with requests on the client side. >>>> >>>> 06) Added SKMS Standard Error Codes & Messages in Appendix C. >>>> >>>> 07) Added the Vendor Process for requesting a reserved block of SKMS >>>> Error >>>> Codes in Appendix D. >>>> >>>> Please review these changes. I am submitting a ballot for the TC to >>>> submit >>>> this for Public Review. We are required to do this for 15 days >>>> given that >>>> we have made changes to the protocol. The TC will have approximately 3 >>>> weeks (1 week for ballot + 2 weeks for PR2) to get comments back on >>>> these >>>> changes. However, I would encourage you to submit feedback as early as >>>> possible. >>>> >>>> Once we are complete with PR2 and have addressed any comments at >>>> that time, >>>> we will be at the penultimate step of the standards vote. >>>> >>>> Thanks for your patience. >>>> >>>> -- Arshad Noor* >>>> >>>> The document named SKSML-DRAFT7 Specification, XSD and sample instances >>>> (ZIP) (sksml-draft7.zip) has been submitted by Arshad Noor* to the >>>> OASIS >>>> Enterprise Key Management Infrastructure (EKMI) Technical Committee >>>> document repository. >>>> >>>> Document Description: >>>> DRAFT 7 of the SKSML 1.0 Specification (Public Review 02), the EKMI XML >>>> Schema Definition and sample schema instances. >>>> >>>> View Document Details: >>>> http://www.oasis-open.org/committees/document.php?document_id=29914 >>>> >>>> Download Document: >>>> http://www.oasis-open.org/committees/download.php/29914/sksml-draft7.zip >>>> >>>> >>>> >>>> PLEASE NOTE: If the above links do not work for you, your email >>>> application >>>> may be breaking the link into two pieces. You may be able to copy >>>> and paste >>>> the entire link address into the address field of your web browser. >>>> >>>> -OASIS Open Administration
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]