{{ object.description|markdown|relativise_constrain_img_src:object }}
{{ object.goals|markdown|relativise_constrain_img_src:object }}
{{ object.objectives|markdown|relativise_constrain_img_src:object }}
{{ object.evaluation|markdown|relativise_constrain_img_src:object }}
{{ object.materials|markdown|relativise_constrain_img_src:object }}
{{ object.background|markdown|relativise_constrain_img_src:object }}
{{ object.fulldesc|markdown|relativise_constrain_img_src:object }}
Space Awareness curricula topics (EU and South Africa)
{% for category in object.spaceawe_categories %} {{ category.title }}, {% endfor %} {{ object.theme }}
{{ object.curriculum|markdown|relativise_constrain_img_src:object }}{{ object.additional_information|markdown|relativise_constrain_img_src:object }}
{% endif %}
{{ object.conclusion|markdown|relativise_constrain_img_src:object }}


Organizations
{/*We can give your company superpowers to do things that they never thought possible. Let us delight your customers and empower your needs...through pure data analytics.
Yes that's right, you thought it was the stuff of dreams, but even bananas can be bioengineered.
That is what they all say about us
Nan Chief Fun Officer Acme Toys
Instead of focusing on content creation and hard work, we have learned how to master the art of doing nothing by providing massive amounts of whitespace and generic content that can seem massive, monolithic and worth your attention.
Read MoreYes I know you probably disregarded the earlier boasts as non-sequitur filler content, but its really true. It took years of gene splicing and combinatory DNA research, but our bananas can really dance.
I'm Still Quite InterestedExtra space for a call to action inside the footer that could help re-engage users.
Extra space for a call to action inside the footer that could help re-engage users.


2018
An average of 67 new residents move to Wake County each day, making it one of the fastest growing counties in North Carolina. An additional 170,000 people have flooded the county in the past eight years, straining affordability and intensifying demand for all types of housing.
There is already a deficit of 50,000 units of affordable housing across Wake County. The crisis is projected to only worsen through 2030 — to provide for the anticipated influx, an additional 7,500 new housing units must be built each year.
—Wake County Commissioner Jessica Holmes, Wake County Commissioner Sig Hutchinson, The News & Observer
For those who manage to secure housing, affordability becomes the next hurdle.
Affordability is a nationwide problem. In no state can a two-bedroom apartment at the Fair Market Rent be afforded by the federal minimum wage.
But the affordability crisis is especially critical in Wake County.
Apartment prices in Wake County are over 20 percent higher than the state average. Forty-three percent of renters and 19 percent of homeowners report having difficulty affording housing.
See below to compare Wake County salaries and rent to statewide averages.
“I got more spiders in my house than I have outside. All kinds of spiders, some I ain’t never seen before. Then there’s centipedes that run around the house, and I mean big ones.”
“You have food deserts; we have an affordable housing desert, That is unacceptable. We must have the political will to address this issue.”
“This isn’t a matter of people being lazy or not having jobs or not being willing to work harder. I think that’s a very popular misconception.”
With shrinking supply and surging prices, many Wake County residents resort to dilapidated, unsafe housing conditions.
Left with no viable alternatives, residents jeopardize health when residing in spaces without regular heating and air conditioning, water supply or pest control.
“You have people living in all kinds of harsh situations because you don’t have affordable housing,” said Octavia Rainey, a housing advocate. “And that leads to all kinds of health issues, stress, hypertensions and people not taking care of themselves. If you’re not healthy, you can’t work.”
Homelessness is another growing concern in Wake County. There were 4,726 homeless persons in Wake County reported in 2016, including 749 children.
360 Video Courtesy of Madison Walls


We,at pizza world,are determined to ensure that you have that special moment with pizza and all added assortments e.g soda,gingerbread etc
Your choices on delivery are hand delivered or proceed to the restaurant to receive it yourself,Thank you
We are devoted to only be the best at serving you


btSoftBody implementation by Nathanael Presson
More...
#include <btSoftBodyInternals.h>
template<typename T>
struct btSymMatrix< T >
btSoftBody implementation by Nathanael Presson
Definition at line 33 of file btSoftBodyInternals.h.
◆ btSymMatrix() [1/2]
◆ btSymMatrix() [2/2]
◆ index()
◆ operator()() [1/2]
◆ operator()() [2/2]
template<typename T>
| const T& btSymMatrix< T >::operator() |
( |
int |
c, |
|
|
int |
r |
|
) |
| const |
|
inline |
◆ resize()
template<typename T>
| void btSymMatrix< T >::resize |
( |
int |
n, |
|
|
const T & |
init = T() |
|
) |
| |
|
inline |
◆ dim
◆ store
The documentation for this struct was generated from the following file:


WITNESS LIST Environmental Regulation Committee April 29, 1997-2:00P HB 3192 On: Duncan, David (TNRCC) SB 681 For: Bartosiewicz, John P. (Ft. Worth Transit Auth.) Duerr, John W. (Engine Manufacturers) O'Conner, Patrick (NAFA, Federal Express) Ratliff, Charles R. (The Frito Lay Company) Stiles, Rep. Mark (himself) Against: Pittman, Susan (American Lung Assn.) Registering, but not testifying: For: Culver, Anne (Mtro Trans of Harris Co) Igo, Shanna (Tx. Municipal League) Miksa, Mary (TABCC) Plaster, Michael (Texas Transit Assn.)


Apple Card users can get 3 percent back on Nike purchases
Source: iMore
What you need to know
- Nike joins companies like Uber/Uber Eats and Walgreens/Duane Reade in offering cashback.
- The promotion won't work in non-U.S. Nike stores.
- Allegations over gender discrimination with Apple Card continue to grow.
Just in time for the holiday shopping season, Apple has announced a new Apple Card promotion. Cardmembers now receive 3 percent cash back for purchases made across Nike's many retail platforms in the United States. The latest 3 percent cashback promotion for Apple Card includes purchases made through Nike stores, SNKRS, Nike Training Club, Nike.com, and the Nike app.
Source: Apple
As you would with purchases made at Apple retail locations, the 3 percent cashback is added to your Apple Card Daily Cash. When deposited, you can use the money to make Apple Pay purchases, help pay down your Apple Card balance, or send it to family and friends.
Besides Apple and Nike, you'll receive 3 percent cashback on Apple Card purchases made at Duane Reade, T-Mobile, Uber, Uber Eats, and Walgreens.
First announced in March, the Apple Card was officially released in the United States in August.
You can learn more about Apple Card through the official website.
We may earn a commission for purchases using our links. Learn more.


Meeta Mistry
is a member of the
Bionformatics Core at the
Harvard School of Public Health. Her training began in
Biochemistry, however postgraduate interests in computational
approaches fostered the transition to Bioinformatics. Her
expertise includes complex statistical analysis of large-scale
datasets, specifically those pertaining to next-generation
sequencing data. She also has a passion for teaching
bioinformatics with experience at the high school, graduate and
postgraduate level. Meeta has a PhD in Bioinformatics from the
University of British Columbia.


<?xml version="1.0" encoding="utf-8"?> <RecoverResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="Iacd24dbd4b3c79660f4d26aca7aaaea2" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success" RequestId="I66f40510c322d281602ce76b9eb04d7d" xmlns="http://www.w3.org/2002/03/xkms#"> <KeyBinding Id="I29cb8ac8a2ad878f7be44edfe53ea77a"> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> 3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> <Status StatusValue="http://www.w3.org/2002/03/xkms#Invalid"> <InvalidReason>http://www.w3.org/2002/03/xkms#Signature</InvalidReason> <InvalidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</InvalidReason> <InvalidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</InvalidReason> <InvalidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</InvalidReason> </Status> </KeyBinding> <PrivateKey> <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content" MimeType="text/xml"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" /> <xenc:CipherData> <xenc:CipherValue> DDSIEvW/tshnuCwCC+jX6y/srzMpt3qCIQ5zXmk/cHN4o/BItHsi9BJF85a3hnN C4/aFfPVJ3WgP6vIZNAUaDY2FbAJckWRgWhGku36p7DZTB14vmt5P5C1bXGU5ps CDw5Sbm+s/cFkReyfGk6khJTpbgQABPGIZBy2hiZMdSnu0eRgaVUXk9X5oPAhYU BjiQRq56ckHgEhkuwa+RiA+ybDNn/Ttjt5Uu5BjCONkOdeE8eJMlu0ykj99Vn7G NKUvt86bJsuwu5ZD1vSmVEwUAvHKV09UfVWfcKEINoj30t8Imj9naJ37oVRNPXl EKqZY9cxqzHiYEEhu0wxiTMiLbkEyh1DIcLNW78JXpWHRuRTrU5hgNzGEO1pKo7 1uRT1/lArojeJGCJKAwQJvCDXU9zZSXVLzU/AqUshR3L0AoY8pJ/p+LbmlTh43E 4TeT0iXNWkLz0mdgWdmwhhZtj8NcP/4auqfpv7+4NAP5OFVOEYJgE1I60F49K9m 7FbNygiAczfN1YZwjc5lLoIXo75cXduxOZgTWN8ZnFKwrhG1IMhstrauywur6lr lyxZ1JXEj2aohE4Msa7HKx1LSzDi3dejtK3ZFRqnJcJ1bQ/liOA1IgonN0wvUaH DM9ibo2xUie2DfoSw3kWCDf0bcZEcV33UFNR3w8kOHgpSAwdHJi0pRyHdgfyd8w 3NzvfCNy9AlrU2MbTdFF7hBxmgFK3fvaX7aEcgdqY17dqkiK75TAwzkVh5WkVjS WZGSiN49C8e4bY9zzq33lZwZabd5ts2Dvy3RuKc0hQj2rnCZcowXC+XJ7tVtMG+ lNu1ykyeYmvR8VI5Ame5h1DFPjoFLAjkt/tUu2uZlqLYoSKvJU4FWNMAXRUge+f L3f35lObqwxPJN/LVJgvgGqoMt5hO+/uwgsb3nbR7rTHavPX2kS5LDAtW5xNcfF dJz8l+dDjlYBJMN8cgEKnNtHTcnVJ5NiFPsGIFv/3IGUZsiw7M4dff3GN6quv9A 601e5rqG1ObMT6/7y7T0Z5IBXwiqs4HcdV+kyRfJwX1QpGat3nQsOZ59PTsIt5n oKSH0sB5AZmLJa1zgeOILJ574r+F6kD44R32NoLjqu0QL5IqfQ/0lQJuYhn0uEr FeZIn/lvjqzgf+rGPtgI5wtZ9Fv3qKrTPJOGM8atkzPkUtyJ8kR+WRhdAdFH9HM 0PgyrSGjcCGgFIppsN1KJawrvcXokGRzF81cD/3pVaZC/ZIBtvp4DXM2JSLGoa1 GpLuaIFUP5T/uxFf6MpW2v07bB/jqEZrcsB/ofmvv6RXD/gXrrw99iIiv0k2lyR sHDN5/syXglGGeskPvCUOZZ5oXrZruxER/IXKRnlsD+0wJ3JZCSuPy9wYmQk77F pynJ5//7w8UA2qWvkZ0B4rKXOgZYp2pCWaZIDknHJoY+VL7J3sQyAp7qlkQxSBj bhTEjSYXpHWA+Vj/TiH1ue7/ULlCKfDNvDaWFuEqGT/9H+xUJ5POfTDBhUh+Row rwCcfYe71B+pB/tylQEERKNpqqgu3TbNJZk5G8U9p41+PwJ0kw9EZnv+z8UEyFl qAZZxj64rTelurPUsiehBFwVwh2fATuMrW9fhGew11npVlF5k+WxE1Cz+ </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </PrivateKey> </RecoverResult>
[269]The decrypted private key parameters are:
<?xml version="1.0" encoding="utf-8"?> <RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2002/03/xkms#"> <Modulus> 3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2TUXCxYuztUU ClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5 O7Pn1/10ElslaF/TF8MQGqYE8= </Modulus> <Exponent>AQAB</Exponent> <P> 8dnXAObQvcKL0Rr/A+5Ufp1yJgLpH+uohFcJV2kUDCzv5VWKcN+LTq2mciKlnFbAQXKa5dNPO x4qi3An/4NSMQ== </P> <Q> 6TUX4d9+enb/aLHtck39x7cPQWlKkNFFJAqXaaRScDhjf4d8b009uW/pu3O2BdIJPY8M/QnUR lqXGLqGGl26fw== </Q> <DP> LVEcMFcPlf72I+BjGGF4A6GM2gKBnDGUCfglD/Pohb+F0/sLTcsVV1DCd3B2h6zZqWnIDHhjy DgG0MnbNM1ugQ== </DP> <DQ> 0DWm7PMtaQl1X3P8G2Gmgvjdlfj7qfAtWtBZ/ufG8oplyyab4oOD6FwSwlm82dV8iol9fy2Xa HjZDir6L/Ae4Q== </DQ> <InverseQ> sD2Vl/CCVTDbhhLwdfc4IQDBOh8xpBUV7PPM5LFGjiLetlfwaYi7Bp2ol8WF1MX88iCV2E3xO PCNfbMhvEB5dA== </InverseQ> <D> REUnMUhO6ZX6NxoCwkJ7El5wXAVGtlNJsnPqFygbeEjlBvD6TZx9TqnpP/8IX7WK6JUFWd9kn QJvCWeJjhbjnImSS/3xc+v+m4glnnebZbaghvfunbI++fQaNAFRVT1hLvEGknqC/7zsrUM04o gU7hP+XgdFTJ1QYGfGHl5c0IE= </D> </RSAKeyPair>
[270]X-KRSS specifies a mechanism for authenticating requests that is independent of any authentication mechanism provided by the message security binding. By its nature the X-KRSS protocol is required to support requests from parties who have yet to register their credentials or who have impaired credentials which are to be revoked.
[271]An X-KRSS Service SHOULD ensure that all requests are authentic and authorized.
[272] Authenticity: The request message originated from the specified party.
[273] Integrity: The request message has not been modified.
[274] Possession: If a public key is specified in a registration request, proof that the request is authorized by a party that has access to the corresponding private key.
[275]Registration services set their own authentication policy. This specification defines an authentication mechanism that employs a shared secret established out of band between the client and the registration service.
[276]Services SHOULD require that clients demonstrate Proof of Possession of the private key components of a public key if a request is made to register a valid key binding bound to that public key.
[277]Services SHOULD accept Proof of Possession of the private key component of a public key to effect revocation of any key binding bound to that key.
[277a]Clients and Responders MAY use dsig:KeyName for HMAC validation. Alternatively, they may use other Identity related information derived from security binding, such as the Sender's IP address.
[278]The protocol operations consist of a remote procedure call that consists of a single request message sent by the client to the registration service followed by a single response message sent by the server to the client.
[279]A response message MAY contain multiple key bindings if the operation resulted in the creation or a change in the status of multiple key bindings. For example a Register operation might cause two independent key bindings with different policy identifiers and validity intervals to be established in two independent underlying PKIs. Revocation of one such key binding might cause the revocation of other associated key bindings.
[280]The <PrototypeKeyBinding> element is derived from the KeyBindingAbstractType. It is used to specify the values of elements that a client requests be present in the keybinding resulting from a registration request.
[281]All fields in a <PrototypeKeyBinding> element are advisory and MAY be ignored by the service. For example a client might request registration under the policy identifier http://example.com/policy/high-security corresponding to a high assurance issuance policy but the returned key binding might specify the policy identifier http://example.com/policy/low-security corresponding to a low assurance issuance policy instead.
[282]The <PrototypeKeyBinding> element extends the KeyBindingAbstractType with the following additional elements:
- <ValidityInterval> [Optional]
- The suggested time interval for which the key binding relationship is valid.
- <RevocationCodeIdentifier> [Optional]
- Specifies a value to be used to validate a RevocationCode value in a subsequent Revocation request.
[283]The following schema defines the <PrototypeKeyBinding>element and PrototypeKeyBindingType:
<!-- PrototypeKeyBinding --> <element name="PrototypeKeyBinding" type="xkms:PrototypeKeyBindingType"/> <complexType name="PrototypeKeyBindingType"> <complexContent> <extension base="xkms:KeyBindingAbstractType"> <sequence> <element ref="xkms:ValidityInterval" minOccurs="0"/> <element ref="xkms:RevocationCodeIdentifier" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> <!-- /PrototypeKeyBinding -->
[284]The <RevocationCodeIdentifier> element contains a MAC output value encoded as a base64 string.
[285]The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism.
[286]On initial registration the <RevocationCodeIdentifier> value is obtained by first performing the MAC calculation on the pass phrase value, then performing a second MAC calculation on the result.
[287]To prove knowledge of the pass phrase in a subsequent revocation request the <RevocationCode> value is obtained by performing the MAC calculation on the pass phrase value.
[288]An advantage of employing the double MAC calculation is that it ensures that an XKMS service does not place arbitrary constraints on the length of or character set in which the pass phrase is encoded.
[289]Details of the MAC output value calculation are provided in the section Cryptographic Algorithm Specific Parameters below.
[290]The following schema defines the <RevocationCodeIdentifier> element and the RevocationCodeIdentifierTypetype:
<!-- RevocationCodeIdentifier --> <element name="RevocationCodeIdentifier" type="xkms:RevocationCodeIdentifierType"/> <simpleType name="RevocationCodeIdentifierType"> <restriction base="base64Binary"/> </simpleType> <!-- /RevocationCodeIdentifier -->
[291]The <Authentication> element is used to authenticate the key binding element within an X-KRSS request. This may be a <PrototypeKeyBinding>, <ReissueKeyBinding>, <RevokeKeyBinding> or <RecoverKeyBinding> element depending on the type of request.
- <KeyBindingAuthentication> [Optional]
- Authentication of the key binding by means of a signature using a previously established key.
- <NotBoundAuthentication> [Optional]
- Plaintext data used to authenticate the X-KRSS request that is not bound to the key binding.
- XKMS Responders do not have to support both of these optional elements in a request message.
[292]The following schema defines the <Authentication> element:
<!-- Authentication --> <element name="Authentication" type="xkms:AuthenticationType"/> <complexType name="AuthenticationType"> <sequence> <element ref="xkms:KeyBindingAuthentication" minOccurs="0"/> <element ref="xkms:NotBoundAuthentication" minOccurs="0"/> </sequence> </complexType> <!-- /Authentication -->
[293]The <KeyBindingAuthentication> element contains an XML Signature [XML-SIG] element that is used to authenticate the request using a previously established key.
- <ds:Signature> [Required]
- An XML Signature [XML-SIG] element that contains a signature over the <KeyBinding> or <PrototypeKeyBinding> element.
[294]The XML signature [XML-SIG] is generated as a detached signature using the Id attribute specified in KeyBindingAbstractType to specify the signature scope.
[295]The following schema defines the <KeyBindingAuthentication> element:
<!-- KeyBindingAuthentication --> <element name="KeyBindingAuthentication" type="xkms:KeyBindingAuthenticationType"/> <complexType name="KeyBindingAuthenticationType"> <sequence> <element ref="ds:Signature"/> </sequence> </complexType> <!-- /KeyBindingAuthentication -->
[296]The <NotBoundAuthentication> contains plaintext authentication data (e.g., limited use shared secret) that is used to authenticate the request.
- Protocol [Required]
- A URI specifying the authentication protocol used.
- Value [Required]
- The plaintext authentication data encoded in base64 format.
[297]The specification of protocol URIs is outside the scope of this document.
[298]This element is provided to support applications in which the authentication scheme requires the server to have plaintext access to the authentication data. The authentication data is not securely bound to the request and thus the element MUST NOT be employed except in circumstances where the message or transport protocol provides adequate protection of both confidentiality and integrity.
[299]The following schema defines the <NotBoundAuthentication> element:
<!-- NotBoundAuthentication --> <element name="NotBoundAuthentication" type="xkms:NotBoundAuthenticationType"/> <complexType name="NotBoundAuthenticationType"> <attribute name="Protocol" type="anyURI" use="required"/> <attribute name="Value" type="base64Binary" use="required"/> </complexType> <!-- /NotBoundAuthentication -->
[300]The <ProofOfPossession> element contains a XML Signature [XML-SIG] element. The signature scope is the <PrototypeKeyBinding> using the public key that is to be registered. The private key component of the public key contained within the <PrototypeKeyBinding> is used to generate the signature.
- <ds:Signature> [Required]
- An XML Signature [XML-SIG] element that contains a detached signature over the <PrototypeKeyBinding> element. The signing key is the key identified by the ds:KeyInfo element within the <PrototypeKeyBinding> element.
[301]The XML signature [XML-SIG] is generated as a detached signature using the Id attribute specified in KeyBindingAbstractType to specify the signature scope.
[302]The following schema defines the <ProofOfPossession> element:
<!-- ProofOfPossession --> <element name="ProofOfPossession" type="xkms:ProofOfPossessionType"/> <complexType name="ProofOfPossessionType"> <sequence> <element ref="ds:Signature"/> </sequence> </complexType> <!-- /ProofOfPossession -->
[303] The <PrivateKey> element contains the encrypted private key parameters returned by the service in a response to a registration request with server generated keys or a response to a successful recovery request.
- <xenc:EncryptedData> [Required]
- The encrypted private key data. This element is as defined by the XML Encryption Specification [XML-Enc]. The Type attribute SHOULD be present and, if present, MUST contain a value of
http://www.w3.org/2001/04/xmlenc#Content
. The MimeType attribute, SHOULD be "text/xml
".
[304]The following schema defines the <PrivateKey> element:
<!-- PrivateKey --> <element name="PrivateKey" type="xkms:PrivateKeyType"/> <complexType name="PrivateKeyType"> <sequence> <element ref="xenc:EncryptedData"/> </sequence> </complexType> <!-- /PrivateKey -->
[305] The <RevocationCode> element contains a MAC output value encoded as a base64 string.
[306]The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism.
[307]On initial registration the <RevocationCodeIdentifier> value is obtained by first performing the MAC calculation on the pass phrase value, then performing a second MAC calculation on the result.
[308]To prove knowledge of the pass phrase in a subsequent revocation request the <RevocationCode> value is obtained by performing the MAC calculation on the pass phrase value.
[309] Details of the MAC output value calculation are provided in the section Cryptographic Algorithm Specific Parameters below.
[310]The following schema defines the <RevocationCode> element and the RevocationCodeType:
<!-- RevocationCode --> <element name="RevocationCode" type="xkms:RevocationCodeType"/> <simpleType name="RevocationCodeType"> <restriction base="base64Binary"/> </simpleType> <!-- /RevocationCode -->
[311]The register request message contains a <RegisterRequest> element that contains the following elements:
- <PrototypeKeyBinding> [Required]
- Specifies elements that the client requests be registered.
- <Authentication> [Required]
- Information that authenticates the request.
- <ProofOfPossesion> [Optional]
- Proof of possession of the private key component of the key binding. A Service that requires the ProofOfPossession element MUST return a Sender.ProofOfPossessionRequired result if the ProofOfPossession element is not present in the request.
[312]The following schema defines the <RegisterRequest> element:
<!-- RegisterRequest --> <element name="RegisterRequest" type="xkms:RegisterRequestType"/> <complexType name="RegisterRequestType"> <complexContent> <extension base="xkms:RequestAbstractType"> <sequence> <element ref="xkms:PrototypeKeyBinding"/> <element ref="xkms:Authentication"/> <element ref="xkms:ProofOfPossession" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> <!-- /RegisterRequest -->
[313]The register response message contains a <RegisterResult> element that contains the following elements:
- <KeyBinding> [Any number]
- If present specifies the key binding that was registered by the service.
- <PrivateKey> [Optional]
- The values of the private key parameters of a private key generated by the registration service.
[314]The following schema defines the <RegisterResult> element:
<!-- RegisterResult --> <element name="RegisterResult" type="xkms:RegisterResultType"/> <complexType name="RegisterResultType"> <complexContent> <extension base="xkms:ResultType"> <sequence> <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/> <element ref="xkms:PrivateKey" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> <!-- /RegisterResult -->
[315]The reissue request message contains a <ReissueRequest> element that contains the following elements:
- <ReissueKeyBinding> [Required]
- Identifies the key binding to be reissued.
- <Authentication> [Required]
- Information that authenticates the request.
- <ProofOfPossesion> [Optional]
- Proof of possession of the private key component of the key binding. A Service that requires the ProofOfPossessionelement MUST return a Sender.ProofOfPossessionRequired result if the ProofOfPossession element is not present in the request.
[316]The following schema defines the <ReissueRequest> and <ReissueKeyBinding> elements:
<!-- ReissueRequest --> <element name="ReissueRequest" type="xkms:ReissueRequestType"/> <complexType name="ReissueRequestType"> <complexContent> <extension base="xkms:RequestAbstractType"> <sequence> <element ref="xkms:ReissueKeyBinding"/> <element ref="xkms:Authentication"/> <element ref="xkms:ProofOfPossession" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> <element name="ReissueKeyBinding" type="xkms:KeyBindingType"/> <!-- /ReissueRequest -->
[317]The reissue response message contains a <ReissueResult> element that contains the following element:
- <KeyBinding> [Any Number]
- If present specifies the key binding(s) that were reissued by the service
[318] The following schema defines the <ReissueResult> element:
<!-- ReissueResult --> <element name="ReissueResult" type="xkms:ReissueResultType"/> <complexType name="ReissueResultType"> <complexContent> <extension base="xkms:ResultType"> <sequence> <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> <!-- /ReissueResult -->
[319]The revoke request message contains a <RevokeRequest> element that contains the following elements:
- <RevokeKeyBinding> [Required]
- Identifies the key binding to be revoked.
- <Authentication> [Choice]
- Information that authenticates the request.
- <RevocationCode> [Choice]
- The revocation code value that generates the revocation code identifier value specified during registration.
[320]The following schema defines the <RevokeRequest> and <RevokeKeyBinding> elements:
<!-- RevokeRequest --> <element name="RevokeRequest" type="xkms:RevokeRequestType"/> <complexType name="RevokeRequestType"> <complexContent> <extension base="xkms:RequestAbstractType"> <sequence> <element ref="xkms:RevokeKeyBinding"/> <choice> <element ref="xkms:Authentication"/> <element ref="xkms:RevocationCode"/> </choice> </sequence> </extension> </complexContent> </complexType> <element name="RevokeKeyBinding" type="xkms:KeyBindingType"/> <!-- /RevokeRequest -->
[321]The request message contains a <RevokeResult> element that contains the following element:
- <KeyBinding> [Any Number]
- If present specifies the key binding that was revoked by the service.
[322]The following schema defines the <RevokeResult>:
<!-- RevokeResult --> <element name="RevokeResult" type="xkms:RevokeResultType"/> <complexType name="RevokeResultType"> <complexContent> <extension base="xkms:ResultType"> <sequence> <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> <!-- /RevokeResult -->
[323]The recover request message contains a <RecoverRequest> element that contains the following elements:
- <RecoverKeyBinding> [Required]
- Identifies the key binding to be recovered.
- <Authentication> [Required]
- Information that authenticates the request.
[324]The following schema defines the <RecoverRequest> and <RecoverKeyBinding> elements:
<!-- RecoverRequest --> <element name="RecoverRequest" type="xkms:RecoverRequestType"/> <complexType name="RecoverRequestType"> <complexContent> <extension base="xkms:RequestAbstractType"> <sequence> <element ref="xkms:RecoverKeyBinding"/> <element ref="xkms:Authentication"/> </sequence> </extension> </complexContent> </complexType> <element name="RecoverKeyBinding" type="xkms:KeyBindingType"/> <!-- /RecoverRequest -->
[325]The request message contains a <RecoverResult> element that contains the following elements:
- <KeyBinding> [Any Number]
- May be present to advertise a change to the status of the key binding made as a result of the key recovery.
- <PrivateKey> [Optional]
- The values of the private key parameters of the recovered private key.
[326]The following schema defines the <RecoverResult> element:
<!-- RecoverResult --> <element name="RecoverResult" type="xkms:RecoverResultType"/> <complexType name="RecoverResultType"> <complexContent> <extension base="xkms:ResultType"> <sequence> <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded"/> <element ref="xkms:PrivateKey" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> <!-- /RecoverResult -->
[327]It is frequently necessary or desirable to use a limited use shared secret for authentication (i.e. a one time use PIN or pass phrase) to authenticate registration request messages. In particular a private key cannot be used for authentication until the corresponding public key has been registered.
[328]In addition it is desirable that private key parameters generated or recovered by the registration service be returned encrypted. It is convenient to use symmetric data for this purpose.
[329a] The symmetric key data MAY be binary data (as from an authentication device) or as a human-readable value (numeric, alphabetic, or both). When it is binary data, no transformation is needed; the data can be used directly as input to the MAC function.
[329b] When the symmetric key data is human-readable, it may be issued to a human user in the form of a text string which may in some circumstances be read over a telephone line. It may be randomly generated and represent an underlying numeric value, or may be a password or phrase. In either case, it is often convenient to present the value to the human user as a string of characters in a character set the particular user understands. To limit the possibility of human error in processing the symmetric key data, and to provide a canonical binary representation, the string text must be compliant to the SASLprep stringprep profile for user names and passwords,[SASLPREP].
[329c] The algorithm for canonicalizing a string-text before feeding it to the MAC function is the following:
[330]Applications MUST ensure that the limited use shared secret data contains sufficient entropy to prevent dictionary attacks. For more details see the more detailed comment in the security considerations section of this document.
[331]Keying material is derived from the shared string using a MAC function.
[332]The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism.
[333]Different MAC keying values are used according to the use of the symmetric key derived as follows:
| Value | Application |
|---|---|
| 0x1 | Authentication |
| 0x2 | Encoding of RevocationCodeIdentifier - Pass 1 |
| 0x3 | Encoding of RevocationCodeIdentifier - Pass 2 |
| 0x4 | Encryption of PrivateKey data |
[334]If the output of the MAC function provides more keying material than is required for a cryptographic operation (i.e. encryption, MAC), the lowest significant bits are used.
[335]If the output of the MAC function provides less keying material than is required additional keying material is obtained as follows:
[336]block0 = MAC (converted, key)
[337]blockn+1 = MAC (converted, key XOR blockn)
[338]output = block0 + block1 ... blockn
[339]i.e. the first MAC output value is used to supply the least significant bits of keying material. A second MAC output value is then obtained by applying the MAC function to the converted string again, this time the MAC keying value is obtained by XOR-ing the first output with the previous keying value. This process may be repeated as many times as necessary to produce a sufficient amount of keying material.
[340]The <PrivateKey> element may contain the private key parameters for any public key encryption algorithm. The parameters for the RSA algorithm are specified below.
[341]This specification does not specify private key parameters for the DSA signature algorithm since the algorithm only supports signature modes and so the application of server generated keys and key recovery is of limited value.
[342]The <RSAKeyPair> element specifies the public and private parameters of an RSA key pair. The contents of the RSAKeyPair element are specified in [PKCS1]. The RSAKeyPair> element contains the following parameters:
- <Modulus> (Required)
- The modulus.
- <Exponent> (Required)
- The public exponent.
- <P> (Required)
- The first factor, a positive integer.
- <Q> (Required)
- The second factor, a positive integer.
- <DP> (Required)
- The first factor's CRT exponent, a positive integer.
- <DQ> (Required)
- The second factor's CRT exponent, a positive integer.
- <InverseQ> (Required)
- The (first) CRT coefficient, a positive integer.
- <D> (Required)
- The private exponent.
[343] The following schema defines the <RSAKeyPair> element:
<!-- RSAKeyPair --> <element name="RSAKeyPair" type="xkms:RSAKeyPairType"/> <complexType name="RSAKeyPairType"> <sequence> <element ref="xkms:Modulus"/> <element ref="xkms:Exponent"/> <element ref="xkms:P"/> <element ref="xkms:Q"/> <element ref="xkms:DP"/> <element ref="xkms:DQ"/> <element ref="xkms:InverseQ"/> <element ref="xkms:D"/> </sequence> </complexType> <element name="Modulus" type="ds:CryptoBinary"/> <element name="Exponent" type="ds:CryptoBinary"/> <element name="P" type="ds:CryptoBinary"/> <element name="Q" type="ds:CryptoBinary"/> <element name="DP" type="ds:CryptoBinary"/> <element name="DQ" type="ds:CryptoBinary"/> <element name="InverseQ" type="ds:CryptoBinary"/> <element name="D" type="ds:CryptoBinary"/> <!-- /RSAKeyPair -->
[344]The section describes features and operations that XKMS applications whose support is either required or recommended to ensure interoperability of XKMS services.
[345]As such the conformance requirements fall on message recipients rather than message senders, although a sender SHOULD NOT send a message unless it is known that it will be accepted by the recipient.
[346]The following table specifies the conformance requirements of XKMS as REQUIRED,. RECOMMENDED or OPTIONAL as follows:
[347]If support for a feature is specified as REQUIRED a conforming XKMS implementation MUST support the use of that feature in a message sent by another XKMS implementation.
[348]If support for a feature is specified as RECOMMENDED a conforming XKMS implementation SHOULD support the use of that feature if used by another XKMS implementation.
[349]If support for a feature is specified as OPTIONAL, XKMS implementations SHOULD NOT send messages requiring support for that feature.
[350]Some features are specified as REQUIRED* or RECOMMENDED*. This signifies that the condition holds if another feature is supported. For example an XKMS Locate service is not required to support XML Signature. If however XML Signature is supported the use of Exclusive Canonicalization MUST be supported.
[351]One feature is specified as RECOMMENDED +. This signifies that even though this feature can only be used at the request of the client it is strongly recommended that the client request use of this feature since a service is likely to require it for the response to be successful.
[352]Where a service supports a feature that is advertised as OPTIONAL it is recommended that the service advertise this feature by means of a Web Service description mechanism. For example an XKMS service that supports the use of a transport encoding other than HTTP SHOULD advertise that fact.
[352a] When a client request includes an OPTIONAL element that is not supported by the Server, the server may use ResultMajor=Receiver and ResultMinor=OptionalElementNotSupported code. In some cases, depending on the context, the server may use the Failure or MessageNotSupported ResultMinor codes. In any of these cases, the client should check the server's supported features, for example by reading a WSDL [WSDL] or metadata file. The resource discovery mechanism is out of scope for this specification.
[353]Implementers should note that these requirements may change in future versions of the XKMS specification. For example it is likely that future versions of the XKMS specification will make the then current version of the SOAP specification a requirement.
| Feature | Operations | Requirement Level | Comments |
|---|---|---|---|
| Operation Support | Locate | RECOMMENDED | Services SHOULD support retrieval of their own credential by means of the Locate operation with the XKMS protocol URI. |
| All | One Operation REQUIRED | A conforming XKMS service MUST support at least one XKMS operation, that is there MUST be at least one possible input that results in the result Success. | |
| Compound | OPTIONAL | See note for Status operation support. | |
| Status | RECOMMENDED* | Services SHOULD support status operations if asynchronous processing and compound requests are also supported. | |
| Operation Response | All | REQUIRED | A conforming XKMS service MUST accept any valid XKMS request sent to it and be capable of responding to the request with a correctly formatted XKMS result. If a service does not support an operation it MUST respond to all requests for a particular operation with the result Sender.MessageNotSupported. |
| Feature | Operations | Requirement Level | Comments |
|---|---|---|---|
| Synchronous Response | All | REQUIRED | A conforming XKMS service MUST be capable of returning an immediate response to any XKMS request. |
| Asynchronous Response | Register, Reissue, Recover | RECOMMENDED+ | Processing of certain X-KRSS operations may require manual intervention by an operator in certain circumstances. It is therefore recommended that clients support the use of asynchronous processing with these operations unless it is known that all requests will be serviced immediately. |
| Compound | RECOMMENDED | Services that support Compound Operations SHOULD support compound requests. | |
| Locate, Validate, Revoke |
OPTIONAL | Services MAY support Asynchronous responses be supported on these operations. | |
| Pending, Status |
PROHIBITED | A client MAY offer asynchronous processing of Pending and Status operations however a service MUST NOT return a pending response. | |
| Two-Phase Request | All | RECOMMENDED+ | Clients SHOULD support use of the two-phase request protocol. The additional complexity of implementing the two phase protocol is not high and allows a service to provide a response even in cases where it is under a denial of service attack. |
| Feature | Operations | Requirement Level | Comments |
|---|---|---|---|
| HTTP Transport | All | REQUIRED | Services MUST support the use of HTTP transport. |
| SOAP 1.2 Transport | All | REQUIRED | Services MUST support the use of SOAP 1.2 encapsulation. |
| SOAP 1.1 Transport | All | RECOMMENDED | Services MAY support the use of SOAP 1.1 encapsulation. |
| Feature | Operations | Requirement Level | Comments |
|---|---|---|---|
| No Security Binding | Locate | REQUIRED | An XKMS Service MUST be capable of supporting Locate operations without requiring any authentication or protocol security mechanisms. |
| [Others] | RECOMMENDED | ||
| Payload Authentication Binding | All | RECOMMENDED | If XML Signature is used, Exclusive Canonicalization MUST be supported. |
| TLS Binding | All | RECOMMENDED |
[355]Implementations SHOULD consider the following security issues.
[356]Implementations SHOULD ensure that replay of a previous XKMS response is not possible.
[357]The precise mechanism by which replay attacks are prevented is left to the implementation. For example generic mechanism built into the object exchange protocol if specified MAY be used.
[358]A generally applicable means of preventing a replay attack is to place a token in each message that demonstrates to the recipient that the message is 'fresh', for example:
[359]XKMS Services SHOULD take measures to prevent or mitigate denial of service attacks. In particular XKMS Services SHOULD NOT perform an unlimited number of resource intensive operations unless the request comes from an authenticated source. Potentially resource intensive operations include:
[360]Key recovery policy is left as an implementation decision.
[361]Depending on the implementation and application, a key recovery operation might involve an unacceptable loss of confidence in the security of a private key component. This may lead to the possibility of repudiation of a signed document or of accountability in the case of an encrypted document.
[362]Services SHOULD carefully assess the extent to which a recovery operation compromises a private key and apply sufficient controls such as the revocation of the underlying key binding as appropriate.
[363]If a limited use shared secret is used care must be taken to ensure that the secret has sufficient entropy that the probability of guessing by an attacker is tolerably low. Particular care must be taken if a limited use shared secret is used to encrypt a service generated private key since the transported private key might be subject to a dictionary attack. Implementations should not re-use revocation codes across different key bindings (regardless of the amount of entropy used when generating them). Note that strong confidentiality protection of RevocationCodeIdentifier and RevocationCode elements would also help against this problem. Applications SHOULD enforce the following minimum entropy values for the shared secret:
- Registration of Client Generated Key
- The shared secret SHOULD contain a minimum of 32 bits of entropy if the service implements measures to prevent guessing of the shared secret (which MAY include strong confidentiality protections for revocation code identifiers and revocation codes, providing safeguards against the dictionary attacks, and to protect against attackers recognizing deliberate or accidental collisions of revocation codes) and a minimum of 128 bits of entropy otherwise.
- Registration of Service Generated Key
- The shared secret SHOULD have a minimum of 128 bits of entropy.
[364]Clients SHOULD NOT send confidential or privacy sensitive data to an XKMS Service as Opaque Data unless it is encrypted such that it is not disclosed to the service.
[365]Examples of confidential data include internal program indices such as pointers which might permit a malicious party with access to an XKMS service or its audit logs to perform an attack based on knowledge of the internal state of the client.
[366]If a service supports the use of authentication using the <NotBoundAuthentication> element, controls MUST be employed to ensure the confidentiality of the authentication data and to ensure that the <NotBoundAuthentication> is bound to the request.
[367]This MAY be a message level or transport level protocol that protects both encryption and integrity such as TLS [RFC-2246].
[368]XKMS services that provide signed responses SHOULD ensure that the requestor cannot solicit a predicted response, thus providing a signing oracle. Such a signing oracle might provide a direct compromise for the key under a different protocol or allow a weakness in the signature or digest algorithm employed to be exploited.
[369]Response messages should include at least as much randomly chosen data as the output of the digest algorithm used to create the signature. For example a message signed using RSA and SHA-1 should contain at least 160 bits of random data.
[370]An XKMS service MAY solicit data which is subject to privacy concerns. In certain circumstances management of such data MAY be subject to government regulation, corporate policies or contractual obligations. Deployments SHOULD consider whether the information they collect is subject to such concerns and if necessary deploy a privacy notification mechanism such as P3P [P3P].
[371]Implementations MUST ensure that in cases where a private key is generated by the service, the information used to encrypt the private key data is adequately protected. In particular if an authentication pass phrase exchanged out of band is used to encrypt the private key the implementation MUST ensure that the out of band communication mechanism adequately protects the confidentiality of the pass phrase.
[372]It is recommended that implementations make use of TLS or an in-band key exchange mechanism to protect the private key in the case that the authentication pass phrase is disclosed.
[372a]Implementations supporting encryption of Private Key Data MUST support Shared Secret. Use of Shared Secret is detailed in section 8.1.
[373]In certain circumstances the length of an encrypted response MAY reveal information that is useful to an attacker. For example a short message might indicate that a request was refused. Deployments SHOULD consider whether such disclosures might result in compromise of confidential information.
[373a] The Implementation of XKMS MUST check for
a signature value reference in the to-be-signed data when using a Signed SOAP
message. Also, implementations MUST ensure that all the bytes in the XKMS messages,
e.g., from <LocateRequest> .... </LocateRequest>
, be included in
hashing and in the resulting signature value of the message.
[374]In many instances it is desirable to advertise the existence of an XKMS service in some form of discovery protocol. This appendix describes specific means of advertising the existence of XKMS services in the Internet Domain Name Service (DNS).
[375]The provision of an XKMS service that provides information on key information bound to DNS addresses in a specified DNS zone MAY be advertised by means of the DNS SRV record [RFC 2782]. An SRV record contains the following data fields:
[376]_Service._Protocol.NameTTLClassSRVPriorityWeightPortTarget
[377]The following service values are defined:
[378]The publication of an SRV record in a DNS zone that advertises an XKMS service is an affirmative statement by the operator of the zone that the XKMS service indicated MAY be queried for information concerning key information bound to protocol addresses within that zone. The publication of an SRV record does not imply any undertaking on the part of the part of the publisher to ensure that the information provided by the XKMS service is accurate or trustworthy. Relying parties MUST therefore establish the trustworthiness of any information they may receive from an XKMS service discovered by means of an SRV record by other means, for example by forwarding the data to an XKMS Validate service.
[379]The following SRV record advertises an XKMS X-KISS service on port 80 of border-xkms.example.com:
[380]_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 1 80 border-xkms.example.com
[381]The following SRV record advertises three XKMS X-KISS services, main1, main2 and backup. Clients should direct requests to main1 and main2 with equal priority. The service backup should only be accessed if neither main1 or main2 is available:
[382]_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 50 80
main1.example.com
_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 50 80 main2.example.com
_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 1 1 80
backup.example.com
[383]For clarity the examples in the running text omit certain details such as the message authentication signatures and SOAP binding information. This section provides these messages in full to facilitate interoperability testing.
[384]The calculation of the authentication values used in the examples.
[385]The secret key is used to encrypt Bob's private key as follows:
<?xml version="1.0"
encoding="utf-8"?>
<RSAKeyPair xmlns="http://www.w3.org/2002/03/xkms#"> ...
[386]The calculation of the pass phrase values used in the examples.
[387]The parameters of the parties RSA key pairs are as follows:
<?xml version="1.0" encoding="utf-8"?> <RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2002/03/xkms#"> <Modulus> 0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgG thO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GD NiHKVDQggPBLc1XagW20RMvok= </Modulus> <Exponent>AQAB</Exponent> <P> 7p05u5P4BO+aXdyD/6n31a4Dk9kC4Tv5fMbE15/ioPii9JwPU2J29qhO1QEqvgNwxv67w4jrC 025Yz5LXgjziw== </P> <Q> 4ceKAtGgSJg8ddRxwz8OESXVOd1tlSHFu7Gqona3VxbrOONLZEbsnYA4dv4nI+pxl8PmUe5CP gggGElx30OIuw== </Q> <DP> ve9rEDQVfaBYCRTKAY2DGJT+hgZ881qxGjCCaXz8gdPIqts6m85KEcchkQ3vvvawI8aLIXdwW TwSMLxac8y+Rw== </DP> <DQ> jW/x3ggx76gmn+3hAl3a0xUvORukjTrl4snOyg2ylsUNv8prrTrc+WGcfbaDEHXKiTc4bnTiX He8m1pPEnz9Bw== </DQ> <InverseQ> yxCo+k0v8n80Qeo2QAGKiwltLF+1ObyZ1TQg4chISWdfLD+j1nIKIs1miELdszjO/szLWMx5k A3kOLi6jXsByw== </InverseQ> <D> aeLWu8jh75/zRGdL6T1QFatvfH5uwHXQW4EeZJ00/P0lghEOvgNPWPGkjpaxNtW39GvaaWoJN pilw9CFL2HHIVn1OVZyw5BDbotQty3lm66KL7qtrjqlqyPu5ARglGqTZIaRyP8LW6NAbkyxLP npADVfHJuEePmooCmHbTValP0= </D> </RSAKeyPair>
<?xml version="1.0" encoding="utf-8"?> <RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2002/03/xkms#"> <Modulus> 3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2TUXCxYuztUU ClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5 O7Pn1/10ElslaF/TF8MQGqYE8= </Modulus> <Exponent>AQAB</Exponent> <P> 8dnXAObQvcKL0Rr/A+5Ufp1yJgLpH+uohFcJV2kUDCzv5VWKcN+LTq2mciKlnFbAQXKa5dNPO x4qi3An/4NSMQ== </P> <Q> 6TUX4d9+enb/aLHtck39x7cPQWlKkNFFJAqXaaRScDhjf4d8b009uW/pu3O2BdIJPY8M/QnUR lqXGLqGGl26fw== </Q> <DP> LVEcMFcPlf72I+BjGGF4A6GM2gKBnDGUCfglD/Pohb+F0/sLTcsVV1DCd3B2h6zZqWnIDHhjy DgG0MnbNM1ugQ== </DP> <DQ> 0DWm7PMtaQl1X3P8G2Gmgvjdlfj7qfAtWtBZ/ufG8oplyyab4oOD6FwSwlm82dV8iol9fy2Xa HjZDir6L/Ae4Q== </DQ> <InverseQ> sD2Vl/CCVTDbhhLwdfc4IQDBOh8xpBUV7PPM5LFGjiLetlfwaYi7Bp2ol8WF1MX88iCV2E3xO PCNfbMhvEB5dA== </InverseQ> <D> REUnMUhO6ZX6NxoCwkJ7El5wXAVGtlNJsnPqFygbeEjlBvD6TZx9TqnpP/8IX7WK6JUFWd9kn QJvCWeJjhbjnImSS/3xc+v+m4glnnebZbaghvfunbI++fQaNAFRVT1hLvEGknqC/7zsrUM04o gU7hP+XgdFTJ1QYGfGHl5c0IE= </D> </RSAKeyPair>
<?xml version="1.0" encoding="utf-8"?> <RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2002/03/xkms#"> <Modulus> 189VeX3+tAcwQPGMtYm8/CEKRfe6DtBFZ11SAREHhMIqf68/dsmbes0q0dnxWQcKfQtVDfp6R f0ulk5rZZ3j2vHHK9OFXMfaF+zJdATJ3KkXd5myjNf2clYWqKZp7K8/7Wo/qIiL8EsCT7yihR QvkYfYprFbF9GjKJPs4ng+zE8= </Modulus> <Exponent>AQAB</Exponent> <P> 6+mJu5c75rQ2D0NjjZVgpzwHC2Rqcz+Dqs8E+f6yN2cYH5DTRKk08YGWSJanxwkNHCRSOC8KZ spLzmnVUyKavw== </P> <Q> 6i+ZxJX3FDz8SwIvFEp+Vzu2C+N3USgOWGghrZuYzxKSoawpmIU0+22IVug1H3w0c7ae+5d35 8O8APR+7v0CcQ== </Q> <DP> Wizzy/P8HqyF+YGd3THbNzGX07/3fMQrdTAay+CSiODsdKxsRVOUfDg3lNmZmlgYXch4cSdyB 2aOYYFM3LFeiw== </DP> <DQ> 0GAuiHeP9FgXfX6h+YIXTPN6lrV9k576tLtjTCCpJYe3JVgVYvsUG6xopjvUGQHhghy69c7fC EBn5smmsGw8YQ== </DQ> <InverseQ> phQH0GiKxdQnq7xj+5z69zLL6cI/53STn/XXZz9A/XRPUJecJxUguJHgbrKAI1aylLBZB0CfS +UVkIkoF/nP2g== </InverseQ> <D> ybPx+oRlO1QAqKJa1g2vgaNL28tGrbPBOnPBQlftRArJ998OnPKfi+4YWFyvs3reNbMSwubZw 3J4SWlv/WDN5Ux2ozdqjl8DShZfhpeRhVIkygg8tDqqbkVmuzQyUbDR5NncMiEPX5errlrCyd wsc2OgUDHYXslORPsRFh/Fk6E= </D> </RSAKeyPair>
[388][CSP] C. A. R. Hoare, Communicating Sequential Processes, Prentice Hall, 1985, http://www.usingcsp.com/.
[389][P3P] L. Cranor, M. Langheinrich, M. Marchiori, M. Presler-Marshall, J. Reagle, The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, W3C Recommendation 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/.
[390][PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF RFC 2459, January 1999, http://www.ietf.org/rfc/rfc2459.txt.
[391][PKCS1] B. Kaliski, PKCS #1: RSA Encryption Version 2.0, RSA Laboratories, also IETF RFC 2437, October 1998. http://www.ietf.org/rfc/rfc2437.txt.
[392][RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt.
[393][RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF RFC 2459, January 1999. http://www.ietf.org/rfc/rfc2459.txt.
[394][RFC-2104] H. Krawczyk,, M. Bellare, and R. Canetti, HMAC: Keyed Hashing for Message Authentication, IETF RFC 2104, February 1997. http://www.ietf.org/rfc/rfc2104.txt.
[395][RFC-2246] T. Dierks, C. Allen., The TLS Protocol Version, 1.0. IETF RFC 2246 January 1999. http://www.ietf.org/rfc/rfc2246.txt.
[396][RFC-2373] R. Hinden, S. Deering,IP Version 6 Addressing Architecture, IETF RFC 2373 July 1998., http://www.ietf.org/rfc/rfc2373.txt.
[397][RFC-2782] A. Gulbrandsen, P. Vixie, L. Esibov, A DNS RR for specifying the location of services (DNS SRV). IETF RFC 2782, February 2000. http://www.ietf.org/rfc/rfc2782.txt.
[397b][SASLPREP] K. D. Zeilenga, SASLprep: Stringprep profile for user names and passwords, IETF RFC 4013, February 2005, http://www.ietf.org/rfc/rfc4013.txt.
[398][SOAP] M. Gudgin, et al. SOAP Version 1.2 Part 1: Messaging Framework, W3C Recommendation 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.
[399][XMLP] XML Protocol Working Group, http://www.w3.org/2000/xp/Group/.
[400][WSDL] R. Chinnici, M. Gudgin, J.-J. Moreau, J. Schlimmer, S. Weerawarana, Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Working Draft, 3 August, 2004, latest draft at http://www.w3.org/TR/wsdl20.
[401][X509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997.
[402][XML] T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen. Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. October 2000. http://www.w3.org/TR/2000/REC-xml-20001006.
[403][XML-SIG] D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XML-Signature Syntax and Processing, W3C Recommendation, 12 February 2002. http://www.w3.org/TR/xmldsig-core/.
[404][XML-SIG-XSD] XML Signature Schema available from http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd.
[405][XML-Enc] D. Eastlake, J. Reagle, T. Imamura, B. Dillaway, E. Simon, XML Encryption Syntax and Processing, W3C Recommendation, 10 December 2002, http://www.w3.org/TR/xmlenc-core/.
[406][XML-NS] T. Bray, D. Hollander, A. Layman. Namespaces in XML. W3C Recommendation. January 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114.
[407][XML-Schema1] H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn. XML Schema Part 1: Structures Second EditionW3C Recommendation 28 October 2004. 2001. http://www.w3.org/TR/xmlschema-1/.
[408][XML-Schema2] P. V. Biron, A. Malhotra, XML Schema Part 2: Datatypes Second Edition; W3C Recommendation 28 October 2004. http://www.w3.org/TR/xmlschema-2/.
[409][XAdES] J.C. Cruellas, G. Karlinger, K. Sankar XML Advanced Electronic Signatures, W3C Note 20 February 2003. http://www.w3.org/TR/XAdES/.
[410]This specification is the work of the W3C XML Key Management Working Group. The contributions of the following Working Group members to this specification are gratefully acknowledged in accordance with the contributor policies and the active WG roster.
[411]Participants in the Working Group are (at the time of writing, and by alphabetical order): Guillermo Alvaro Rey (Trinity College Dublin), Stephen Farrell (Trinity College Dublin, Co-Chair), José Kahan (W3C, staff contact), Berin Lautenbach (Apache Software Foundation), Tommy Lindberg (Markup Security), Roland Lockhart (Entrust, Inc.), Vamsi Motukuru (Oracle Corp.), Shivaram Mysore (Co-Chair; Editor since 13 Apr 2004), Rich Salz (DataPower Technology, Inc.), Yunhao Zhang (SQLData Systems).
[412]Previous participants were (by alphabetical order): Daniel Ash (Identrus), Blair Dillaway (Microsoft), Donald Eastlake 3rd (Motorola), Yassir Elley (Sun Microsystems), Jeremy Epstein (webMethods), Slava Galperin (Sun Microsystems), Phillip Hallam-Baker (VeriSign Inc, Editor until 13 Apr 2004), Loren Hart (VeriSign Inc.), Mack Hicks (Bank of America), Merlin Hughes (Baltimore), Frederick Hirsch (Nokia Mobile Phones), Mike Just (Treasury Board of Canada Secretariat), Brian LaMacchia (Microsoft), Pradeep Lamsal, Joseph Reagle (W3C, previous staff contact), Dave Remy (GeoTrust, Inc.), Peter Rostin (RSA Security Inc.), Ed Simon (XMLsec Inc.)
[413]The authors also acknowledge the extensive assistance provided in the design stage of this specification by David Solo (CitiGroup) and Barbara Fox (Microsoft), and the contributions of (by alphabetical order) Dr. Paul Boisen (NSA), Alex Deacon, Dan Guinan, Marc Hayes, Jeremy Epstein (webMethods), Andrew Layman (Microsoft), Mingliang Pei (VeriSign).
[414]The people who have contributed to discussions on<EMAIL_ADDRESS>are also gratefully acknowledged.
This appendix documents changes (other than very minor editorial changes) from the Proposed Recommendation of 2 May 2005 that were made to accommodate the comments. Each entry contains:
None.


|
Class Summary |
| AlternativeCarrierRecord |
Alternative Carrier Record. |
| CollisionResolutionRecord |
Collision Resolution Record. |
| ErrorRecord |
Error record. |
| HandoverCarrierRecord |
Handover Carrier Record
The Handover Carrier Record provides a unique identification of an alternative carrier technology in Handover Request
messages when no carrier configuration data is to be provided. |
| HandoverRequestRecord |
Handover Request Record
The Handover Request Record identifies a list of possible alternative carriers that the Handover Requester device
would be able to use for further communication with the Handover Selector. |
| HandoverSelectRecord |
Handover Select Record
The Handover Select Record identifies the alternative carriers that the Handover Selector device selected from the
list provided within the previous Handover Request Message. |


CJP says suo motu notices not a solution
by Staff ReportLAHORE: Chief Justice of Pakistan (CJP) Asif Saeed Khosa on Saturday said the court won’t have to interfere in other institutions’ domain if everyone was working efficiently, downplaying the need for court intervention in public domain.
Addressing a ceremony, he said: “Whenever a matter captures the public’s attention, people expect a suo motu notice.” However, there won’t be a need for these notices if the government institutions were active beforehand, he added.
He said respect must be given to those who appear in the courts, but summoning senior officials to courts was not a good practice. He said we must ensure that courts were providing justice to the public.
He said a matter comes to SC after investigation and trial. “One should maintain the dignity of a police official or any other person who appears before the court,” he said.
The CJP said retired police officers played an important role in the reforms committee, adding that a lawyer and as judge he had a pleasant relation with police. He said model courts have brought revolution in the judicial history of Pakistan.
Earlier, the CJP chaired the session of Police Reforms Committee (PRC) – which was constituted in January to table recommendations for improvements in the policing system of the country – to examine progress achieved in reforms in the police department.
The session was attended by inspector generals of four provinces, Gilgit Baltistan and Islamabad.


WASD, dpad or first stick to move. X, space or button 3 to shoot. shift or button 4 + left or right to dodge.
Your nest has been defiled.


Click individual lots to select or unselect, or use the drawing tools to select a custom polygon.
The geometries and attributes used in this tool come from MapPLUTO 16v2, an open data set available for download from the Department of City Planning's Bytes of the Big Apple.


PropertiesPicoContainer is a special type of PicoContainer that is populated from the entries in a properties file.
Here is an example of how to use PropertiesPicoContainer to
map properties as configuration for a component, with parameter
names as the bindings.
Consider this component:
public class BigFatComponent { URL spellWebService; int timeout; public BigFatComponent(String spellingWebServiceURL, int timeout) throws MalformedURLExeption { this.spellWebService = new URL(spellingWebServiceURL); this.timeout = timeout; } public String toString() { return "URL=" + spellWebService + ", timeout=" + timeout; } // other methods }
For automatic binding of properties to parameter names of the component:
Properties defaultProperties = new Properties(); defaultProperties.load("my-application.properties"); // default properties are taken from here PicoContainer propsContainer = new PropertiesPicoContainer(defaultProperties); MutablePicoContainer mpc = new DefaultPicoContainer(propsContainer); mpc.as(Characteristics.USE_NAMES).addComponent(BigFatComponent.class);
Here is another manual use forcing an association between a item in the properties file, and the relative position of a parameter in the constructor. It is most useful when there is not a tie-up between the parameter names and the properties. In this case the arg passed in to the ConfigParameter (varargs list) is the one that matches the property name:
mpc.addComponent(BigFatComponent.class, ConfigParameter("wsURL"), ConfigParameter("serviceTimeout"));
Type conversion is automatic in many cases. Properties in a properties file are clearly strings. Parameters can be any of:
PropertiesPicoContainer can be part of a tree of containers. It makes sense, of course, being more near the root of that tree.


Vacations
jQuery Travels - Vacation Confirmation
Confirmations
Hawaiian Vacation
Paid 399.99 on January 14, 2013.
FLIGHT DETAILS
계정생성일:
추종자:
서식지:
깃허브 주소:
View Boarding Pass
Call us at 555-25937 to make a reservation today!


Eight NFL teams watch Colin Kaepernick's workout
by The Atlanta Journal-ConstitutionATLANTA - Just 20 minutes before Colin Kaepernick’s workout was to start at the Falcons’ facilities in Flowery Branch Saturday, it was moved from to Charles Drew High School in Riverdale by the player’s representatives.
Kaepernick’s representatives had issues with the NFL-arranged workout, the media availability and the conditional insurance claims.
Kaepernick threw passes for about 40 minutes at the new site, then signed autographs for hundreds of fans who gathered in an end zone to watch.
Eight team representatives made it to the new location, including Philadelphia Eagles vice president of football operations Andrew Berry. It appeared the Jets, Redskins and Chiefs also had someone in attendance.
They stood along the sideline, jotting into their notepads as Kaepernick tossed passes.
“Our biggest thing with everything today was to make sure we had transparency in what went on,” Kaepernick said afterward. ‘We weren’t getting that elsewhere, so we came out here.”
Kaepernick threw passes to free agent receivers Bruce Ellington, Brice Butler, Jordan Veasy and Ari Werts.
Kaepernick, who worked out in a tank top and shorts, has clearly kept himself in good shape during his near three-year layoff. His passes had zip on them, though he was a bit off target on his deep throws.
“I’ve been ready for three years,” Kaepernick said. “I’ve been denied for three years. We all know why.  We have nothing to hide. We’re waiting for the 32 owners, the 32 teams, (Commissioner) Roger Goodell to stop running, to stop running from the truth, to stop running from the people.”
One team official said that Kaepernick’s representatives wanted to film the workout and distribute the film because they didn’t trust NFL films producing the video.
Also, the Kaepernick representatives allegedly wanted to take the narrative from the NFL because the workout was arranged on such short notice and had the tenor of a publicity stunt.
In a statement, the NFL said it was “disappointed that Colin did not appear for his workout. ... Colin's decision has no effect on his status in the league. He remains an unrestricted free agent eligible to sign with any club,” the NFL said.
The 32-year-old Kaepernick hasn't played since the 2016 season with the San Francisco 49ers. He helped start a wave of protests about social and racial injustice that season by kneeling during the national anthem at games.
Kaepernick’s agent, Jeff Nalley, didn’t sound hopeful after the workouts.
“If teams want to see him, they will ask to work him out,” he said. “No team asked for this workout.”
D. Orlando Ledbetter, with The Atlanta Journal-Constitution, contributed to this article.
TRENDING NOW:
- Roberto Clemente's wife, Vera, dies at 78
- Timeline of Bethel Park woman's disappearance, man's alleged confession of her murder
- Primanti’s offers Maurkice Pouncey a job on Twitter, Pouncey responds
- VIDEO: Man, young boy shot at New Jersey high school football game
- DOWNLOAD the Channel 11 News app for breaking news alerts
© 2019 Cox Media Group.


Neighbors¶
Neighbor calculation functions for lexlib.
-
lexlib.neighbors.
check_neighbors
(a, b, sep=None)[source]¶ Determine whether two words are neighbors. Returns True if they are neighbors and False if they are not.
sep – String used to separate phonemes (if the words are phonological forms). To separate into individual characters, set to None (default).
-
lexlib.neighbors.
get_neighbor_dict
(words, **kwargs)[source]¶ Compare each word in a list of words to each word in a corpus word list (or in the same list if corpus is not given), and return a dict where each target word is a key, and its value is a list of its neighbors. (If you are looking for a function to get neighbor pairs, see get_neighbor_pairs()).
- keyword arguments:
corpus – List of all the words to get the neighbors from. If empty, defaults to words.
sep – String used to separate phonemes (if the words are phonological forms). To separate into individual characters, set to None (default).
debug – If True, it prints the current word and the words being compared to it to the console. Defaults to False.
-
lexlib.neighbors.
get_neighbor_pairs
(words, **kwargs)[source]¶ Compare each word in a list of words to each word in a corpus word list (or in the same list if corpus is not given), and return a list of (word, neighbor) pairs. (If you are looking for a function to get lists of all the neighbors for specific words, see get_neighbor_pairs()).
- keyword arguments:
corpus – List of all the words to get the neighbors from. If omitted, defaults to words.
sep – String used to separate phonemes (if the words are phonological forms). To separate into individual characters, set to None (default).
debug – If True, it logs the current word and the words being compared to it to the console. Defaults to False.
-
lexlib.neighbors.
get_neighbor_positions
(neighbor_pairs, sep=None)[source]¶ Given a list of (word1, word2) neighbor_pairs, return a list of (word1, word2, position) triples, where position is the position in the words where the neighbor relationship is formed. Note that this can only be calculated for pairs of substitution neighbors. If the words differ in length, position will be -1.
Example:
>>> neighbor_pairs = [("cat", "cap"), ("cat", "cut"), ("cat", "cast")] >>> get_neighbor_positions(neighbor_pairs) [("cat", "cap", 3), ("cat", "cut", 2), ("cat", "cast", -1)]
-
lexlib.neighbors.
get_neighbor_types
(neighbor_dict, sep=None)[source]¶ Given a neighbor_dict (where a key is a “target” word and its value is a list of all of its neighbors), return a list of (word1, word2, relationship) triples, where relationship is one of “deletion,” “addition,” “substitution,” or “unknown”.


Whether you are a senior that needs a helping hand moving from the old family home or whether you have a family or work full time and are finding your move too overwhelming, then Transition Angels are your experienced and trustworthy solution – from helping you get your home ready for sale, to settling into your new home and everything in between.
We are specialists at co-ordinating and transitioning our clients from the old home into their new home, offering practical help, advice and understanding to make it the smoothest of transitions.
FROM THE FOUNDER
I know most people consider moving, up there with one of the most stressful things we have to do. Our goal is to take the pain out of the moving process by utilising the planning, skill and experience of our hand picked team.
I personally get a buzz when we see our clients settled into their new home at the end of moving day with everything in place, no boxes left around with beds made, leaving them with smiles on their faces. Our aim to have it looking like they’ve been there for 6 months.
-
Hallelujah for the Transition Angels!
What an efficient, worry free and friendly service — all the packing and unpacking done for you; all safely wrapped in tons of packing and handled with ‘hands of care’.
Thank you from a relieved, grateful and satisfied customerHeather McLennan — Kincumber
-
I was completely ‘stressed out’ at the thought of moving. After you explained what and how you were going to do, my stress level dropped. I then realised that ‘Transition Angels’ really had a live Angel running the business.
I watched as you carefully wrapped and packed my precious belongings and furniture. You efficiently organised the transfer of all the services at both properties and transported the furniture to my new address where everything was unpacked and placed in its correct position.
Finally, you cleaned and left my old home in immaculate condition and ready for the estate agents to show their first clients.
I’ve made several moves in my lifetime, but this is the first time that I have experienced a completely stress free move and the kindness and consideration given to me.Thank you so much Angels.
Richard — Booker Bay
-
Just wanted to tell you how grateful we are to you and your team for the help given during our move.
We were overwhelmed by the care and support given both during the packing, transporting and the unpacking.
When it came to the unpacking not only were you very careful with all our precious possessions but the attention you took in the placement of the furniture was incredible. (even though we were known to change the placement many times, still smiling you did as requested).
We would highly recommend you and your team to anyone wanting a carefree move.Lorraine and Les Brady — Brentwood Village
SERVICES
We break down the transition process into easy stages:
- decluttering
- packing
- coordination of removalist
- cleaning
- unpacking and set up
We also have an eye for details reminding you of those easily overlooked tasks like transferring the utilities accounts, redirecting mail, handing over keys and many more useful tips.
CONTACT US
Get in touch with us today to discuss your project requirments!