Hi,
In my understanding, if you specify Require*assertions, exactly this is allowed
to reference Token:
<sp:RequireKeyIdentifierReference /> - key identifier (for X.509 Subject Key
Identifier)
<sp:RequireEmbeddedTokenReference /> - Binary Security Token
<sp:RequireIssuerSerialReference /> - issuer serial
<sp:RequireThumbprintReference> - thumbprint reference (certificate hash),
looks like:
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier
EncodingType="http://...-wss-soap-message-security-1.0#Base64Binary";
ValueType="http://.../oasis-wss-soap-message-security-1.1#ThumbprintSHA1";
>uYn3PK2wXheN2lLZr4n2mJjoWE0=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
Regards,
Andrei.
> -----Original Message-----
> From: COURTAULT Francois [mailto:[email protected]]
> Sent: Dienstag, 10. Dezember 2013 11:59
> To: [email protected]; [email protected]
> Cc: Andrei Shakirin
> Subject: RE: Spec questions
>
> Hello Colm,
>
> The only Require* I have in my policy file are:
> - <sp:RequireThumbprintReference/> for InitiatorToken and
> RecipientToken
> - <sp:RequireSignatureConfirmation/>
>
> Does one of the above policy assertion describes the way we have to
> reference the X509 token in the <wsse:SecurityTokenReference> ?
> If yes, I suppose that it is the <sp:RequireThumbprintReference/> but I don't
> see the link with 3 possible options we may have for token reference:
> - Reference to a Subject Key Identifier
> - Reference to a Binary Security Token
> - Reference to an Issuer and Serial Number
>
> According to me, the links between policy assertions and token reference
> looks like below:
> - Reference to a Subject Key Identifier is required by the
> <sp:RequireKeyIdentifierReference /> presence
> - Reference to a Binary Security Token is required by the
> <sp:RequireEmbeddedTokenReference /> presence
> - Reference to an Issuer and Serial Number is requires by the
> <sp:RequireIssuerSerialReference /> presence
>
> This is why I am a little bit lost :-( and though requires your help.
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:[email protected]]
> Sent: mardi 10 décembre 2013 11:28
> To: COURTAULT Francois
> Cc: Andrei Shakirin; [email protected]
> Subject: Re: Spec questions
>
> No, if you have a Require* Assertion, then only that is allowed to reference
> that token.
>
> Colm.
>
>
> On Mon, Dec 9, 2013 at 5:18 PM, COURTAULT Francois <
> [email protected]> wrote:
>
> > Hello guys,
> >
> > Thanks a lot for your explanations :-) The security assertion I only
> > have is RequireThumbprintReference.
> >
> > So in such case, does that mean that the 3 ways to reference an X.509
> > token in <wsse:SecurityTokenReference>:
> > * Reference to a Subject Key Identifier
> > * Reference to a Binary Security Token
> > * Reference to an Issuer and Serial Number
> >
> > are allowed ?
> >
> > Best regards.
> >
> > -----Original Message-----
> > From: Andrei Shakirin [mailto:[email protected]]
> > Sent: lundi 9 décembre 2013 15:46
> > To: [email protected]; COURTAULT Francois
> > Cc: [email protected]
> > Subject: RE: Spec questions
> >
> > Hi Colm,
> >
> > That was my missing piece of the my puzzle :)
> >
> > Thanks,
> > Andrei.
> >
> > From: Colm O hEigeartaigh [mailto:[email protected]]
> > Sent: Montag, 9. Dezember 2013 11:33
> > To: COURTAULT Francois
> > Cc: Andrei Shakirin; [email protected]
> > Subject: Re: Spec questions
> >
> >
> > > I also interpret <sp:ProtectTokens/> in this way. If it is active,
> > > the
> > signature must protect the used token as well:
> >
> > +1.
> >
> > > They can be controlled through following policy assertions: ...
> > Note that the MustSupport* policy assertions only state the the
> > message initiator/recipient must be able to process various ways of
> > identifying keys. It doesn't mandate them. To do this, take a look at
> > the various policies associated with a particular token. For example,
> > the X509Token policy has the following optional policies:
> >
> > <sp:RequireKeyIdentifierReference ... /> ?
> > <sp:RequireIssuerSerialReference ... /> ?
> > <sp:RequireEmbeddedTokenReference ... /> ?
> > <sp:RequireThumbprintReference ... /> ?
> > Colm.
> >
> >
> > On Fri, Dec 6, 2013 at 6:17 PM, COURTAULT Francois <
> > [email protected]> wrote:
> > Hello Andrei,
> >
> > Thanks a lot for your interpretation :-) Colm could you confirm please
> > ?
> >
> > For my second question regarding SecurityTokenReference, I have only
> > the following policy assertions:
> > <sp:MustSupportRefKeyIdentifier/>
> > <sp:MustSupportRefIssuerSerial/>
> > <sp:MustSupportRefThumbprint/>
> > <sp:MustSupportRefEncryptedKey/>
> > <sp:RequireSignatureConfirmation/>
> >
> > My interpretation about MustSupportRefThumbprint, for example, is that
> > the initiator and the recipient MUST be able to process references
> > using Token thumbprints. This means that any URI (a reference), in the
> > Signature section, which contains token thumbprint like
> > URI="#X509-21B185F9A383FC218D138383549326938", has to be processed:
> am
> > I correct ?
> >
> > If we have <sp:MustSupportRefKeyIdentifier/>, does that mean that we
> > have to have for the SecurityToken reference something like:
> > <wsse:SecurityTokenReference
> > xmlns:wsse="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-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:[email protected]]
> > Sent: vendredi 6 décembre 2013 18:01
> > To: [email protected]
> > Cc: [email protected]; COURTAULT Francois
> > Subject: RE: Spec questions
> >
> > Hi,
> >
> > Colm knows the subject better, anyway short answer from me:
> >
> > > -----Original Message-----
> > > From: COURTAULT Francois [mailto:[email protected]]
> > > Sent: Donnerstag, 5. Dezember 2013 14:32
> > > To: [email protected]
> > > Cc: [email protected]
> > > Subject: Spec questions
> > >
> > > Hello everyone,
> > >
> > > I try to understand what policy requires that a Certificate
> > > reference has to be included in the SignedInfo section.
> > > Is it due to <sp:ProtectTokens/> policy assertion ? If I read the
> > > spec at §6.5, it was stated that:
> > > "This boolean property specifies whether signatures must cover the
> > > token used to generate that signature. If the value is 'true', then
> > > each token used to generate a signature MUST be covered by that
> > signature."
> > >
> > > My interpretation of this sentence is that the token used for the
> > > signature has to be included in the signature so that the SignedInfo
> > > section has to contain the token reference: is my interpretation
> > > correct
> > ?
> > > It also means that if we use Asymmetric binding, it is mandatory to
> > > have in the SignedInfo section something like:
> > > <ds:Reference URI="X509-<thumbprint>>: right ?
> >
> > I also interpret <sp:ProtectTokens/> in this way. If it is active, the
> > signature must protect the used token as well:
> >
> > <wsse:BinarySecurityToken>
> > xmlns:wsu="
> > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-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
