You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by COURTAULT Francois <Fr...@gemalto.com> on 2013/12/05 14:31:42 UTC
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 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 ?
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
RE: Spec questions
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Hello guys,
Finally I have understood what you have said after reading the spec located at https://www.oasis-open.org/committees/download.php/13383/wss-v1.1-spec-pr-x509TokenProfile-01.htm#_Toc105230346
Thanks a lot for you help :-)
Best Regards.
-----Original Message-----
From: Andrei Shakirin [mailto:ashakirin@talend.com]
Sent: mardi 17 décembre 2013 16:45
To: users@cxf.apache.org
Cc: coheigea@apache.org; COURTAULT Francois
Subject: RE: Spec questions
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:Francois.COURTAULT@gemalto.com]
> Sent: Dienstag, 17. Dezember 2013 16:01
> To: users@cxf.apache.org; coheigea@apache.org
> 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: users@cxf.apache.org; Andrei Shakirin
> Cc: coheigea@apache.org
> Subject: RE: Spec questions
>
> Hello,
>
> Any answer to my previous questions ?
>
> Best Regards.
>
> -----Original Message-----
> From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> Sent: mercredi 11 décembre 2013 09:45
> To: Andrei Shakirin; users@cxf.apache.org
> Cc: coheigea@apache.org
> 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:ashakirin@talend.com]
> Sent: mardi 10 décembre 2013 15:45
> To: COURTAULT Francois; users@cxf.apache.org
> Cc: coheigea@apache.org
> 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:Francois.COURTAULT@gemalto.com]
> > Sent: Dienstag, 10. Dezember 2013 11:59
> > To: users@cxf.apache.org; coheigea@apache.org
> > 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:coheigea@apache.org]
> > Sent: mardi 10 décembre 2013 11:28
> > To: COURTAULT Francois
> > Cc: Andrei Shakirin; users@cxf.apache.org
> > 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 <
> > Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > > Sent: lundi 9 décembre 2013 15:46
> > > To: coheigea@apache.org; COURTAULT Francois
> > > Cc: users@cxf.apache.org
> > > Subject: RE: Spec questions
> > >
> > > Hi Colm,
> > >
> > > That was my missing piece of the my puzzle :)
> > >
> > > Thanks,
> > > Andrei.
> > >
> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > Sent: Montag, 9. Dezember 2013 11:33
> > > To: COURTAULT Francois
> > > Cc: Andrei Shakirin; users@cxf.apache.org
> > > 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 <
> > > Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > > Sent: vendredi 6 décembre 2013 18:01
> > > To: users@cxf.apache.org
> > > Cc: coheigea@apache.org; COURTAULT Francois
> > > Subject: RE: Spec questions
> > >
> > > Hi,
> > >
> > > Colm knows the subject better, anyway short answer from me:
> > >
> > > > -----Original Message-----
> > > > From: COURTAULT Francois
> [mailto:Francois.COURTAULT@gemalto.com]
> > > > Sent: Donnerstag, 5. Dezember 2013 14:32
> > > > To: users@cxf.apache.org
> > > > Cc: coheigea@apache.org
> > > > 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
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
RE: Spec questions
Posted by Andrei Shakirin <as...@talend.com>.
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:Francois.COURTAULT@gemalto.com]
> Sent: Dienstag, 17. Dezember 2013 16:01
> To: users@cxf.apache.org; coheigea@apache.org
> 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: users@cxf.apache.org; Andrei Shakirin
> Cc: coheigea@apache.org
> Subject: RE: Spec questions
>
> Hello,
>
> Any answer to my previous questions ?
>
> Best Regards.
>
> -----Original Message-----
> From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> Sent: mercredi 11 décembre 2013 09:45
> To: Andrei Shakirin; users@cxf.apache.org
> Cc: coheigea@apache.org
> 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:ashakirin@talend.com]
> Sent: mardi 10 décembre 2013 15:45
> To: COURTAULT Francois; users@cxf.apache.org
> Cc: coheigea@apache.org
> 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:Francois.COURTAULT@gemalto.com]
> > Sent: Dienstag, 10. Dezember 2013 11:59
> > To: users@cxf.apache.org; coheigea@apache.org
> > 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:coheigea@apache.org]
> > Sent: mardi 10 décembre 2013 11:28
> > To: COURTAULT Francois
> > Cc: Andrei Shakirin; users@cxf.apache.org
> > 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 <
> > Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > > Sent: lundi 9 décembre 2013 15:46
> > > To: coheigea@apache.org; COURTAULT Francois
> > > Cc: users@cxf.apache.org
> > > Subject: RE: Spec questions
> > >
> > > Hi Colm,
> > >
> > > That was my missing piece of the my puzzle :)
> > >
> > > Thanks,
> > > Andrei.
> > >
> > > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > > Sent: Montag, 9. Dezember 2013 11:33
> > > To: COURTAULT Francois
> > > Cc: Andrei Shakirin; users@cxf.apache.org
> > > 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 <
> > > Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > > Sent: vendredi 6 décembre 2013 18:01
> > > To: users@cxf.apache.org
> > > Cc: coheigea@apache.org; COURTAULT Francois
> > > Subject: RE: Spec questions
> > >
> > > Hi,
> > >
> > > Colm knows the subject better, anyway short answer from me:
> > >
> > > > -----Original Message-----
> > > > From: COURTAULT Francois
> [mailto:Francois.COURTAULT@gemalto.com]
> > > > Sent: Donnerstag, 5. Dezember 2013 14:32
> > > > To: users@cxf.apache.org
> > > > Cc: coheigea@apache.org
> > > > 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
RE: Spec questions
Posted by COURTAULT Francois <Fr...@gemalto.com>.
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: users@cxf.apache.org; Andrei Shakirin
Cc: coheigea@apache.org
Subject: RE: Spec questions
Hello,
Any answer to my previous questions ?
Best Regards.
-----Original Message-----
From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
Sent: mercredi 11 décembre 2013 09:45
To: Andrei Shakirin; users@cxf.apache.org
Cc: coheigea@apache.org
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:ashakirin@talend.com]
Sent: mardi 10 décembre 2013 15:45
To: COURTAULT Francois; users@cxf.apache.org
Cc: coheigea@apache.org
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:Francois.COURTAULT@gemalto.com]
> Sent: Dienstag, 10. Dezember 2013 11:59
> To: users@cxf.apache.org; coheigea@apache.org
> 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:coheigea@apache.org]
> Sent: mardi 10 décembre 2013 11:28
> To: COURTAULT Francois
> Cc: Andrei Shakirin; users@cxf.apache.org
> 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 <
> Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > Sent: lundi 9 décembre 2013 15:46
> > To: coheigea@apache.org; COURTAULT Francois
> > Cc: users@cxf.apache.org
> > Subject: RE: Spec questions
> >
> > Hi Colm,
> >
> > That was my missing piece of the my puzzle :)
> >
> > Thanks,
> > Andrei.
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Montag, 9. Dezember 2013 11:33
> > To: COURTAULT Francois
> > Cc: Andrei Shakirin; users@cxf.apache.org
> > 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 <
> > Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > Sent: vendredi 6 décembre 2013 18:01
> > To: users@cxf.apache.org
> > Cc: coheigea@apache.org; COURTAULT Francois
> > Subject: RE: Spec questions
> >
> > Hi,
> >
> > Colm knows the subject better, anyway short answer from me:
> >
> > > -----Original Message-----
> > > From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> > > Sent: Donnerstag, 5. Dezember 2013 14:32
> > > To: users@cxf.apache.org
> > > Cc: coheigea@apache.org
> > > 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
RE: Spec questions
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Hello,
Any answer to my previous questions ?
Best Regards.
-----Original Message-----
From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
Sent: mercredi 11 décembre 2013 09:45
To: Andrei Shakirin; users@cxf.apache.org
Cc: coheigea@apache.org
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:ashakirin@talend.com]
Sent: mardi 10 décembre 2013 15:45
To: COURTAULT Francois; users@cxf.apache.org
Cc: coheigea@apache.org
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:Francois.COURTAULT@gemalto.com]
> Sent: Dienstag, 10. Dezember 2013 11:59
> To: users@cxf.apache.org; coheigea@apache.org
> 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:coheigea@apache.org]
> Sent: mardi 10 décembre 2013 11:28
> To: COURTAULT Francois
> Cc: Andrei Shakirin; users@cxf.apache.org
> 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 <
> Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > Sent: lundi 9 décembre 2013 15:46
> > To: coheigea@apache.org; COURTAULT Francois
> > Cc: users@cxf.apache.org
> > Subject: RE: Spec questions
> >
> > Hi Colm,
> >
> > That was my missing piece of the my puzzle :)
> >
> > Thanks,
> > Andrei.
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Montag, 9. Dezember 2013 11:33
> > To: COURTAULT Francois
> > Cc: Andrei Shakirin; users@cxf.apache.org
> > 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 <
> > Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > Sent: vendredi 6 décembre 2013 18:01
> > To: users@cxf.apache.org
> > Cc: coheigea@apache.org; COURTAULT Francois
> > Subject: RE: Spec questions
> >
> > Hi,
> >
> > Colm knows the subject better, anyway short answer from me:
> >
> > > -----Original Message-----
> > > From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> > > Sent: Donnerstag, 5. Dezember 2013 14:32
> > > To: users@cxf.apache.org
> > > Cc: coheigea@apache.org
> > > 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
RE: Spec questions
Posted by COURTAULT Francois <Fr...@gemalto.com>.
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:ashakirin@talend.com]
Sent: mardi 10 décembre 2013 15:45
To: COURTAULT Francois; users@cxf.apache.org
Cc: coheigea@apache.org
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:Francois.COURTAULT@gemalto.com]
> Sent: Dienstag, 10. Dezember 2013 11:59
> To: users@cxf.apache.org; coheigea@apache.org
> 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:coheigea@apache.org]
> Sent: mardi 10 décembre 2013 11:28
> To: COURTAULT Francois
> Cc: Andrei Shakirin; users@cxf.apache.org
> 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 <
> Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > Sent: lundi 9 décembre 2013 15:46
> > To: coheigea@apache.org; COURTAULT Francois
> > Cc: users@cxf.apache.org
> > Subject: RE: Spec questions
> >
> > Hi Colm,
> >
> > That was my missing piece of the my puzzle :)
> >
> > Thanks,
> > Andrei.
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Montag, 9. Dezember 2013 11:33
> > To: COURTAULT Francois
> > Cc: Andrei Shakirin; users@cxf.apache.org
> > 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 <
> > Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > Sent: vendredi 6 décembre 2013 18:01
> > To: users@cxf.apache.org
> > Cc: coheigea@apache.org; COURTAULT Francois
> > Subject: RE: Spec questions
> >
> > Hi,
> >
> > Colm knows the subject better, anyway short answer from me:
> >
> > > -----Original Message-----
> > > From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> > > Sent: Donnerstag, 5. Dezember 2013 14:32
> > > To: users@cxf.apache.org
> > > Cc: coheigea@apache.org
> > > 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
RE: Spec questions
Posted by Andrei Shakirin <as...@talend.com>.
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:Francois.COURTAULT@gemalto.com]
> Sent: Dienstag, 10. Dezember 2013 11:59
> To: users@cxf.apache.org; coheigea@apache.org
> 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:coheigea@apache.org]
> Sent: mardi 10 décembre 2013 11:28
> To: COURTAULT Francois
> Cc: Andrei Shakirin; users@cxf.apache.org
> 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 <
> Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> > Sent: lundi 9 décembre 2013 15:46
> > To: coheigea@apache.org; COURTAULT Francois
> > Cc: users@cxf.apache.org
> > Subject: RE: Spec questions
> >
> > Hi Colm,
> >
> > That was my missing piece of the my puzzle :)
> >
> > Thanks,
> > Andrei.
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Montag, 9. Dezember 2013 11:33
> > To: COURTAULT Francois
> > Cc: Andrei Shakirin; users@cxf.apache.org
> > 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 <
> > Francois.COURTAULT@gemalto.com> 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-sec
> > 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-uti
> > lity-1.0.xsd
> > "
> > wsse11:TokenType="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-pro
> > 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#Thu
> > 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:ashakirin@talend.com]
> > Sent: vendredi 6 décembre 2013 18:01
> > To: users@cxf.apache.org
> > Cc: coheigea@apache.org; COURTAULT Francois
> > Subject: RE: Spec questions
> >
> > Hi,
> >
> > Colm knows the subject better, anyway short answer from me:
> >
> > > -----Original Message-----
> > > From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> > > Sent: Donnerstag, 5. Dezember 2013 14:32
> > > To: users@cxf.apache.org
> > > Cc: coheigea@apache.org
> > > 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-uti
> > 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-pro
> > 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
RE: Spec questions
Posted by COURTAULT Francois <Fr...@gemalto.com>.
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:coheigea@apache.org]
Sent: mardi 10 décembre 2013 11:28
To: COURTAULT Francois
Cc: Andrei Shakirin; users@cxf.apache.org
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 < Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> Sent: lundi 9 décembre 2013 15:46
> To: coheigea@apache.org; COURTAULT Francois
> Cc: users@cxf.apache.org
> Subject: RE: Spec questions
>
> Hi Colm,
>
> That was my missing piece of the my puzzle :)
>
> Thanks,
> Andrei.
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Montag, 9. Dezember 2013 11:33
> To: COURTAULT Francois
> Cc: Andrei Shakirin; users@cxf.apache.org
> 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 <
> Francois.COURTAULT@gemalto.com> 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-sec
> 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-uti
> lity-1.0.xsd
> "
> wsse11:TokenType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-pro
> 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#Thu
> 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:ashakirin@talend.com]
> Sent: vendredi 6 décembre 2013 18:01
> To: users@cxf.apache.org
> Cc: coheigea@apache.org; COURTAULT Francois
> Subject: RE: Spec questions
>
> Hi,
>
> Colm knows the subject better, anyway short answer from me:
>
> > -----Original Message-----
> > From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> > Sent: Donnerstag, 5. Dezember 2013 14:32
> > To: users@cxf.apache.org
> > Cc: coheigea@apache.org
> > 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-uti
> 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-pro
> 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
Re: Spec questions
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <
Francois.COURTAULT@gemalto.com> 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:ashakirin@talend.com]
> Sent: lundi 9 décembre 2013 15:46
> To: coheigea@apache.org; COURTAULT Francois
> Cc: users@cxf.apache.org
> Subject: RE: Spec questions
>
> Hi Colm,
>
> That was my missing piece of the my puzzle :)
>
> Thanks,
> Andrei.
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Montag, 9. Dezember 2013 11:33
> To: COURTAULT Francois
> Cc: Andrei Shakirin; users@cxf.apache.org
> 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 <
> Francois.COURTAULT@gemalto.com> 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-secext-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-utility-1.0.xsd
> "
> wsse11:TokenType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
> "
>
> wsu:Id="str_22Ps0gftJ20pYdu9">
> <wsse:KeyIdentifier
> EncodingType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
> "
> ValueType="
> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1
> ">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:ashakirin@talend.com]
> Sent: vendredi 6 décembre 2013 18:01
> To: users@cxf.apache.org
> Cc: coheigea@apache.org; COURTAULT Francois
> Subject: RE: Spec questions
>
> Hi,
>
> Colm knows the subject better, anyway short answer from me:
>
> > -----Original Message-----
> > From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> > Sent: Donnerstag, 5. Dezember 2013 14:32
> > To: users@cxf.apache.org
> > Cc: coheigea@apache.org
> > 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-utility-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-security-1.0#Base64Binary
> "
> ValueType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-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
RE: Spec questions
Posted by COURTAULT Francois <Fr...@gemalto.com>.
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:ashakirin@talend.com]
Sent: lundi 9 décembre 2013 15:46
To: coheigea@apache.org; COURTAULT Francois
Cc: users@cxf.apache.org
Subject: RE: Spec questions
Hi Colm,
That was my missing piece of the my puzzle :)
Thanks,
Andrei.
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Montag, 9. Dezember 2013 11:33
To: COURTAULT Francois
Cc: Andrei Shakirin; users@cxf.apache.org
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 <Fr...@gemalto.com> 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-secext-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-utility-1.0.xsd"
wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="str_22Ps0gftJ20pYdu9">
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">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:ashakirin@talend.com]
Sent: vendredi 6 décembre 2013 18:01
To: users@cxf.apache.org
Cc: coheigea@apache.org; COURTAULT Francois
Subject: RE: Spec questions
Hi,
Colm knows the subject better, anyway short answer from me:
> -----Original Message-----
> From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> Sent: Donnerstag, 5. Dezember 2013 14:32
> To: users@cxf.apache.org
> Cc: coheigea@apache.org
> 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-utility-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-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-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
RE: Spec questions
Posted by Andrei Shakirin <as...@talend.com>.
Hi Colm,
That was my missing piece of the my puzzle :)
Thanks,
Andrei.
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Montag, 9. Dezember 2013 11:33
To: COURTAULT Francois
Cc: Andrei Shakirin; users@cxf.apache.org
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 <Fr...@gemalto.com> 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-secext-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-utility-1.0.xsd"
wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="str_22Ps0gftJ20pYdu9">
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">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:ashakirin@talend.com]
Sent: vendredi 6 décembre 2013 18:01
To: users@cxf.apache.org
Cc: coheigea@apache.org; COURTAULT Francois
Subject: RE: Spec questions
Hi,
Colm knows the subject better, anyway short answer from me:
> -----Original Message-----
> From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> Sent: Donnerstag, 5. Dezember 2013 14:32
> To: users@cxf.apache.org
> Cc: coheigea@apache.org
> 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-utility-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-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-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
Re: Spec questions
Posted by Colm O hEigeartaigh <co...@apache.org>.
> 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 <
Francois.COURTAULT@gemalto.com> 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-secext-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-utility-1.0.xsd
> "
> wsse11:TokenType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
> "
>
> wsu:Id="str_22Ps0gftJ20pYdu9">
> <wsse:KeyIdentifier
> EncodingType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
> "
> ValueType="
> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1
> ">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:ashakirin@talend.com]
> Sent: vendredi 6 décembre 2013 18:01
> To: users@cxf.apache.org
> Cc: coheigea@apache.org; COURTAULT Francois
> Subject: RE: Spec questions
>
> Hi,
>
> Colm knows the subject better, anyway short answer from me:
>
> > -----Original Message-----
> > From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> > Sent: Donnerstag, 5. Dezember 2013 14:32
> > To: users@cxf.apache.org
> > Cc: coheigea@apache.org
> > 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-utility-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-security-1.0#Base64Binary
> "
> ValueType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-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
RE: Spec questions
Posted by COURTAULT Francois <Fr...@gemalto.com>.
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-secext-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-utility-1.0.xsd"
wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="str_22Ps0gftJ20pYdu9">
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">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:ashakirin@talend.com]
Sent: vendredi 6 décembre 2013 18:01
To: users@cxf.apache.org
Cc: coheigea@apache.org; COURTAULT Francois
Subject: RE: Spec questions
Hi,
Colm knows the subject better, anyway short answer from me:
> -----Original Message-----
> From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> Sent: Donnerstag, 5. Dezember 2013 14:32
> To: users@cxf.apache.org
> Cc: coheigea@apache.org
> 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-utility-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-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-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
RE: Spec questions
Posted by Andrei Shakirin <as...@talend.com>.
Hi,
Colm knows the subject better, anyway short answer from me:
> -----Original Message-----
> From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
> Sent: Donnerstag, 5. Dezember 2013 14:32
> To: users@cxf.apache.org
> Cc: coheigea@apache.org
> 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-utility-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-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-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