Brian,
you say that UsernameToken is a key bearing element - AFAIK that's not the case.
UsernameToken is not defined as a key bearing element but is only used to identify
and to authenticate a user (in case a password is provided). Thus you can encrypt
a UsernameToken with some key and the keyholder element has to preceed the
encrypted UsernameToken.
Key holders in the sense of WSS are certificates or a keyname but not a UsernameToken. UT was not designed for such a use.
Regards, Werner
Brian Nielsen schrieb:
Werner,
Thank you for your quick reply, which is in agreement with another reply I
got from Anne Thomas Manes.
Once more I've discovered how hard I find it is to write precise postings
that stick to, and complete an argumentation :-). My example was sort of
incomplete and I didn't followup on my argumentation, so I'll try again. You are 100% right about the order of elements according to the first part
of quote i had from the specification about prepeding. I didn't go into the
consequence of two other parts of the quote:
<quote> Note that this specification does not impose any specific order of processing the sub-elements. The receiving application can use whatever order is required. </quote>
Uhmm, so the 'client' should do it in a certain order to help the 'server',
but there isn't implied any order of processing. That sound more like a
legal document lingo than a strict spec, but maybe that's just to relax
implementers that want to do it their own way.
Then comes the part that I think the current implementation is conflict with:
<quote> When a sub-element refers to a key carried in another sub-element (for example, a signature sub-element that refers to a binary security token sub-element that contains the X.509 certificate used for the signature), the key-bearing element SHOULD be ordered to precede the key-using Element: </quote>
So if I understand this right i see "2) 'wsse:UsernameToken'" as the key-bearing element and "1) 'xenc:EncryptedKey'" as the key-using Element, and then the UsernameToken SHOULD precede the EncryptedKey. Maybe this is an misinterpretation since the still does precede the encryption (embedded under SecurityTokenReference).
This 'problem' has be puzzeling me a long time since it seems WSE2 does it the way i read the specification. In one of my prior postings [1] with an WSE2.0 example request, where a Timestamp and a UsernameToken is added and then signed along with all the addressing headers. I can not reproduce this 'layout' since my signature part would come out on the top with wss4j, since i would have to do it like:
<parameter name="action" value="Timestamp UsernameToken Signature"/>
And then the signature part would be to topmost sub-element, which is correct as goes for the prepending SHOULD 'rule' but seems to be in conflict with the key-bearing precede key-using 'rule'.
Brgds Brian
[1]http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]& msgNo=2090
-----Original Message-----
From: Werner Dittmann [mailto:[EMAIL PROTECTED] Sent: 7. maj 2005 09:43
To: Brian Nielsen
Cc: [email protected]
Subject: Re: The order of actions, processing order and sequence af
serialized ws-security header elements
Brian,
the Axis handler that drive the WSS4J library read the action from left to right. Thus if you have the action value "Timestamp UsernameToken Encrypt" then WSS4J first creates the wsse:Security element and inserts the timestamp element. After that WSS4J sets up the username token element and prepends it (inserts it before) the timestamp, then WSS4J handles encryption and prepends all encryption related elements. Thus, as described in WSS specs the wsse:Security element is built from bottom to top.
After all actions are done the wsse:Security element contains, from top to bottom: - Encryption elements - UsernameToken elements - Timestamp elements
The receiver part of the handler automatically reverts the actions, thus you can use the same order of actions in both handlers.
As for you problem with the encryption exception: in your example you reveresed the order of action. Thus you ordered to encrypt an element that does not yet exists.
Regards, Werner
Brian Nielsen schrieb:
I've got a question regarding how to configure my security handlers (actions), since they don't behave like I would want them to. Here's the facts that I've found before going into the specifics of my 'problem'::
A) The order of actions
In [1] under "Combining security actions", there is an example the WS Interoperability specifications:
1) Insert a UsernameToken, use PasswordText to set the password. In addition add a timestamp and a nonce into the UsernameToken
2) Encrypt the UsernameToken to protect the information.
That should be configured like this
<parameter name="action" value="UsernameToken Encrypt"/>
Should first 'things' first, and very intuitive.
Okay I'll add a Timestamp prior to that, so that'll be:
<parameter name="action" value="Timestamp UsernameToken Encrypt"/>
Enenthough the timestamp is'nt important for my problem is does make it some what clearer.
B) processing order In the WS-Security spec [2] section 5. "Security Header", it says:
<quote>
As elements are added to a <wsse:Security> header block, they SHOULD be prepended to the existing elements. As such, the <wsse:Security> header block represents the signing and encryption steps the message producer took to create the message. This prepending rule ensures that the receiving application can process sub-elements in the order they appear in the <wsse:Security> header block, because there will be no forward dependency among the sub- elements. Note that this specification does not impose any specific order of processing the sub- elements. The receiving application can use whatever order is required.
When a sub-element refers to a key carried in another sub-element (for example, a signature sub-element that refers to a binary security token sub-element that contains the X.509 certificate used for the signature), the key-bearing element SHOULD be ordered to precede the key-using
Element:
</quote>
C) sequence af serialized ws-security
The following examples are all taken from client-side requests!. My first example is based on :
<parameter name="action" value="Timestamp UsernameToken Encrypt"/>
With no specific 'encryptionParts', so it'll encrypt the soap body, I've inserted it as a big footnote to keep this text readable [3]. The child elements of the 'wsse:Security' element are, taken from the top:
1) 'xenc:EncryptedKey'
2) 'wsse:UsernameToken'
3) 'wsu:Timestamp'
That looks like just the opposite of what I expected, so I'll try and turn it around:
<parameter name="action" value="Encrypt UsernameToken Timestamp"/>
And then I get [4] where the order is just the way I wanted them. Now'll insert am 'encryptionParts' so that it's the UsernameToken that get's encrypted. Ups, that did not go well:
Exception in thread "main" AxisFault
faultCode:
{http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
faultSubcode:
faultString: WSDoAllSender: Encryption: error during message
processingorg.apache.ws.security.WSSecurityException: General security error
(WSEncryptBody/WSSignEnvelope: Element to encrypt/sign not found:
{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec
ext-1
.0.xsd}UsernameToken)
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:WSDoAllSender: Encryption:
error during message processingorg.apache.ws.security.WSSecurityException:
General security error (WSEncryptBody/WSSignEnvelope: Element to encrypt/sign not found:
{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec
ext-1
.0.xsd}UsernameToken)
at
org.apache.ws.axis.security.WSDoAllSender.performENCRAction(WSDoAllSend
er.ja
va:455)
at
org.apache.ws.axis.security.WSDoAllSender.invoke(WSDoAllSender.java:316)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java
eventhough not that intuitive:32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) ...
Uhmmm, that did not work, but had i change the sequence of the 'Encrypt' and 'UsernameToken' in the 'action' parameter I would get through but with the 'wrong' ordering of the serialized elements. One last try, I'll do it in two steps, that surely must be a way around
<handler type="java:org.apache.ws.axis.security.WSDoAllSender"> <parameter name="action" value="UsernameToken Timestamp"/> ... </handler> <handler type="java:org.apache.ws.axis.security.WSDoAllSender"> <parameter name="action" value="Encrypt"/> ... </handler>
But the result [5] is still with 'xenc:EncryptedKey' at the top (both with and without 'NoSerialization'), and to some degree it makes more sense since this is prepended the existing elements.
So after going through all this:
1) what should I do different?
2) is this an error?
3) does it not matter at all?
I certainly think it does matter and that it can make it harder to configure for interoperability, but would like a second opinion.
Regards Brian
[1]http://ws.apache.org/ws-fx/wss4j/package.html
[2]http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message -secu rity-1.0.pdf
[3]
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wss
ecuri
ty-secext-1.0.xsd">
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<ds:KeyInfo
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-s
oap-m
essage-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509
-toke
n-profile-1.0#X509v3">MIICojCCAgugAwIBAgIBCDANBgkqhkiG9w0BAQQFADCBjzELM
AkGA1
UEBhMCREsxEzARBgNVBAgT
CkNPUEVOSEFHRU4xDTALBgNVBAcTBENJVFkxFDASBgNVBAoTC0Zha2UgU1NMIENBMRQwEgY
DVQQL EwtJVCBESVZJU0lPTjEUMBIGA1UEAxMLRkFLRSBTU0wgQ0ExGjAYBgkqhkiG9w0BCQEWC2J
uaUBp dHN0LmRrMB4XDTA0MDkyOTA4MDkwMloXDTA3MDkyOTA4MDkwMlowgY4xCzAJBgNVBAYTAkR
LMRIw EAYDVQQIFAlCSVJLRVLDmEQxJDAiBgNVBAoTG0RFVCBDRU5UUkFMRSBQRVJTT05SRUdJU1R
FUjEV MBMGA1UECxMMQ1BSIEtPTlRPUkVUMRMwEQYDVQQDEwp3d3cuY3ByLmRrMRkwFwYJKoZIhvc
NAQkB FgpjcHJAY3ByLmRrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC31NZppksvJ1ilKuB
D6flx
+HOjDGr8XsOsHDnyaJ+ovGJMCbSlvP2Shdo374im2i7KsF6fZDnNdPTkolU3RxOQ+P8eSa/
+HOjDGr8XsOsHDnyaJ+ovGJMCbSlvP2Shdo374im2i7KsF6fZDnNdPTkolU3RxOQ+6qvNW
utsdxVuPaB6rZwzy4gpNFP+7KvuIQZVVxOA9NMqXv1VDzBb5hV/DAcAlnyos7IjtsmsoNTX
utsdxVuPaB6rZwzy4gpNFP+1QwID
AQABow0wCzAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBAUAA4GBAKR/kL3zvnWQr0V/zr0qNWQ
vUfhZ BFMy03RuAJw3G51L/mhUiXH8mMPjB9uozQ9FiAzZ9mQ/Ebt7tHUNE+fgPMWg/rO2wfmwvnp
0Mp/F O/5DVS4hwun+3me6wNi5GBDmlKiOWFXWnHxKsKVEx5weAsebgeh1JijGtSGK0NZnrU8Z</w
sse:K
eyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>Fo7OjT1pNea1e2u3SqJruV64X6h3Zl+R62/cL9GEg7pv8ZPzQZX/V JnPqv JSGELyl5WED0/yPnOS xHNHEvrZ6OanhQNxjwhOem93O1MKmz0NlreXdthQP2HAieGb9OW14suOJhaxoViJUXEICNN /A5wM PdhW9ZfuW2KfsLG7rVg=</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#EncDataId-26622782"/> </xenc:ReferenceList> </xenc:EncryptedKey> <wsse:UsernameToken> <wsse:Username>benny</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username- token -profile-1.0#PasswordText">bennysPassword</wsse:Password> </wsse:UsernameToken> <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse curit y-utility-1.0.xsd"> <wsu:Created>2005-05-06T20:34:06Z</wsu:Created> <wsu:Expires>2005-05-06T20:39:06Z</wsu:Expires> </wsu:Timestamp> </wsse:Security> </soapenv:Header> <soapenv:Body> <xenc:EncryptedData Id="EncDataId-26622782" Type="http://www.w3.org/2001/04/xmlenc#Content";> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <xenc:CipherData>
<xenc:CipherValue>OaOy3N1efI+f3v/F48zxJi/lPT1IQAe9Oa4zLSY4hoRo//aEsIjT/
A5H1A
ziwPp18aHs7bE0WWJS
e1JsigoikCjYmFHzE/8ycFx6K6mTn+PTyDobjb7886hQWv0d4ykoz/P8Z/Lomm06tbiiS8Z
QYeZZ 26fsUpOatdxWtgPlKsv5BCGdhTURwDoqqm36ukM5o4nhD6Jd59swLlpy3IBsv1lqMfEP/EZ
HY4Vg
ejJxK2ZJtghd8++I0swRvxdUQ51Fvk1JbaQDL8R4jDSBDTnU8VC5Hnc/+jSx5MRYcx1be2t
ejJxK2ZJtghd8++VFH/3
XhDeUSfku9HQYhJcUKHZs+W4CTsCSHdWU5uK0yg074vfc18E4mAAbRezU5gr2/SdzrPu8iS
XhDeUSfku9HQYhJcUKHZs+pyo3K
5DtlfHI0OtCtFs+cLtYP9UsW+UpyLDMeA2FmE0KGTvBHy51gyACfjJiq6dGlZMmUlJeV</x
5DtlfHI0OtCtFs+cLtYP9UsW+enc:C
ipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</soapenv:Body>
</soapenv:Envelope>
[4]
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wss
ecuri
ty-secext-1.0.xsd">
<wsu:Timestamp
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
curit
y-utility-1.0.xsd">
<wsu:Created>2005-05-06T20:35:16Z</wsu:Created>
<wsu:Expires>2005-05-06T20:40:16Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken>
<wsse:Username>benny</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
token -profile-1.0#PasswordText">bennysPassword</wsse:Password>
</wsse:UsernameToken>
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<ds:KeyInfo
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-s
oap-m
essage-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509
-toke
n-profile-1.0#X509v3">MIICojCCAgugAwIBAgIBCDANBgkqhkiG9w0BAQQFADCBjzELM
AkGA1
UEBhMCREsxEzARBgNVBAgT
CkNPUEVOSEFHRU4xDTALBgNVBAcTBENJVFkxFDASBgNVBAoTC0Zha2UgU1NMIENBMRQwEgY
DVQQL EwtJVCBESVZJU0lPTjEUMBIGA1UEAxMLRkFLRSBTU0wgQ0ExGjAYBgkqhkiG9w0BCQEWC2J
uaUBp dHN0LmRrMB4XDTA0MDkyOTA4MDkwMloXDTA3MDkyOTA4MDkwMlowgY4xCzAJBgNVBAYTAkR
LMRIw EAYDVQQIFAlCSVJLRVLDmEQxJDAiBgNVBAoTG0RFVCBDRU5UUkFMRSBQRVJTT05SRUdJU1R
FUjEV MBMGA1UECxMMQ1BSIEtPTlRPUkVUMRMwEQYDVQQDEwp3d3cuY3ByLmRrMRkwFwYJKoZIhvc
NAQkB FgpjcHJAY3ByLmRrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC31NZppksvJ1ilKuB
D6flx
+HOjDGr8XsOsHDnyaJ+ovGJMCbSlvP2Shdo374im2i7KsF6fZDnNdPTkolU3RxOQ+P8eSa/
+HOjDGr8XsOsHDnyaJ+ovGJMCbSlvP2Shdo374im2i7KsF6fZDnNdPTkolU3RxOQ+6qvNW
utsdxVuPaB6rZwzy4gpNFP+7KvuIQZVVxOA9NMqXv1VDzBb5hV/DAcAlnyos7IjtsmsoNTX
utsdxVuPaB6rZwzy4gpNFP+1QwID
AQABow0wCzAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBAUAA4GBAKR/kL3zvnWQr0V/zr0qNWQ
vUfhZ BFMy03RuAJw3G51L/mhUiXH8mMPjB9uozQ9FiAzZ9mQ/Ebt7tHUNE+fgPMWg/rO2wfmwvnp
0Mp/F O/5DVS4hwun+3me6wNi5GBDmlKiOWFXWnHxKsKVEx5weAsebgeh1JijGtSGK0NZnrU8Z</w
sse:K
eyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>VFKi6bc8ErjMRQaN+Ir7rZ9hfLlPOZysYLF71z+afA+tWC9tFIQO1 rsqTG JdqIxWVjRwUMO2Gznj w9BTHUZkgVQKgju92XCM6dYtQK+19H/7O39UQKTCklEZnDAPMjjw6dTrKRqLWD/E/gX0YXp w9BTHUZkgVQKgju92XCM6dYtQK+SbFmb /lfJNxoCkNW1FrY2maM=</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#EncDataId-3556929"/> </xenc:ReferenceList> </xenc:EncryptedKey> </wsse:Security> </soapenv:Header> <soapenv:Body> <xenc:EncryptedData Id="EncDataId-3556929" Type="http://www.w3.org/2001/04/xmlenc#Content";> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <xenc:CipherData>
<xenc:CipherValue>ywYGy+KP4teYT0z0CqFvnteu6czZNSyFbUcR1IQlThjqR5mKJVUeF 6pHD6 9iy1yh5wMFmJQMzIGr eFtrp73XTLdXNf+gCtsBN0Wpy2m36Ee+06BH1n+v+GY9qGM57Ol42zIYC13MErrGvNFCo0f eFtrp73XTLdXNf+gCtsBN0Wpy2m36Ee+06BH1n+v+ssIr7 BZ5g9Iv/qZZYxZj8Atf5NMKUgyMsM216EmtSATu3a79B7InK2v3MsQ29CDpZa67TqvXLwra dkhA5 mLNSv3TVHNoPXEtxWVyVMsKydYX39vaUeprPtuJ+W5j0KdyuxvYn92MN7me1qdoxshfyvYK mLNSv3TVHNoPXEtxWVyVMsKydYX39vaUeprPtuJ+qaadp 4ulQiBdu0+3qr0q+Sj17058f6Yo3Wjar49Pr1KNGDTmpaR/5aeXKfss6qFP1+0fdmDqjj2K 4ulQiBdu0+3qr0q+PC2ji n32hzUjsrtzD8DLW3/B0Kkoh8xR3z+J8/swWBe0tnzk/qYcKnmEtKbJGWevr1umERI+K</x enc:C ipherValue> </xenc:CipherData> </xenc:EncryptedData> </soapenv:Body> </soapenv:Envelope>
[5]
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wss
ecuri
ty-secext-1.0.xsd">
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<ds:KeyInfo
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-s
oap-m
essage-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509
-toke
n-profile-1.0#X509v3">MIICojCCAgugAwIBAgIBCDANBgkqhkiG9w0BAQQFADCBjzELM
AkGA1
UEBhMCREsxEzARBgNVBAgT
CkNPUEVOSEFHRU4xDTALBgNVBAcTBENJVFkxFDASBgNVBAoTC0Zha2UgU1NMIENBMRQwEgY
DVQQL EwtJVCBESVZJU0lPTjEUMBIGA1UEAxMLRkFLRSBTU0wgQ0ExGjAYBgkqhkiG9w0BCQEWC2J
uaUBp dHN0LmRrMB4XDTA0MDkyOTA4MDkwMloXDTA3MDkyOTA4MDkwMlowgY4xCzAJBgNVBAYTAkR
LMRIw EAYDVQQIFAlCSVJLRVLDmEQxJDAiBgNVBAoTG0RFVCBDRU5UUkFMRSBQRVJTT05SRUdJU1R
FUjEV MBMGA1UECxMMQ1BSIEtPTlRPUkVUMRMwEQYDVQQDEwp3d3cuY3ByLmRrMRkwFwYJKoZIhvc
NAQkB FgpjcHJAY3ByLmRrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC31NZppksvJ1ilKuB
D6flx
+HOjDGr8XsOsHDnyaJ+ovGJMCbSlvP2Shdo374im2i7KsF6fZDnNdPTkolU3RxOQ+P8eSa/
+HOjDGr8XsOsHDnyaJ+ovGJMCbSlvP2Shdo374im2i7KsF6fZDnNdPTkolU3RxOQ+6
+HOjDGr8XsOsHDnyaJ+ovGJMCbSlvP2Shdo374im2i7KsF6fZDnNdPTkolU3RxOQ+qvNW
utsdxVuPaB6rZwzy4gpNFP+7KvuIQZVVxOA9NMqXv1VDzBb5hV/DAcAlnyos7IjtsmsoNTX
utsdxVuPaB6rZwzy4gpNFP+1
utsdxVuPaB6rZwzy4gpNFP+QwID
AQABow0wCzAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBAUAA4GBAKR/kL3zvnWQr0V/zr0qNWQ
vUfhZ BFMy03RuAJw3G51L/mhUiXH8mMPjB9uozQ9FiAzZ9mQ/Ebt7tHUNE+fgPMWg/rO2wfmwvnp
0Mp/F O/5DVS4hwun+3me6wNi5GBDmlKiOWFXWnHxKsKVEx5weAsebgeh1JijGtSGK0NZnrU8Z</w
sse:K
eyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>NGbRneWj5Xmv/U2YevVoBqV/iIiyCjqPpiqdo4ctK28102Dlfb0tn
BuDiY
WgsHCY+CBTpRqmhb5O
zhKyYa7QnXtCSSsWETm537Sb2Rl0SgYgV0US331N/qbiII86B5uElgk8+PbmKhCqY1piCXg
6sPY0 GWwm3GnrVZGKTnCOxO4=</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#EncDataId-28524838"/>
</xenc:ReferenceList>
</xenc:EncryptedKey>
<wsu:Timestamp
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
curit
y-utility-1.0.xsd">
<wsu:Created>2005-05-06T20:52:26Z</wsu:Created>
<wsu:Expires>2005-05-06T20:57:26Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken>
<xenc:EncryptedData Id="EncDataId-28524838"
Type="http://www.w3.org/2001/04/xmlenc#Content";>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>Xu2hWw6vcVgP4kw8OR/a3Tz2BjM2M9rr3+CUrNrXmqkRZ+5P/Ejb7
QbeH5
KxOI6vmMbCIVAuVXGd
THpHIYH4lenXH3Kd8FCO2uVmUsRbPlP9aiVaWUrbCK4SM5+MZVC0WAAVfgzCaepquqA+hso
THpHIYH4lenXH3Kd8FCO2uVmUsRbPlP9aiVaWUrbCK4SM5+MZVC0WAAVfgzCaepquqA+j
THpHIYH4lenXH3Kd8FCO2uVmUsRbPlP9aiVaWUrbCK4SM5+MZVC0WAAVfgzCaepquqA+/Mo
THpHIYH4lenXH3Kd8FCO2uVmUsRbPlP9aiVaWUrbCK4SM5+MZVC0WAAVfgzCaepquqA+V
Y/eeLHAma0WHRDH7ikycOHyxsj8rEqe7mlSPORCvuyLm2p6s8TAJs0fZuVh0KOZln6RN6rb
dgS5Z CPDvBrE95E3ey/yBd9REBwKjvqcamPvXyK63hQv43E8/tzXXwZmv5B3hmdL8xXmIMtOdG8r
hHOCx
T6VH1s3wjJ7+AB/4xn7xw/WGm/cFRT4SPaY/zAifpcGjq/Zw+TKrnk1NVvYbD7BpnG2dUkp
T6VH1s3wjJ7+0
T6VH1s3wjJ7+fdUS
KBWJy/74pJIC7f4Y0dx/M7QwV0aS2EzPZSsb2Mwu0yvuAJpg1CE4SRUn0QmngAdyTK3K9WF
MGFu/
wbv9QdqzTkOAsk0TTCKt8ZAjpGS+K/f1mCvv6KwLofM3dkMMpqIx9J4A6AZBf0Hd2g7J0Sa
wbv9QdqzTkOAsk0TTCKt8ZAjpGS+z
wbv9QdqzTkOAsk0TTCKt8ZAjpGS+ERkN
8kXxiQP9RubGYW9Xpa+E6BbGS/D7992oB8YVoid47x+itiLMKCaCTE2WHto96KGI7UwXmK6
8kXxiQP9RubGYW9Xpa+G
8kXxiQP9RubGYW9Xpa+xou6
gjnORTMvhtH24tn4iMAHIa8mlh8DwIOjSd5tZZuB6xBF6EAh/fd+HQ==</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<CivilRegistrationNumber
xmlns="http://rep.oio.dk/cpr.dk/xml/schemas/core/2002/06/28/";>121256123
4</Ci
vilRegistrationNumber>
</soapenv:Body>
</soapenv:Envelope>
