Hi, > 1) Is the mapping I have provided in my last post right or wrong ?
>From me view your mapping is correct, I would add RequireThumbprintReference >with thumbprint reference (certificate hash) - see my previous answer for >details. The best way however, is trying and validation this. > 2) As I have only <sp:RequireThumbprintReference/> for InitiatorToken and > RecipientToken policy assertion, what is the consequence for Token > reference ? Which one is mandatory (or not) with this policy assertion ? I would say that the thumbprint reference (certificate hash) is mandatory - I have sent sample in my previous mail. Regards, Andrei. > -----Original Message----- > From: COURTAULT Francois [mailto:[email protected]] > Sent: Dienstag, 17. Dezember 2013 16:01 > To: [email protected]; [email protected] > Cc: Andrei Shakirin > Subject: RE: Spec questions > > Hello guys, > > I really need your answers to the questions I have asked in my last post. > Could you look at those please ? > > Best regards. > > -----Original Message----- > From: COURTAULT Francois > Sent: vendredi 13 décembre 2013 17:46 > To: [email protected]; Andrei Shakirin > Cc: [email protected] > Subject: RE: Spec questions > > Hello, > > Any answer to my previous questions ? > > Best Regards. > > -----Original Message----- > From: COURTAULT Francois [mailto:[email protected]] > Sent: mercredi 11 décembre 2013 09:45 > To: Andrei Shakirin; [email protected] > Cc: [email protected] > Subject: RE: Spec questions > > Hello Andrei, > > Not sure to really understand you, sorry about that. > I want to figure out if, for token reference, as we may use 3 ways according > to the spec, depending on policy assertion like Require*, it is mandatory or > not to use such or such token reference way. I want also to know, in case of > some Require* assertions are missing, if a default behavior is expected. > > 1) Is the mapping I have provided in my last post right or wrong ? > 2) As I have only <sp:RequireThumbprintReference/> for InitiatorToken and > RecipientToken policy assertion, what is the consequence for Token > reference ? Which one is mandatory (or not) with this policy assertion ? > > Best Regards. > > -----Original Message----- > From: Andrei Shakirin [mailto:[email protected]] > Sent: mardi 10 décembre 2013 15:45 > To: COURTAULT Francois; [email protected] > Cc: [email protected] > Subject: RE: Spec questions > > Hi, > > In my understanding, if you specify Require*assertions, exactly this is > allowed to reference Token: > <sp:RequireKeyIdentifierReference /> - key identifier (for X.509 Subject Key > Identifier) <sp:RequireEmbeddedTokenReference /> - Binary Security Token > <sp:RequireIssuerSerialReference /> - issuer serial > <sp:RequireThumbprintReference> - thumbprint reference (certificate > hash), looks like: > > <wsse:SecurityTokenReference> > <wsse:KeyIdentifier > EncodingType="http://...-wss-soap-message-security- > 1.0#Base64Binary" > ValueType="http://.../oasis-wss-soap-message-security- > 1.1#ThumbprintSHA1" > >uYn3PK2wXheN2lLZr4n2mJjoWE0=</wsse:KeyIdentifier> > </wsse:SecurityTokenReference> > > Regards, > Andrei. > > > -----Original Message----- > > From: COURTAULT Francois [mailto:[email protected]] > > Sent: Dienstag, 10. Dezember 2013 11:59 > > To: [email protected]; [email protected] > > Cc: Andrei Shakirin > > Subject: RE: Spec questions > > > > Hello Colm, > > > > The only Require* I have in my policy file are: > > - <sp:RequireThumbprintReference/> for InitiatorToken and > > RecipientToken > > - <sp:RequireSignatureConfirmation/> > > > > Does one of the above policy assertion describes the way we have to > > reference the X509 token in the <wsse:SecurityTokenReference> ? > > If yes, I suppose that it is the <sp:RequireThumbprintReference/> but > > I don't see the link with 3 possible options we may have for token > reference: > > - Reference to a Subject Key Identifier > > - Reference to a Binary Security Token > > - Reference to an Issuer and Serial Number > > > > According to me, the links between policy assertions and token > > reference looks like below: > > - Reference to a Subject Key Identifier is required by the > > <sp:RequireKeyIdentifierReference /> presence > > - Reference to a Binary Security Token is required by the > > <sp:RequireEmbeddedTokenReference /> presence > > - Reference to an Issuer and Serial Number is requires by the > > <sp:RequireIssuerSerialReference /> presence > > > > This is why I am a little bit lost :-( and though requires your help. > > > > Best Regards. > > > > -----Original Message----- > > From: Colm O hEigeartaigh [mailto:[email protected]] > > Sent: mardi 10 décembre 2013 11:28 > > To: COURTAULT Francois > > Cc: Andrei Shakirin; [email protected] > > Subject: Re: Spec questions > > > > No, if you have a Require* Assertion, then only that is allowed to > > reference that token. > > > > Colm. > > > > > > On Mon, Dec 9, 2013 at 5:18 PM, COURTAULT Francois < > > [email protected]> wrote: > > > > > Hello guys, > > > > > > Thanks a lot for your explanations :-) The security assertion I only > > > have is RequireThumbprintReference. > > > > > > So in such case, does that mean that the 3 ways to reference an > > > X.509 token in <wsse:SecurityTokenReference>: > > > * Reference to a Subject Key Identifier > > > * Reference to a Binary Security Token > > > * Reference to an Issuer and Serial Number > > > > > > are allowed ? > > > > > > Best regards. > > > > > > -----Original Message----- > > > From: Andrei Shakirin [mailto:[email protected]] > > > Sent: lundi 9 décembre 2013 15:46 > > > To: [email protected]; COURTAULT Francois > > > Cc: [email protected] > > > Subject: RE: Spec questions > > > > > > Hi Colm, > > > > > > That was my missing piece of the my puzzle :) > > > > > > Thanks, > > > Andrei. > > > > > > From: Colm O hEigeartaigh [mailto:[email protected]] > > > Sent: Montag, 9. Dezember 2013 11:33 > > > To: COURTAULT Francois > > > Cc: Andrei Shakirin; [email protected] > > > Subject: Re: Spec questions > > > > > > > > > > I also interpret <sp:ProtectTokens/> in this way. If it is active, > > > > the > > > signature must protect the used token as well: > > > > > > +1. > > > > > > > They can be controlled through following policy assertions: ... > > > Note that the MustSupport* policy assertions only state the the > > > message initiator/recipient must be able to process various ways of > > > identifying keys. It doesn't mandate them. To do this, take a look > > > at the various policies associated with a particular token. For > > > example, the X509Token policy has the following optional policies: > > > > > > <sp:RequireKeyIdentifierReference ... /> ? > > > <sp:RequireIssuerSerialReference ... /> ? > > > <sp:RequireEmbeddedTokenReference ... /> ? > > > <sp:RequireThumbprintReference ... /> ? > > > Colm. > > > > > > > > > On Fri, Dec 6, 2013 at 6:17 PM, COURTAULT Francois < > > > [email protected]> wrote: > > > Hello Andrei, > > > > > > Thanks a lot for your interpretation :-) Colm could you confirm > > > please ? > > > > > > For my second question regarding SecurityTokenReference, I have only > > > the following policy assertions: > > > <sp:MustSupportRefKeyIdentifier/> > > > <sp:MustSupportRefIssuerSerial/> > > > <sp:MustSupportRefThumbprint/> > > > <sp:MustSupportRefEncryptedKey/> > > > <sp:RequireSignatureConfirmation/> > > > > > > My interpretation about MustSupportRefThumbprint, for example, is > > > that the initiator and the recipient MUST be able to process > > > references using Token thumbprints. This means that any URI (a > > > reference), in the Signature section, which contains token > > > thumbprint like URI="#X509-21B185F9A383FC218D138383549326938", has > to be processed: > > am > > > I correct ? > > > > > > If we have <sp:MustSupportRefKeyIdentifier/>, does that mean that we > > > have to have for the SecurityToken reference something like: > > > <wsse:SecurityTokenReference > > > xmlns:wsse=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-s > > > ec > > > ext-1.0.xsd > > > " > > > xmlns:wsse11=" > > > http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"; > > > xmlns:wsu=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-u > > > ti > > > lity-1.0.xsd > > > " > > > wsse11:TokenType=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-p > > > ro > > > file-1.0#X509v3 > > > " > > > > > > wsu:Id="str_22Ps0gftJ20pYdu9"> > > > <wsse:KeyIdentifier > > > EncodingType=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap- > message > > > - > > s > > > ecurity-1.0#Base64Binary > > > " > > > ValueType=" > > > http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#T > > > hu > > > mbprintSHA1 ">KRyiNJ91OZnOVXzLWazn3ISSs+s=</wsse:KeyIdentifier> > > > > > > </wsse:SecurityTokenReference> > > > > > > instead of > > > <wsse:SecurityTokenReference > > > > > > wsu:Id="STR-21B185F9A383FC218D138383549326940"> > > > <wsse:Reference > > > URI="#X509-21B185F9A383FC218D138383549326938" > > > ValueType=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token- > > profile-1.0#X509v3" > > > /> > > > > > > </wsse:SecurityTokenReference> ? > > > > > > Best Regards. > > > > > > -----Original Message----- > > > From: Andrei Shakirin [mailto:[email protected]] > > > Sent: vendredi 6 décembre 2013 18:01 > > > To: [email protected] > > > Cc: [email protected]; COURTAULT Francois > > > Subject: RE: Spec questions > > > > > > Hi, > > > > > > Colm knows the subject better, anyway short answer from me: > > > > > > > -----Original Message----- > > > > From: COURTAULT Francois > [mailto:[email protected]] > > > > Sent: Donnerstag, 5. Dezember 2013 14:32 > > > > To: [email protected] > > > > Cc: [email protected] > > > > Subject: Spec questions > > > > > > > > Hello everyone, > > > > > > > > I try to understand what policy requires that a Certificate > > > > reference has to be included in the SignedInfo section. > > > > Is it due to <sp:ProtectTokens/> policy assertion ? If I read > > > > the spec at §6.5, it was stated that: > > > > "This boolean property specifies whether signatures must cover the > > > > token used to generate that signature. If the value is 'true', > > > > then each token used to generate a signature MUST be covered by > > > > that > > > signature." > > > > > > > > My interpretation of this sentence is that the token used for the > > > > signature has to be included in the signature so that the > > > > SignedInfo section has to contain the token reference: is my > > > > interpretation correct > > > ? > > > > It also means that if we use Asymmetric binding, it is mandatory > > > > to have in the SignedInfo section something like: > > > > <ds:Reference URI="X509-<thumbprint>>: right ? > > > > > > I also interpret <sp:ProtectTokens/> in this way. If it is active, > > > the signature must protect the used token as well: > > > > > > <wsse:BinarySecurityToken> > > > xmlns:wsu=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-u > > > ti > > > lity-1.0.xsd > > > " > > > EncodingType=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-messa > > > ge-security-1.0#Base64Binary" > > > ValueType=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token- > > profile-1.0#X509v3" > > > wsu:Id="CertId-3201971"> ... > > > </wsse:BinarySecurityToken> > > > > > > <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; > > > Id="Signature-20079748"> > > > <ds:SignedInfo> > > > <ds:CanonicalizationMethod \ > > > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; /> > > > <ds:SignatureMethod Algorithm=" > > > http://www.w3.org/2000/09/xmldsig#rsa-sha1"; \ /> ... > > > <ds:Reference URI="#CertId-3201971"> > > > <ds:Transforms> > > > <ds:Transform Algorithm=" > > > http://www.w3.org/2001/10/xml-exc-c14n#"; /> > > > </ds:Transforms> > > > <ds:DigestMethod Algorithm=" > > > http://www.w3.org/2000/09/xmldsig#sha1"; /> > > > <ds:DigestValue> > > > 5eik4SB6Q0N9fWnyA9HDtDnfjeY=</ds:DigestValue> > > > </ds:Reference> > > > ... > > > </ds:SignedInfo> > > > </ds:Signature> > > > > > > > > > > > I have also another questions. In the spec at §3.2 Token > > > > References, it is stated that the: > > > > " <wsse:SecurityTokenReference> element MAY reference an X.509 > > token > > > > type by one of the following means: > > > > > > > > · Reference to a Subject Key Identifier > > > > > > > > · Reference to a Binary Security Token > > > > > > > > · Reference to an Issuer and Serial Number" > > > > Could you confirm me that the 3 means are possible and equivalent ? > > > > Or depending on a security policy assertion, we have to use only > > > > one of these methods ? > > > > > > > > > > 1. The Reference to a Subject Key Identifier means that > > > SecurityTokenReference contains KeyIdentifier with X509 SubjectDN. > > > X509 certificate can be found based on this data. > > > 2. The Reference to a Binary Security Token means that X509 is > > > embedded into message security header and just referenced from the > > signature: > > > <wsse:BinarySecurityToken > > > EncodingType=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap- > message > > > - > > s > > > ecurity-1.0#Base64Binary > > > " > > > ValueType=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-p > > > ro > > > file-1.0#X509v3 > > > " > > > > > > wsu:Id="X509-21B185F9A383FC218D138383549326938">... > > > </wsse:BinarySecurityToken> > > > ... > > > <wsse:SecurityTokenReference > > > > > > wsu:Id="STR-21B185F9A383FC218D138383549326940"> > > > <wsse:Reference > > > URI="#X509-21B185F9A383FC218D138383549326938" > > > ValueType=" > > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token- > > profile-1.0#X509v3" > > > /> > > > </wsse:SecurityTokenReference> 3. The > > > Reference to an Issuer and Serial Number is other way to identify > > > X509 certificate - provider Issuer DN and serial number that also > > > identify certificate unambiguously. In this case > > > SecurityTokenReference contains X509Data element with > X509IssuerSerial. > > > > > > AFAIK all are possible. > > > > > > They can be controlled through following policy assertions: > > > > > > §9.2: > > > /sp:Wss11/wsp:Policy/sp:MustSupportRefKeyIdentifier > > > This optional element is a policy assertion indicates that the [Key > > > Identifier References] property is set to 'true'. > > > > > > /sp:Wss11/wsp:Policy/sp:MustSupportRefIssuerSerial > > > This optional element is a policy assertion indicates that the > > > [Issuer Serial References] property is set to 'true'. > > > > > > /sp:Wss11/wsp:Policy/sp:MustSupportRefExternalURI > > > This optional element is a policy assertion indicates that the > > > [External URI References] property is set to 'true'. > > > > > > /sp:Wss11/wsp:Policy/sp:MustSupportRefEmbeddedToken > > > This optional element is a policy assertion indicates that the > > > [Embedded Token References] property is set to 'true'. > > > > > > /sp:Wss11/wsp:Policy/sp:MustSupportRefThumbprint > > > This optional element is a policy assertion indicates that the > > > [Thumbprint References] property is set to 'true'. > > > > > > /sp:Wss11/wsp:Policy/sp:MustSupportRefEncryptedKey > > > This optional element is a policy assertion indicates that the > > > [EncryptedKey References] property is set to 'true'. > > > > > > /sp:Wss11/wsp:Policy/sp:RequireSignatureConfirmation > > > This optional element is a policy assertion indicates that the > > > [Signature Confirmation] property is set to 'true'. > > > > > > Regards, > > > Andrei. > > > > > > > > > > > Best Regards. > > > > > > > > ________________________________ > > > > This message and any attachments are intended solely for the > > > > addressees and may contain confidential information. Any > > > > unauthorized use or disclosure, either whole or partial, is prohibited. > > > > E-mails are susceptible to alteration. Our company shall not be > > > > liable for the message if altered, changed or falsified. If you > > > > are not the intended recipient of this message, please delete it > > > > and notify the > > > sender. > > > > Although all reasonable efforts have been made to keep this > > > > transmission free from viruses, the sender will not be liable for > > > > damages caused by a transmitted virus > > > > > > This message and any attachments are intended solely for the > > > addressees and may contain confidential information. Any > > > unauthorized use or disclosure, either whole or partial, is prohibited. > > > E-mails are susceptible to alteration. Our company shall not be > > > liable for the message if altered, changed or falsified. If you are > > > not the intended recipient of this message, please delete it and notify > the sender. > > > Although all reasonable efforts have been made to keep this > > > transmission free from viruses, the sender will not be liable for > > > damages caused by a transmitted virus > > > > > > > > > > > > -- > > > Colm O hEigeartaigh > > > > > > Talend Community Coder > > > http://coders.talend.com > > > > > > This message and any attachments are intended solely for the > > > addressees and may contain confidential information. Any > > > unauthorized use or disclosure, either whole or partial, is prohibited. > > > E-mails are susceptible to alteration. Our company shall not be > > > liable for the message if altered, changed or falsified. If you are > > > not the intended recipient of this message, please delete it and notify > the sender. > > > Although all reasonable efforts have been made to keep this > > > transmission free from viruses, the sender will not be liable for > > > damages caused by a transmitted virus > > > > > > > > > > > -- > > Colm O hEigeartaigh > > > > Talend Community Coder > > http://coders.talend.com > > > > This message and any attachments are intended solely for the > > addressees and may contain confidential information. Any unauthorized > > use or disclosure, either whole or partial, is prohibited. > > E-mails are susceptible to alteration. Our company shall not be liable > > for the message if altered, changed or falsified. If you are not the > > intended recipient of this message, please delete it and notify the sender. > > Although all reasonable efforts have been made to keep this > > transmission free from viruses, the sender will not be liable for > > damages caused by a transmitted virus > > This message and any attachments are intended solely for the addressees > and may contain confidential information. Any unauthorized use or > disclosure, either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for the > message if altered, changed or falsified. If you are not the intended > recipient > of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission > free from viruses, the sender will not be liable for damages caused by a > transmitted virus > > This message and any attachments are intended solely for the addressees > and may contain confidential information. Any unauthorized use or > disclosure, either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for the > message if altered, changed or falsified. If you are not the intended > recipient > of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission > free from viruses, the sender will not be liable for damages caused by a > transmitted virus
