cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Spec questions
Date Mon, 09 Dec 2013 10:32:39 GMT
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message