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-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:[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-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

Reply via email to