text:
Strategy & Impact
Reporting & Transparency
– Impact Map
Residential Contractors
Capital Providers
Canton Hydroelectric Facility to Produce Clean Energy for Connecticut
Posted on July 8, 2019 August 23, 2019 by Rudy Sturk
Historic powerhouse will produce 1 MW of renewable, clean energy and provide many benefits to the Town of Canton, the people of Connecticut, and the environment
Rocky Hill, Conn. (July 8, 2019) – The construction of a 1 megawatt (MW) hydroelectric facility at the Upper Collinsville Dam on the Farmington River in Canton is resuming after the closing of the construction loans, according to the project's developer, Canton Hydro, LLC. The project is the result of significant expertise and innovation from many stakeholders, including the Town of Canton, The Provident Bank, the Department of Energy and Environmental Protection (DEEP), and the Connecticut Green Bank. Once operational, the facility is projected to generate an average 4.3 million kWh of clean energy and save 3.2 metric tons of CO2 emissions annually, while preserving a historic powerhouse, enhancing public safety features, and revitalizing aquatic habitat by allowing fish to swim upstream for spawning for the first time since 1867.
"Hydro projects like this one in Canton are very exciting for Connecticut," said Bryan Garcia, President and CEO of the Connecticut Green Bank. "Although these projects require significant work and coordination, they provide a great example of how the Green Bank's public-private partnership model works to leverage capital, revitalize Connecticut's environmental infrastructure, and produce clean energy for years to come."
This project is the culmination of more than a decade of efforts, including the drafting of the Collinsville Renewable Energy Promotion Act (H.R. 316; Pub.L. 113–122), a U.S. public law that was introduced into the 113th United States Congress, which was signed into law by President Barack Obama on June 30, 2014. The bill allowed the Town to take over the lapsed Federal Energy Regulatory Commission (FERC) licenses to refurbish two old dams. Originally constructed for hydropower that generated electricity for the former Collins Company factory, the site ceased generation in 1966. After a pre-feasibility study concluded the site could again support hydroelectric, the Town of Canton selected Canton Hydro through a competitive request for proposals.
"In addition to the generation of clean energy and reduction of carbon emissions, this hydro project will provide long-term benefits to Canton residents, the state, the environment and the wildlife," said Canton First Selectman Beth Kandrysawtz. "Some of the other positive outcomes will be the construction of an upstream fish and eel passage, enhanced recreational possibilities due to the increased water level in the upper impoundment area, the improvement of flood control, and the creation of jobs. Not to mention the preservation of the historic powerhouse which was built in the 1930s."
Clean Energy Through Creative Financing
The final requirement for the project was securing financing, which was accomplished through a creative partnership structure. The total project cost is approximately $6.6 million with the Green Bank providing a $1.2 million subordinate loan and $500,000 limited guaranty to leverage an approximately $4.7 million senior loan from The Provident Bank through the U.S. Small Business Administration (SBA) 504 Loan program. Additional equity is being provided by Canton Hydro.
"When a project has this many moving parts — environmental, economic, legislative and so on — it's vital to have a financial partner willing to take a comprehensive approach that benefits both the client and their community," says Dave Mansfield, CEO of The Provident Bank. "The Provident team is powered by innovation and that's why renewable energy lending and the type of creative financing required for something such as the Upper Collinsville Dam, are not only a specialty of ours, but true passion projects."
Redeveloping Historic Hydropower
The dam is owned by the State of Connecticut and the water rights will be leased to Canton Hydro over a 30-year period. Utilizing the state's Virtual Net Metering program, State of Connecticut owned buildings through DEEP will benefit from the lower cost renewable energy.
"This is a terrific project that builds on Connecticut's legacy of leadership in environmental protection and clean energy development," said DEEP Commissioner Katie Dykes. "Working with the Green Bank and local developers across Connecticut, we can improve our historic dams to provide clean energy, while at the same time restoring these facilities that create opportunities for recreation and wildlife conservation, and protecting our precious water resources. The process and documentation established with this project will serve as a replicable model that can be used with other state buildings that could benefit from clean energy technologies."
The project will use a Kaplan turbine manufactured by WWS Wasserkraft GmbH, an Austrian company with longstanding experience in the construction of high-performance hydroelectric plants smaller than 10 MW per unit. In addition to supplying the main equipment, Wasserkraft will act as the turnkey solution provider and will supervise construction. A Denil Fishway passage to support the migration of fish into the Farmington River will be installed along with a new low-level fish guidance barrier to prevent fish swimming towards the primary spillway and guide them directly to the entrance of the upstream fish passage.
"This project is a truly innovative approach to the redevelopment of a hydropower plant in Connecticut," said Mariana Cardenas Trief, clean energy finance consultant to the Green Bank. "The capital stack displays a creative blend of public funding, from sources like the Green Bank and the SBA 504 Loan program, and private investment from Provident."
About Canton Hydro LLC
Canton Hydro was established in 2015 for the purposed of the redevelopment of the Upper Collinsville Hydro facility by a group of architects, engineers and investors passionate about revitalizing hydro power assets and preserving historic structures while improving the aquatic habitat. For more information, please visit www.cantonhydro.com.
About The Provident Bank
The Provident Bank, a subsidiary of Provident Bancorp, Inc. (NASDAQ: PVBC), is an innovative, commercial bank that finds solutions for our business and private clients. We are committed to strengthening the economic development of the regions we serve, by working closely with businesses and private clients and delivering superior products and high-touch services to meet their banking needs. The Provident has offices in Massachusetts and New Hampshire. All deposits are insured in full through a combination of insurance provided by the Federal Deposit Insurance Corporation (FDIC) and the Depositors Insurance Fund (DIF).
Posted in Activation, financing, Innovation, News
The Connecticut Green Bank is the nation's first green bank. We're creating a thriving marketplace to accelerate green energy adoption in Connecticut by making green energy financing accessible and affordable for homeowners, businesses and institutions.
© 2020 CT Green Bank. All Rights Reserved.
Home · Contact


Triond, a privately held company, launched its web publishing service and announced it secured $1.5M in funding from Giza Venture Capital. With Triond, users can submit original content, including written articles and photographs for publication on relevant sites within Triond's content network. With Triond's revenue-generation model, every user earns 50% of the advertising revenue generated from their content. Triond's publishing network covers topics including sports, business, humor, literature, health,and wellness, and science. Users can track their statistics including article views, comments, and earnings in their Triond account. Additionally, every user has a customizable Triond profile page, which shows every published item and links to its location.


My head is full of children.
I've heard hundreds of their voices this week. Brilliant, sincere, thoughtful voices. Bland, benighted, sarcastic voices. They were all there at this year's AP Reading.
The best way I can think to describe this experience is that while in my classroom I am tuned to the frequency of my own students, at the AP Reading the dial's needle spread to capture every frequency. Thousands of voices broadcast their claims to the vast listening audience: a few trembled with conviction, some held forth with prosaic observations, and many lay limp with vapid utterances. But they were all "somebody's precious little angel," as another Reader at my table often reminded us.
And then there were the Readers themselves. (Yes, the word is capitalized, thank you very much.) We were from all over the country, men and women ranging from their mid-twenties to their late-seventies, from inner-city high schools to Ivy League universities, some in jeans and T-shirts and some in hajibs, some naïve and some jaded, but all of us shivering in the air conditioning and trying to remember that to every one of these young writers, their ideas were fresh and original, even if we'd seen the same lines of reasoning all week: polite speech makes people comfortable and is therefore good; polite speech is fake and is therefore bad.
My head is also full of teachers. As an extrovert, I love meeting new people, but even I have my limits.
Let's talk scale here. First, in addition to the Lang. and Comp. folks, hundreds of other Readers were in the same building scoring exams in other subjects. (In Louisville and Cincinnati, there were thousands more.) It's amazing how the College Board pulls this off every year, with all exams still scored by humans—not artificial intelligence—and all of us in one room.
And it's amazing how the Kansas City Convention Center can accommodate all these humans. The room we were in—just that one room—was the size of eight football fields. (When's the last time you were in a room that required motorized transport?) Each of the three essays had about 500 readers devoted to it, in areas demarcated with curtained dividers. To hear the directions of the Chief Reader, we wore headsets.
A funny remark would elicit a roar of laughter that boomed toward the 42-foot ceiling, thundering like the shouts of the elves in The Polar Express when Santa gives the first gift of Christmas. On the first morning, while we were quietly receiving instructions, I heard the sound of metal screeching and juddering nearby. It sounded like a bunch of people were shoving a train across the concrete floor. No one at my table took any notice of it. Finally, seeing my confusion, an experienced Reader whispered, "That's another group getting up for a break." That screeching and juddering was the sound of 500 chairs being pushed back all at once in the next area.
Then there was the food, located on another planet downstairs—nearly a ten-minute walk—in the banquet hall: 24 buffet lines, 12 salad bar lines, several tables of desserts and drinks, and 16 massive coffee urns, always pumping.
But this extraordinary scale wasn't confined to the workday. There were teachers everywhere in downtown KC, between the convention center and the nearby hotels. On "eat-out night," when we were all given a break from the cavernous banquet hall, teachers completely filled the restaurants near Union Station. At the Green Lady Lounge, a wonderful jazz venue (a bar with no TVs!), the waitress, after taking our orders, asked, "What subject are you reading?" I even spotted several Readers at the Royals game, amid a crowd of some 33,000.
One evening, after several of us had half-filled an elevator in the hotel lobby, the elevator stopped at the fifth floor and a boy about nine years old, wet from the pool, began to step in. He took one wide-eyed look at us and said, "I'll wait for the next one." We roared.
I felt like a hayseed who'd had her first taste of the big city, but instead of craning my neck to see how high the skyscrapers were, I was craning my neck to see the people who fill my particular teaching niche. I wish I could have met more of those teachers—my tribe, those exhausted, caring people in sensible shoes.
And I wish I could meet some of the kids whose voices I still hear in my head. I want to meet the girl who says her polite speech is not fake because she really does want to spread love and good will. I want to meet the kid who says polite speech is the work of Satan. I want to meet the kid who, instead of writing essay #3, wrote the word REGRET in large block letters and filled the page with line drawings. I want to meet the kid who says it's just not nice to call someone a cottonheadedninimuggins.


text:
Versions: (draft-barnes-acme)  00 01 02 03 04 05
Network Working Group                                          R. Barnes
Internet-Draft                                                   Mozilla
Expires: September 22, 2016                                          EFF
Certificates in the Web's X.509 PKI (PKIX) are used for a number of
purposes, the most significant of which is the authentication of
domain names.  Thus, certificate authorities in the Web PKI are
trusted to verify that an applicant for a certificate legitimately
represents the domain name(s) in the certificate.  Today, this
verification is done through a collection of ad hoc mechanisms.  This
document describes a protocol that a certificate authority (CA) and
an applicant can use to automate the process of verification and
DISCLAIMER: This is a work in progress draft of ACME and has not yet
had a thorough security analysis.
submitted as pull requests at https://github.com/ietf-wg-acme/acme .
Instructions are on that page as well.  Editorial changes can be
managed in GitHub, but any substantive change should be discussed on
the ACME mailing list (acme@ietf.org).
Barnes, et al.         Expires September 22, 2016               [Page 1]
Internet-Draft                    ACME                        March 2016
This Internet-Draft will expire on September 22, 2016.
5.  Message Transport . . . . . . . . . . . . . . . . . . . . . .   9
5.1.  HTTPS Requests  . . . . . . . . . . . . . . . . . . . . .   9
5.2.  Request Authentication  . . . . . . . . . . . . . . . . .   9
5.3.  Request URI Type Integrity  . . . . . . . . . . . . . . .  10
5.4.1.  Replay-Nonce  . . . . . . . . . . . . . . . . . . . .  12
5.5.  Errors  . . . . . . . . . . . . . . . . . . . . . . . . .  12
6.  Certificate Management  . . . . . . . . . . . . . . . . . . .  14
6.1.1.  Registration Objects  . . . . . . . . . . . . . . . .  16
6.1.2.  Authorization Objects . . . . . . . . . . . . . . . .  17
6.2.  Directory . . . . . . . . . . . . . . . . . . . . . . . .  18
6.3.  Registration  . . . . . . . . . . . . . . . . . . . . . .  20
6.3.1.  Account Key Roll-over . . . . . . . . . . . . . . . .  22
6.3.2.  Deleting an Account . . . . . . . . . . . . . . . . .  23
6.4.  Identifier Authorization  . . . . . . . . . . . . . . . .  24
6.4.1.  Responding to Challenges  . . . . . . . . . . . . . .  26
6.4.2.  Deleting an Authorization . . . . . . . . . . . . . .  28
6.5.  Certificate Issuance  . . . . . . . . . . . . . . . . . .  29
6.6.  Certificate Revocation  . . . . . . . . . . . . . . . . .  32
7.  Identifier Validation Challenges  . . . . . . . . . . . . . .  33
7.1.  Key Authorizations  . . . . . . . . . . . . . . . . . . .  35
7.2.  HTTP  . . . . . . . . . . . . . . . . . . . . . . . . . .  35
7.3.  TLS with Server Name Indication (TLS SNI) . . . . . . . .  38
7.4.  DNS . . . . . . . . . . . . . . . . . . . . . . . . . . .  39
9.  Well-Known URI for the HTTP Challenge . . . . . . . . . . . .  41
9.1.  Replay-Nonce HTTP Header  . . . . . . . . . . . . . . . .  41
9.2.  "nonce" JWS Header Parameter  . . . . . . . . . . . . . .  41
9.3.  URN Sub-namespace for ACME (urn:ietf:params:acme) . . . .  42
9.4.  New Registries  . . . . . . . . . . . . . . . . . . . . .  42
9.4.1.  Error Codes . . . . . . . . . . . . . . . . . . . . .  42
9.4.2.  Identifier Types  . . . . . . . . . . . . . . . . . .  43
9.4.3.  Challenge Types . . . . . . . . . . . . . . . . . . .  43
10. Security Considerations . . . . . . . . . . . . . . . . . . .  44
10.1.  Threat model . . . . . . . . . . . . . . . . . . . . . .  44
10.2.  Integrity of Authorizations  . . . . . . . . . . . . . .  45
10.3.  Denial-of-Service Considerations . . . . . . . . . . . .  48
10.4.  CA Policy Considerations . . . . . . . . . . . . . . . .  49
11. Operational Considerations  . . . . . . . . . . . . . . . . .  49
11.1.  Default Virtual Hosts  . . . . . . . . . . . . . . . . .  49
11.2.  Use of DNSSEC Resolvers  . . . . . . . . . . . . . . . .  50
Certificates in the Web PKI [RFC5280] are most commonly used to
authenticate domain names.  Thus, certificate authorities in the Web
PKI are trusted to verify that an applicant for a certificate
Existing Web PKI certificate authorities tend to run on a set of ad
hoc protocols for certificate issuance and identity verification.  A
typical user experience is something like:
o  Cut-and-paste the CSR into a CA web page.
*  Put a CA-provided challenge at a DNS location corresponding to
*  Receive CA challenge at a (hopefully) administrator-controlled
e-mail address corresponding to the domain and then respond to
it on the CA's web page.
to follow and cause significant confusion.  Informal usability tests
by the authors indicate that webmasters often need 1-3 hours to
obtain and install a certificate for a domain.  Even in the best
case, the lack of published, standardized mechanisms presents an
obstacle to the wide deployment of HTTPS and other PKIX-dependent
systems because it inhibits mechanization of tasks related to
certificate issuance, deployment, and revocation.
and infrastructural software to obtain certificates without user
deployment of HTTPS and the practicality of PKIX authentication for
other protocols based on TLS [RFC5246].
The major guiding use case for ACME is obtaining certificates for Web
sites (HTTPS [RFC2818]).  In that case, the server is intended to
speak for one or more domains, and the process of certificate
issuance is intended to verify that the server actually speaks for
the domain(s).
Validation" (DV) certificates are by far the most common type.  For
DV validation, the CA merely verifies that the requester has
effective control of the web server and/or DNS server for the domain,
but does not explicitly attempt to verify their real-world identity.
(This is as opposed to "Organization Validation" (OV) and "Extended
Validation" (EV) certificates, where the process is intended to also
verify the real-world identity of the requester.)
by the issuing authority in an interactive process that can be
When deploying a current HTTPS server, an operator generally gets a
prompt to generate a self-signed certificate.  When an operator
deploys an ACME-compatible web server, the experience would be
o  The ACME client prompts the operator for the intended domain
name(s) that the web server is to stand for.
that a certificate be issued for the intended domain name(s).
o  Once the CA is satisfied, the certificate is issued and the ACME
notifying the operator via e-mail, SMS, etc.
required to keep the server functional and its credentials up-to-
date.
The overall idea is that it's nearly as easy to deploy with a CA-
issued certificate as a self-signed certificate, and that once the
operator has done so, the process is self-sustaining with minimal
manual intervention.  Close integration of ACME with HTTPS servers,
for example, can allow the immediate and automated deployment of
certificates as they are issued, optionally sparing the human
administrator from additional configuration work.
such as issuance or revocation.  An ACME client therefore typically
runs on a web server, mail server, or some other server system which
requires valid TLS certificates.  The ACME server runs at a
certificate authority, and responds to client requests, performing
the requested actions if the client is authorized.
An ACME client is represented by an "account key pair".  The client
uses the private key of this key pair to sign all messages sent to
the server.  The server uses the public key to verify the
authenticity and integrity of messages from the client.
a set of JSON messages carried over HTTPS.  In some ways, ACME
functions much like a traditional CA, in which a user creates an
account, adds identifiers to that account (proving control of the
domains), and requests certificate issuance for those domains while
logged in to the account.
In ACME, the account is represented by an account key pair.  The "add
a domain" function is accomplished by authorizing the key pair for a
given domain.  Certificate issuance and revocation are authorized by
a signature with the key pair.
The first phase of ACME is for the client to register with the ACME
server.  The client generates an asymmetric key pair and associates
this key pair with a set of contact information by signing the
contact information.  The server acknowledges the registration by
replying with a registration object echoing the client's input.
Client                                                  Server
<-------            Registration
Before a client can issue certificates, it must establish an
authorization with the server for an account key pair to act for the
identifier(s) that it wishes to include in the certificate.  To do
this, the client must demonstrate to the server both (1) that it
holds the private key of the account key pair, and (2) that it has
authority over the identifier being claimed.
Proof of possession of the account key is built into the ACME
protocol.  All messages from the client to the server are signed by
the client, and the server verifies them using the public key of the
account key pair.
To verify that the client controls the identifier being claimed, the
server issues the client a set of challenges.  Because there are many
different ways to validate possession of different types of
identifiers, the server will choose from an extensible set of
challenges that are appropriate for the identifier being claimed.
The client responds with a set of responses that tell the server
which challenges the client has completed.  The server then validates
the challenges to check that the client has accomplished the
challenge.
For example, if the client requests a domain name, the server might
challenge the client to provision a record in the DNS under that
name, or to provision a file on a web server referenced by an A or
AAAA record under that name.  The server would then query the DNS for
the record in question, or send an HTTP request for the file.  If the
client provisioned the DNS or the web server as expected, then the
server considers the client authorized for the domain name.
<-------              Challenges
<-------       Updated Challenge
Poll                          ------->
<-------           Authorization
Once the client has authorized an account key pair for an identifier,
it can use the key pair to authorize the issuance of certificates for
the identifier.  To do this, the client sends a PKCS#10 Certificate
Signing Request (CSR) to the server (indicating the identifier(s) to
be included in the issued certificate) and a signature over the CSR
by the private key of the account key pair.
Note that as a result, the CSR is signed twice: One by the private
key corresponding to the public key in the CSR, and once by the
private key of the account key pair.  The former signature indicates
that the holder of the key in the CSR is willing to act for the
indicated identifiers, and the latter signature indicates to the
server that the issuance of the certificate is authorized by the
client (i.e., the domain holder).
If the server agrees to issue the certificate, then it creates the
certificate and provides it in its response.  The certificate is
assigned a URI, which the client can use to fetch updated versions of
<--------            Certificate
To revoke a certificate, the client simply sends a revocation request
indicating the certificate to be revoked, signed with an authorized
key pair.  The server indicates whether the request has succeeded.
Revocation request
names.  The use of ACME for other protocols will require further
specification, in order to describe how these identifiers are encoded
in the protocol, and what types of validation challenges the server
ACME uses a combination of HTTPS and JWS to create a messaging layer
with a few important security properties.
over HTTPS, using JWS to provide som additional security properties
for messages sent from the client to the server.  HTTPS provides
server authentication and confidentiality.  With some ACME-specific
extensions, JWS provides authentication of the client's request
payloads, anti-replay protection, and a degree of integrity for the
HTTPS request URI.
[RFC2818][RFC7159].  Use of HTTPS is REQUIRED.  Clients SHOULD
support HTTP public key pinning [RFC7469], and servers SHOULD emit
pinning headers.  Each subsection of Section 6 below describes the
message formats used by the function, and the order in which messages
are sent.
In all HTTPS transactions used by ACME, the ACME client is the HTTPS
client and the ACME server is the HTTPS server.
browser-based clients [W3C.CR-cors-20130129].  Such servers SHOULD
base64url encoding described in [RFC4648] Section 5, according to the
profile specified in JSON Web Signature [RFC7515] Section 2.  This
be stripped.
All ACME requests with a non-empty body MUST encapsulate the body in
a JWS object, signed using the account key pair.  The server MUST
verify the JWS before processing the request.  (For readability,
however, the examples below omit this encapsulation.)  Encapsulating
request bodies in JWS provides a simple authentication of requests by
way of key continuity.
o  The JWS MUST use the Flattened JSON Serialization
o  The JWS MUST be encoded using UTF-8
o  The JWS Header or Protected Header MUST include "alg" and "jwk"
o  The JWS MUST NOT have the value "none" in its "alg" field
o  The JWS Protected Header MUST include the "nonce" field (defined
below)
Note that this implies that GET requests are not authenticated.
Servers MUST NOT respond to GET requests for resources that might be
considered sensitive.
5.3.  Request URI Type Integrity
It is common in deployment the entity terminating TLS for HTTPS to be
different from the entity operating the logical HTTPS server, with a
"request routing" layer in the middle.  For example, an ACME CA might
have a content delivery network terminate TLS connections from
clients so that it can inspect client requests for denial-of-service
not signed in the HTTPS request, e.g., the request URI and headers.
ACME uses JWS to provides a limited integrity mechanism, which
protects against an intermediary changing the request URI to anothe
ACME URI of a different type.  (It does not protect against changing
between URIs of the same type, e.g., from one authorization URI to
another).
An ACME request carries a JSON dictionary that provides the details
of the client's request to the server.  Each request object MUST have
a "resource" field that indicates what type of resource the request
is addressed to, as defined in the below table:
Barnes, et al.         Expires September 22, 2016              [Page 10]
+--------------------+------------------+
| Resource type      | "resource" value |
| New registration   | new-reg          |
|                    |                  |
| New authorization  | new-authz        |
| New certificate    | new-cert         |
| Revoke certificate | revoke-cert      |
| Registration       | reg              |
| Authorization      | authz            |
| Challenge          | challenge        |
| Certificate        | cert             |
Other fields in ACME request bodies are described below.
ACME requests have a mandatory anti-replay mechanism.  This mechanism
is based on the server maintaining a list of nonces that it has
issued to clients, and requiring any signed request from the client
to carry such a nonce.
An ACME server MUST include a Replay-Nonce header field in each
successful response it provides to a client, with contents as
specified below.  In particular, the ACME server MUST provide a
Replay-Nonce header field in response to a HEAD request for any valid
resource.  (This allows clients to easily obtain a fresh nonce.)  It
MAY also provide nonces in error responses.
header, the "nonce" header parameter, with contents as defined below.
As part of JWS verification, the ACME server MUST verify that the
value of the "nonce" header is a value that the server previously
provided in a Replay-Nonce header field.  Once a nonce value has
appeared in an ACME request, the server MUST consider it invalid, in
the same way as a value it had never issued.
unacceptable (or not present), it SHOULD provide HTTP status code 400
(Bad Request), and indicate the ACME error code
"urn:ietf:params:acme:error:badNonce".
client requests.  The server should generate the value provided in
high probability.
according to the base64url encoding described in Section 2 of
[RFC7515].  Clients MUST ignore invalid Replay-Nonce values.
base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
Replay-Nonce = *base64url
encoded according to the base64url encoding described in Section 2 of
Errors can be reported in ACME both at the HTTP layer and within ACME
payloads.  ACME servers can return responses with an HTTP error
response code (4XX or 5XX).  For example: If the client submits a
request using a method not allowed in this document, then the server
MAY return status code 405 (Method Not Allowed).
additional information using problem document
[I-D.ietf-appsawg-http-problem].  To facilitate automatic response to
errors, this document defines the following standard tokens for use
in the "type" field (within the "urn:ietf:params:acme:error:"
namespace):
+----------------+--------------------------------------------------+
| Code           | Description                                      |
| badCSR         | The CSR is unacceptable (e.g., due to a short    |
|                | key)                                             |
|                |                                                  |
| badNonce       | The client sent an unacceptable anti-replay      |
|                | nonce                                            |
| connection     | The server could not connect to the client for   |
|                | validation                                       |
| dnssec         | The server could not validate a DNSSEC signed    |
|                | domain                                           |
| malformed      | The request message was malformed                |
| serverInternal | The server experienced an internal error         |
| tls            | The server experienced a TLS error during        |
| unauthorized   | The client lacks sufficient authorization        |
| unknownHost    | The server could not resolve a domain name       |
| rateLimited    | The request exceeds a rate limit                 |
| invalidContact | The provided contact URI for a registration was  |
|                | invalid                                          |
MUST NOT use the ACME URN namespace for errors other than the
standard types.  Clients SHOULD display the "detail" field of such
errors.
Authorization and challenge objects can also contain error
information to indicate why the server was unable to validate
authorization.
o  Account Key Registration
o  Account Key Authorization
o  Certificate Renewal
ACME is structured as a REST application with a few types of
o  Registration resources, representing information about an account
to act for an identifier
an identifier
o  A "directory" resource
o  A "new-registration" resource
o  A "new-authorization" resource
o  A "new-certificate" resource
o  A "revoke-certificate" resource
For the "new-X" resources above, the server MUST have exactly one
resource for each function.  This resource may be addressed by
multiple URIs, but all must provide equivalent functionality.
ACME uses different URIs for different management functions.  Each
function is listed in a directory along with its corresponding URI,
so clients only need to be configured with the directory URI.  These
URIs are connected by a few different link relations [RFC5988].
used from certificate resources to indicate a resource from which the
client may fetch a chain of CA certificates that could be used to
validate the certificate in the original resource.
The "directory" link relation is present on all resources other than
the directory and indicates the directory URL.
an ACME server.  The solid lines indicate link relations, and the
dotted lines correspond to relationships expressed in other ways,
e.g., the Location header in a 201 (Created) response.
....................................................
.                  .                  .            .
V     "next"       V      "next"      V            V
new-reg ---+----> new-authz ---+----> new-cert    revoke-cert
.       |          .        |         .            ^
.       |          .        |         .            | "revoke"
V       |          V        |         V            |
reg* ----+        authz -----+       cert-----------+
. ^                 |
. | "up"            | "up"
V |                 V
challenge         cert-chain
+--------------------+----------------+--------------+
| Action             | Request        | Response     |
| Register           | POST new-reg   | 201 -> reg   |
|                    |                |              |
| Request challenges | POST new-authz | 201 -> authz |
| Answer challenges  | POST challenge | 200          |
| Poll for status    | GET  authz     | 200          |
| Request issuance   | POST new-cert  | 201 -> cert  |
| Check for new cert | GET  cert      | 200          |
6.1.1.  Registration Objects
An ACME registration resource represents a set of metadata associated
to an account key pair.  Registration resources have the following
key (required, dictionary):  The public key of the account key pair,
encoded as a JSON Web Key object [RFC7517].
contact (optional, array of string):  An array of URIs that the
authorization.  For example, the server may wish to notify the
client about server-initiated revocation.
agreement (optional, string):  A URI referring to a subscriber
agreement or terms of service provided by the server (see below).
Including this field indicates the client's agreement with the
referenced terms.
authorizations (required, string):  A URI from which a list of
authorizations granted to this account can be fetched via a GET
request.  The result of the GET request MUST be a JSON object
whose "authorizations" field is an array of strings, where each
string is the URI of an authorization belonging to this
registration.  The server SHOULD include pending authorizations,
and SHOULD NOT include authorizations that are invalid or expired.
The server MAY return an incomplete list, along with a Link header
with link relation "next" indicating a URL to retrieve further
entries.
certificates (required, string):  A URI from which a list of
certificates issued for this account can be fetched via a GET
whose "certificates" field is an array of strings, where each
string is the URI of a certificate.  The server SHOULD NOT include
expired or revoked certificates.  The server MAY return an
incomplete list, along with a Link header with link relation
"next" indicating a URL to retrieve further entries.
"resource": "new-reg",
"tel:+12025551212"
"agreement": "https://example.com/acme/terms",
"authorizations": "https://example.com/acme/reg/1/authz",
"certificates": "https://example.com/acme/reg/1/cert",
An ACME authorization object represents server's authorization for an
account to represent an identifier.  In addition to the identifier,
an authorization includes several metadata fields, such as the status
of the authorization (e.g., "pending", "valid", or "revoked") and
which challenges were used to validate possession of the identifier.
identifier (required, dictionary of string):  The identifier that the
account is authorized to represent
Possible values are: "unknown", "pending", "processing", "valid",
"invalid" and "revoked".  If this field is missing, then the
default value is "pending".
objects with "valid" in the "status field.
challenges (required, array):  The challenges that the client needs
to fulfill in order to prove possession of the identifier (for
pending authorizations).  For final authorizations, the challenges
that were used.  Each array entry is a dictionary with parameters
required to validate the challenge, as specified in Section 7.
combinations (optional, array of arrays of integers):  A collection
of sets of challenges, each of which would be sufficient to prove
possession of the identifier.  Clients complete a set of
challenges that covers at least one set in this array.  Challenges
are identified by their indices in the challenges array.  If no
"combinations" element is included in an authorization object, the
client completes all challenges.
qualified domain name (type: "dns").  The value of the identifier
MUST be the ASCII representation of the domain name.  Wildcard domain
names (with "*" as the first label) MUST NOT be included in
authorization requests.  See Section 6.5 below for more information
about wildcard domains.
"validated": "2014-12-01T12:05:00Z",
"keyAuthorization": "SXQe-2XODaDxNR...vb29HhjjLPSggwiE"
6.2.  Directory
In order to help clients configure themselves with the right URIs for
dictionary, whose keys are the "resource" values listed in
Section 5.1, and whose values are the URIs used to accomplish the
corresponding function.
There is no constraint on the actual URI of the directory except that
it should be different from the other ACME server resources' URIs,
and that it should not clash with other services.  For instance:
o  a host which function as both an ACME and Web server may want to
keep the root path "/" for an HTML "front page", and and place the
ACME directory under path "/acme".
directory under path "/".
The dictionary MAY additionally contain a key "meta".  If present, it
MUST be a JSON dictionary; each item in the dictionary is an item of
The following metadata items are defined, all of which are OPTIONAL:
"terms-of-service" (optional, string):  A URI identifying the current
"website" (optional, string)):  An HTTP or HTTPS URL locating a
website providing more information about the ACME server.
"caa-identities" (optional, array of string):  Each string MUST be a
lowercase hostname which the ACME server recognises as referring
to itself for the purposes of CAA record validation as defined in
[RFC6844].  This allows clients to determine the correct issuer
domain name to use when configuring CAA record.
directory URI.
"new-reg": "https://example.com/acme/new-reg",
"new-authz": "https://example.com/acme/new-authz",
"new-cert": "https://example.com/acme/new-cert",
"revoke-cert": "https://example.com/acme/revoke-cert",
"terms-of-service": "https://example.com/acme/terms",
"caa-identities": ["example.com"]
6.3.  Registration
request to the server's new-registration URI.  The body of the
request is a stub registration object containing only the "contact"
field (along with the required "resource" field).
POST /acme/new-registration HTTP/1.1
/* Signed as JWS */
The server MUST ignore any values provided in the "key",
"authorizations", and "certificates" fields in registration bodies
sent by the client, as well as any other fields that it does not
recognize.  If new fields are specified in the future, the
specification of those fields MUST describe whether they may be
The server creates a registration object with the included contact
information.  The "key" element of the registration is set to the
public key used to verify the JWS (i.e., the "jwk" element of the JWS
header).  The server returns this registration object in a 201
(Created) response, with the registration URI in a Location header
field.  The server SHOULD also indicate its new-authorization URI
using the "next" link relation.
If the server already has a registration object with the provided
account key, then it MUST return a 409 (Conflict) response and
provide the URI of that registration in a Location header field.
This allows a client that has an account key but not the
corresponding registration URI to recover the registration URI.
If the server wishes to present the client with terms under which the
ACME service is to be used, it MUST indicate the URI where such terms
can be accessed in a Link header with link relation "terms-of-
service".  As noted above, the client may indicate its agreement with
these terms by updating its registration to include the "agreement"
field, with the terms URI as its value.  When these terms change in a
way that requires an agreement update, the server MUST use a
different URI in the Link header.
Location: https://example.com/acme/reg/asdf
Link: <https://example.com/acme/new-authz>;rel="next"
Link: <https://example.com/acme/terms>;rel="terms-of-service"
Link: <https://example.com/acme/some-directory>;rel="directory"
"key": { /* JWK from JWS header */ },
sends a POST request with updated information to the registration
URI.  The server MUST ignore any updates to the "key",
"authorizations, or "certificates" fields, and MUST verify that the
request is signed with the private key corresponding to the "key"
field of the request before updating the registration.
For example, to update the contact information in the above
registration, the client could send the following request:
POST /acme/reg/asdf HTTP/1.1
"resource": "reg",
Servers SHOULD NOT respond to GET requests for registration resources
as these requests are not authenticated.  If a client wishes to query
the server for information about its account (e.g., to examine the
"contact" or "certificates" fields), then it SHOULD do so by sending
a POST request with an empty update.  That is, it should send a JWS
whose payload is trivial ({"resource":"reg"}).  In this case the
server reply MUST contain the same link headers sent for a new
registration, to allow a client to retrieve the "new-authorization"
and "terms-of-service" URI
A client may wish to change the public key that is associated with a
registration, e.g., in order to mitigate the risk of key compromise.
To do this, the client first constructs a JSON object representing a
request to update the registration:
resource (required, string):  The string "reg", indicating an update
to the registration.
oldKey (required, string):  The JWK thumbprint of the old key
[RFC7638], base64url-encoded
"oldKey": "D7J9RL1f-RWUl68JP-gW1KSl2TkIrJB7hK6rLFFeYMU"
The client signs this object with the new key pair and encodes the
object and signature as a JWS.  The client then sends this JWS to the
server in the "newKey" field of a request to update the registration.
"newKey": /* JSON object signed as JWS with new key */
/* Signed as JWS with original key */
On receiving a request to the registration URL with the "newKey"
attribute set, the server MUST perform the following steps:
1.  Check that the contents of the "newKey" attribute are a valid JWS
2.  Check that the "newKey" JWS verifies using the key in the "jwk"
header parameter of the JWS
3.  Check that the payload of the JWS is a valid JSON object
4.  Check that the "resource" field of the object has the value "reg"
5.  Check that the "oldKey" field of the object contains the JWK
thumbprint of the account key for this registration
If all of these checks pass, then the server updates the registration
by replacing the old account key with the public key carried in the
"jwk" header parameter of the "newKey" JWS object.
If the update was successful, then the server sends a response with
status code 200 (OK) and the updated registration object as its body.
If the update was not successful, then the server responds with an
error status code and a problem document describing the error.
6.3.2.  Deleting an Account
If a client no longer wishes to have an account key registered with
the server, it may request that the server delete its account by
sending a POST request to the account URI containing the "delete"
delete (required, boolean): The boolean value "true".
The request object MUST contain the "resource" field as required
above (with the value "reg").  It MUST NOT contain any fields besides
"resource" and "delete".
Note that although this object is very simple, the risk of replay or
fraudulent generation via signing oracles is mitigated by the need
for an anti-replay token in the protected header of the JWS.
"delete": true,
On receiving a POST to an account URI containing a "delete" field,
the server MUST verify that no other fields were sent in the object
(other than "resource"), and it MUST verify that the value of the
"delete" field is "true" (as a boolean, not a string).  If either of
these checks fails, then the server MUST reject the request with
status code 400 (Bad Request).
If the server accepts the deletion request, then it MUST delete the
account and all related objects and send a response with a 200 (OK)
status code and an empty body.  The server SHOULD delete any
authorization objects related to the deleted account, since they can
no longer be used.  The server SHOULD NOT delete certificate objects
related to the account, since certificates issued under the account
continue to be valid until they expire or are revoked.
process must assure the server of two things: First, that the client
controls the private key of the account key pair, and second, that
the client holds the identifier in question.  This process may be
repeated to associate multiple identifiers to a key pair (e.g., to
request certificates with multiple identifiers), or to associate
multiple accounts with an identifier (e.g., to allow multiple
entities to manage certificates).
As illustrated by the figure in the overview section above, the
authorization process proceeds in two phases.  The client first
requests a new authorization, and the server issues challenges, then
the client responds to those challenges and the server validates the
client's responses.
To begin the key authorization process, the client sends a POST
request to the server's new-authorization resource.  The body of the
POST request MUST contain a JWS object, whose payload is a partial
authorization object.  This JWS object MUST contain only the
"identifier" field, so that the server knows what identifier is being
authorized.  The server MUST ignore any other fields present in the
client's request object.
The authorization object is implicitly tied to the account key used
to sign the request.  Once created, the authorization may only be
updated by that account.
POST /acme/new-authorization HTTP/1.1
"resource": "new-authz",
Before processing the authorization further, the server SHOULD
authorization object from the initial authorization object submitted
o  "status": MUST be "pending" unless the server has out-of-band
o  "challenges" and "combinations": As selected by the server's
policy for this identifier
The server allocates a new URI for this authorization, and returns a
201 (Created) response, with the authorization URI in a Location
header field, and the JSON authorization object in the body.
Location: https://example.com/authz/asdf
Link: <https://example.com/acme/new-cert>;rel="next"
"uri": "https://example.com/authz/asdf/0",
"combinations": [[0], [1]]
To prove control of the identifer and receive authorization, the
client needs to respond with information to complete the challenges.
To do this, the client updates the authorization object received from
the server by filling in any required information in the elements of
the "challenges" dictionary.  (This is also the stage where the
client should perform any actions required by the challenge.)
The client sends these updates back to the server in the form of a
JSON object with the response fields required by the challenge type,
carried in a POST request to the challenge URI (not authorization URI
or the new-authorization URI).  This allows the client to send
information only for challenges it is responding to.
POST /acme/authz/asdf/0 HTTP/1.1
"resource": "challenge",
"keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE"
representation of the challenge with the response fields provided by
If the client's response is invalid for some reason, or does not
Presumably, the client's responses provide the server with enough
information to validate one or more challenges.  The server is said
to "finalize" the authorization when it has completed all the
validations it is going to complete, and assigns the authorization a
"valid", the server MUST add an "expires" field to the authorization.
When finalizing an authorization, the server MAY remove the
"combinations" field (if present) or remove any challenges still
pending.  The server SHOULD NOT remove challenges with status
"invalid".
To check on the status of an authorization, the client sends a GET
request to the authorization URI, and the server responds with the
current authorization object.  In responding to poll requests while
the validation is still in progress, the server MUST return a 202
(Accepted) response, and MAY include a Retry-After header field to
GET /acme/authz/asdf HTTP/1.1
"type": "http-01"
"token": "IlirfxKKXAsHtmzK29Pj8A",
6.4.2.  Deleting an Authorization
delete the authorization.  The client makes this request by sending a
POST request to the authorization URI containing a payload in the
same format as in Section 6.3.2.  The only difference is that the
value of the "resource" field is "authz".
POST /acme/authz/asdf HTTP/1.1
"resource": "authz",
The server MUST perform the same validity checks as in Section 6.3.2
and reject the request if they fail.  If the server deletes the
account then it MUST send a response with a 200 (OK) status code and
an empty body.
6.5.  Certificate Issuance
The holder of an account key pair authorized for one or more
identifiers may use ACME to request that a certificate be issued for
any subset of those identifiers.  The client makes this request by
sending a POST request to the server's new-certificate resource.  The
body of the POST is a JWS object whose JSON payload contains a
Certificate Signing Request (CSR) [RFC2986].  The CSR encodes the
parameters of the requested certificate; authority to issue is
demonstrated by the JWS signature by an account key, from which the
server can look up related authorizations.  Some attributes which
cannot be reflected in a CSR are placed directly in the certificate
certificate being requested.  The CSR is sent in the Base64url-
encoded version of the DER format.  (Note: This field uses the
same modified Base64 encoding rules used elsewhere in this
document, so it is different from PEM.)
field in the certificate, in the date format defined in [RFC3339]
POST /acme/new-cert HTTP/1.1
Accept: application/pkix-cert
"resource": "new-cert",
"csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P",
"notAfter": "2016-01-08T00:00:00Z"
the certificate to be issued.  The CSR MUST indicate the requested
identifiers, either in the commonName portion of the requested
subject name, or in an extensionRequest attribute [RFC2985]
requesting a subjectAltName extension.
The values provided in the CSR are only a request, and are not
guaranteed.  The server SHOULD return an error if it cannot fulfil
the request as specified, but MAY issue a certificate with contents
other than those requested, according to its local policy (e.g.,
removing identifiers for which the client is not authorized).
It is up to the server's local policy to decide which names are
acceptable in a certificate, given the authorizations that the server
associates with the client's account key.  A server MAY consider a
client authorized for a wildcard domain if it is authorized for the
underlying domain name (without the "*" label).  Servers SHOULD NOT
extend authorization across identifier types.  For example, if a
client is authorized for "example.com", then the server should not
allow the client to issue a certificate with an iPAddress
subjectAltName, even if it contains an IP address to which
example.com resolves.
If the CA decides to issue a certificate, then the server creates a
new certificate resource and returns a URI for it in the Location
header field of a 201 (Created) response.
Location: https://example.com/acme/cert/asdf
If the certificate is available at the time of the response, it is
provided in the body of the response.  If the CA has not yet issued
the certificate, the body of this response will be empty.  The client
should then send a GET request to the certificate URI to poll for the
certificate.  As long as the certificate is unavailable, the server
MUST provide a 202 (Accepted) response and include a Retry-After
header to indicate when the server believes the certificate will be
issued (as in the example above).
GET /acme/cert/asdf HTTP/1.1
HTTP/1.1 202 Accepted
Retry-After: 120
The default format of the certificate is DER (application/pkix-cert).
The client may request other formats by including an Accept header in
its request.
The server provides metadata about the certificate in HTTP headers.
In particular, the server MUST include a Link relation header field
[RFC5988] with relation "up" to provide a certificate under which
this certificate was issued, and one with relation "author" to
indicate the registration under which this certificate was issued.
The server MAY include an Expires header as a hint to the client
about when to renew the certificate.  (Of course, the real expiration
of the certificate is controlled by the notAfter time in the
certificate itself.)
If the CA participates in Certificate Transparency (CT) [RFC6962],
then they may want to provide the client with a Signed Certificate
Timestamp (SCT) that can be used to prove that a certificate was
submitted to a CT log.  An SCT can be included as an extension in the
certificate or as an extension to OCSP responses for the certificate.
The server can also provide the client with direct access to an SCT
for a certificate using a Link relation header field with relation
"ct-sct".
Content-Type: application/pkix-cert
Link: <https://example.com/acme/ca-cert>;rel="up";title="issuer"
Link: <https://example.com/acme/revoke-cert>;rel="revoke"
Link: <https://example.com/acme/reg/asdf>;rel="author"
Link: <https://example.com/acme/sct/asdf>;rel="ct-sct"
Content-Location: https://example.com/acme/cert-seq/12345
[DER-encoded certificate]
A certificate resource always represents the most recent certificate
issued for the name/key binding expressed in the CSR.  If the CA
allows a certificate to be renewed, then it publishes renewed
versions of the certificate through the same certificate URI.
Clients retrieve renewed versions of the certificate using a GET
query to the certificate URI, which the server should then return in
a 200 (OK) response.  The server SHOULD provide a stable URI for each
specific certificate in the Content-Location header field, as shown
above.  Requests to stable certificate URIs MUST always result in the
same certificate.
To avoid unnecessary renewals, the CA may choose not to issue a
renewed certificate until it receives such a request (if it even
allows renewal at all).  In such cases, if the CA requires some time
to generate the new certificate, the CA MUST return a 202 (Accepted)
response, with a Retry-After header field that indicates when the new
certificate will be available.  The CA MAY include the current (non-
renewed) certificate as the body of the response.
Likewise, in order to prevent unnecessary renewal due to queries by
parties other than the account key holder, certificate URIs should be
structured as capability URLs [W3C.WD-capability-urls-20140218].
From the client's perspective, there is no difference between a
certificate URI that allows renewal and one that does not.  If the
client wishes to obtain a renewed certificate, and a GET request to
the certificate URI does not yield one, then the client may initiate
a new-certificate transaction to request one.
request to the ACME server's revoke-cert URI.  The body of the POST
is a JWS object whose JSON payload contains the certificate to be
the base64url-encoded version of the DER format.  (Note: This
field uses the same modified Base64 encoding rules used elsewhere
in this document, so it is different from PEM.)
"resource": "revoke-cert",
"certificate": "MIIEDTCCAvegAwIBAgIRAP8..."
Revocation requests are different from other ACME request in that
the certificate.  Before revoking a certificate, the server MUST
verify that the key used to sign the request is authorized to revoke
the certificate.  The server SHOULD consider at least the following
keys authorized for a given certificate:
o  the public key in the certificate.
o  an account key that is authorized to act for all of the
identifier(s) in the certificate.
(OK).  If the revocation fails, the server returns an error.
"type": "urn:ietf:params:acme:error:unauthorized"
"instance": "http://example.com/doc/unauthorized"
Challenges provide the server with assurance that an account key
holder is also the entity that controls an identifier.  For each type
of challenge, it must be the case that in order for an entity to
validation.  The server presents a set of challenge in the
object in a POST request to a challenge URI.
This section describes an initial set of challenge types.  Each
challenge must describe:
uri (required, string):  The URI to which a response can be posted.
Possible values are: "pending", "valid", and "invalid".  If this
field is missing, then the default value is "pending".
validated (optional, string):  The time at which this challenge was
completed by the server, encoded in the format specified in RFC
3339 [RFC3339].  This field is REQUIRED if the "status" field is
error (optional, dictionary of string):  The error that occurred
while the server was validating the challenge, if any.  This field
is structured as a problem document
[I-D.ietf-appsawg-http-problem].
include the "error" field to help the client diagnose why they failed
the challenge.
and TLS SNI, the client directly proves its ability to do certain
things related to the identifier.  The choice of which challenges to
offer to a client under which circumstances is a matter of server
future to support other types of identifier, there will need to be
[[ Editor's Note: In pre-RFC versions of this specification,
challenges are labeled by type, and with the version of the draft in
which they were introduced.  For example, if an HTTP challenge were
introduced in version -03 and a breaking change made in version -05,
then there would be a challenge labeled "http-03" and one labeled
"http-05" - but not one labeled "http-04", since challenge in version
-04 was compatible with one in version -04. ]]
[[ Editor's Note: Operators SHOULD NOT issue "combinations" arrays in
authorization objects that require the client to perform multiple
challenges over the same type, e.g., ["http-03", "http-05"].
Challenges within a type are testing the same capability of the
domain owner, and it may not be possible to satisfy both at once. ]]
Several of the challenges in this document makes use of a key
authorization string.  A key authorization is a string that expresses
a domain holder's authorization for a specified key to satisfy a
specified challenge, by concatenating the token for the challenge
with a key fingerprint, separated by a "." character:
key-authz = token || '.' || base64url(JWK\_Thumbprint(accountKey))
The "JWK_Thumbprint" step indicates the computation specified in
[RFC7638], using the SHA-256 digest.  As specified in the individual
challenges below, the token for a challenge is a JSON string
comprised entirely of characters in the URL-safe Base64 alphabet.
The "||" operator indicates concatenation of strings.
In computations involving key authorizations, such as the digest
computations required for the DNS and TLS SNI challenges, the key
authorization string MUST be represented in UTF-8 form (or,
equivalently, ASCII).
An example of how to compute a JWK thumbprint can be found in
Section 3.1 of [RFC7638].  Note that some cryptographic libraries
prepend a zero octet to the representation of the RSA public key
parameters N and E, in order to avoid ambiguity with regard to the
sign of the number.  As noted in JWA [RFC7518], a JWK object MUST NOT
include this zero octet.  That is, any initial zero octets MUST be
stripped before the values are base64url-encoded.
7.2.  HTTP
control over a domain name by proving that it can provision resources
on an HTTP server that responds for that domain name.  The ACME
server will connect to at least one of the hosts found in A and AAAA
records.  Because many web servers allocate a default HTTPS virtual
host to a particular low-privilege tenant user in a subtle and non-
intuitive manner, the challenge must be completed over HTTP, not
the challenge.  This value MUST have at least 128 bits of entropy,
in order to prevent an attacker from guessing it.  It MUST NOT
contain any characters outside the URL-safe Base64 alphabet and
MUST NOT contain any padding characters ("=").
"token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA",
A client responds to this challenge by constructing a key
authorization from the "token" value provided in the challenge and
the client's account key.  The client then provisions the key
authorization as a resource on the HTTP server for the domain in
fixed prefix ".well-known/acme-challenge/", followed by the "token"
.well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA
The client's response to this challenge indicates its agreement to
this challenge by sending the server the key authorization covering
the challenge's token and the client's account key.  In addition, the
client MAY advise the server at which IP the challenge is
provisioned.
keyAuthorization (required, string):  The key authorization for this
challenge.  This value MUST match the token from the challenge and
the client's account key.
address (optional, string):  An IPv4 or IPv6 address, in dotted
decimal form or [RFC4291] form, respectively.  If given, this
address MUST be included in the set of IP addresses to which the
domain name resolves when the server attempts validation.  If
given, the server SHOULD connect to that specific IP address
instead of arbitrarily choosing an IP from the set of A and AAAA
records to which the domain name resolves.
"keyAuthorization": "evaGxfADs...62jcerQ"
On receiving a response, the server MUST verify that the key
authorization in the response matches the "token" value in the
challenge and the client's account key.  If they do not match, then
the server MUST return an HTTP error in response to the POST request
in which the client sent the challenge.
1.  Form a URI by populating the URI template [RFC6570]
2.  Verify that the resulting URI is well-formed.
3.  If the client has supplied an address to use, verify that the
address is included in the A or AAAA records to which the domain
name resolves.  If the address is not included in the result, the
validation fails.
4.  Dereference the URI using an HTTP GET request.  If an address was
supplied by the client, use that address to establish the HTTP
5.  Verify that the body of the response is well-formed key
6.  Verify that key authorization provided by the server matches the
token for this challenge and the client's account key.
7.3.  TLS with Server Name Indication (TLS SNI)
The TLS with Server Name Indication (TLS SNI) validation method
proves control over a domain name by requiring the client to
configure a TLS server referenced by an A/AAAA record under the
domain name to respond to specific connection attempts utilizing the
Server Name Indication extension [RFC6066].  The server verifies the
client's challenge by accessing the reconfigured server and verifying
a particular challenge certificate is presented.
type (required, string):  The string "tls-sni-02"
"type": "tls-sni-02",
A client responds to this challenge by constructing a self-signed
certificate which the client MUST provision at the domain name
concerned in order to pass the challenge.
The certificate may be constructed arbitrarily, except that each
certificate MUST have exactly two subjectAlternativeNames, SAN A and
SAN B.  Both MUST be dNSNames.
SAN A MUST be constructed as follows: compute the SHA-256 digest of
the UTF-8-encoded challenge token and encode it in lowercase
hexadecimal form.  The dNSName is "x.y.token.acme.invalid", where x
is the first half of the hexadecimal representation and y is the
second half.
SAN B MUST be constructed as follows: compute the SHA-256 digest of
the UTF-8 encoded key authorization and encode it in lowercase
hexadecimal form.  The dNSName is "x.y.ka.acme.invalid" where x is
the first half of the hexadecimal representation and y is the second
half.
The client MUST ensure that the certificate is served to TLS
connections specifying a Server Name Indication (SNI) value of SAN A.
The response to the TLS-SNI challenge simply acknowledges that the
client is ready to fulfill this challenge.
"keyAuthorization": "evaGxfADs...62jcerQ",
Given a challenge/response pair, the ACME server verifies the
client's control of the domain by verifying that the TLS server was
configured appropriately, using these steps:
1.  Compute SAN A and SAN B in the same way as the client.
2.  Open a TLS connection to the domain name being validated on the
requested port, presenting SAN A in the SNI field.  In the
ClientHello initiating the TLS handshake, the server MUST include
a server_name extension (i.e., SNI) containing SAN A.  The server
SHOULD ensure that it does not reveal SAN B in any way when
making the TLS connection, such that the presentation of SAN B in
the returned certificate proves association with the client.
3.  Verify that the certificate contains a subjectAltName extension
containing dNSName entries of SAN A and SAN B and no other
entries.  The comparison MUST be insensitive to case and ordering
of names.
It is RECOMMENDED that the ACME server validation TLS connections
from multiple vantage points to reduce the risk of DNS hijacking
attacks.
successful.  Otherwise, the validation fails.
7.4.  DNS
prove control of that domain by provisioning a resource record under
it.  The DNS challenge requires the client to provision a TXT record
containing a designated value under a specific validation domain
the client's account key.  The client then computes the SHA-256
digest of the key authorization.
The record provisioned to the DNS is the base64url encoding of this
digest.  The client constructs the validation domain name by
"example.com", then the client would provision the following DNS
_acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"
The response to the DNS challenge provides the computed key
authorization to acknowledge that the client is ready to fulfill this
1.  Compute the SHA-256 digest of the key authorization
2.  Query for TXT records under the validation domain name
3.  Verify that the contents of one of the TXT records matches the
[[ Editor's Note: Should we create a registry for tokens that go into
the various JSON objects used by this protocol, i.e., the field names
in the JSON objects? ]]
9.  Well-Known URI for the HTTP Challenge
| Header Field Name | Protocol | Status | Reference |
+:------------+:------+:------+:-----------+ | Replay-Nonce | http |
standard | Section 5.4.1 |
Index value:  No transformation needed.  The
This document requests that IANA create three new registries:
1.  ACME Error Codes
2.  ACME Identifier Types
3.  ACME Challenge Types
All of these registries should be administered under a Specification
Required policy [RFC5226].
9.4.1.  Error Codes
o  Code: The label to be included in the URN for this error,
following "urn:ietf:params:acme:"
Initial contents: The codes and descriptions in the table in
This registry lists the types of identifiers that ACME clients may
request authorization to issue in certificates.
9.4.3.  Challenge Types
This registry lists the ways that ACME servers can offer to validate
control of an identifier.  The "Identifier Type" field in template
o  Label: The value to be put in the "type" field of challenge
objects using this validation mechanism
o  Identifier Type: The type of identifier that this mechanism
o  Reference: Where the challenge type is defined
+---------+-----------------+-----------+
| Label   | Identifier Type | Reference |
| http    | dns             | RFC XXXX  |
|         |                 |           |
| tls-sni | dns             | RFC XXXX  |
| dns     | dns             | RFC XXXX  |
bindings attested by certificates are correct, and that only
1.  Only an entity that controls an identifier can get an account key
authorized for that identifier
improperly transferred to another account key
an ACME server interacting with other Internet hosts along three
o  A contact channel, over which the ACME server sends messages to
the registered contacts for ACME clients
^                          V
|   Contact Channel  +------------+
+--------------------|    ACME    |
but they are different in most cases.  Each of the three channels,
for example, uses a different communications pattern: the ACME
channel will comprise inbound HTTPS connections to the ACME server,
the validation channel outbound HTTP or DNS requests, and the contact
channel will use channels such as email and PSTN.
(noted below), when an attacker can exploit both the ACME channel and
On the ACME channel, in addition to network-layer attackers, we also
need to account for application-layer man in the middle attacks, and
for abusive use of the protocol itself.  Protection against
application-layer MitM addresses potential attackers such as Content
Distribution Networks (CDNs) and middleboxes with a TLS MitM
function.  Preventing abusive use of ACME means ensuring that an
attacker with access to the validation or contact channels can't
obtain illegitimate authorization by acting as an ACME client
registering an account key and sending a new-authorization request
under that account key.  The integrity of the authorization process
thus depends on the identifier validation challenges to ensure that
the challenge can only be completed by someone who both (1) holds the
private key of the account key pair, and (2) controls the identifier
in question.
to avoid situations where an ACME MitM can switch out a legitimate
domain holder's account key for one of his choosing, e.g.:
o  Legitimate domain holder sends a new-authorization request signed
under account key A
o  MitM suppresses the legitimate request, but sends the same request
signed under account key B
All of the challenges above that require an out-of-band query by the
server have a binding to the account private key, such that only the
account private key holder can successfully respond to the validation
o  HTTP: The value provided in the validation request is signed by
the account private key.
o  TLS SNI: The validation TLS request uses the account key pair as
the server's key pair.
o  DNS: The MAC covers the account key, and the MAC key is derived
from an ECDH public key signed with the account private key.
o  TLS SNI: Configure a TLS server for the domain
by misconfiguration and by attack.  For example, on a web server that
allows non-administrative users to write to .well-known, any user can
claim to own the server's hostname by responding to an HTTP
challenge, and likewise for TLS configuration and TLS SNI.
outside world is concerned, the zone or web site provided by the
redirects in HTTP validation and a web site operator provisions a
to different domain.  Then the target of the redirect could use that
to get a certificate through HTTP validation, since the validation
path will not be known to the primary server.
domain can attack the DNS challenge directly, and can provision false
A/AAAA records to direct the ACME server to send its TLS SNI or HTTP
validation query to a server of the attacker's choosing.  There are a
few different mitigations that ACME servers can apply:
impossible for any attacker on the ACME channel, or a passive
attacker on the validation channel to hijack the authorization
process to authorize a key of the attacker's choice.
hosting providers noted above are a particular case.  For identifiers
where the server already has some public key associated with the
domain this attack can be prevented by requiring the client to prove
control of the corresponding private key.
the rate at which any individual account key can issue certificates,
subtree of the DNS.
o  It is advisable to perform DNS queries via TCP to mitigate DNS
forgery attacks over UDP
[[ TODO: Other operational considerations ]]
11.1.  Default Virtual Hosts
In many cases, TLS-based services are deployed on hosted platforms
that use the Server Name Indication (SNI) TLS extension to
distinguish between different hosted services or "virtual hosts".
When a client initiates a TLS connection with an SNI value indicating
a provisioned host, the hosting platform routes the connection to
that host.
When a connection come in with an unknown SNI value, one might expect
the hosting platform to terminate the TLS connection.  However, some
hosting platforms will choose a virtual host to be the "default", and
route connections with unknown SNI values to that host.
In such cases, the owner of the default virtual host can complete a
TLS-based challenge (e.g., "tls-sni-02") for any domain with an A
record that points to the hosting platform.  This could result in
mis-issuance in cases where there are multiple hosts with different
owners resident on the hosting platform.
A CA that accepts TLS-based proof of domain control should attempt to
check whether a domain is hosted on a domain with a default virtual
host before allowing an authorization request for this host to use a
TLS-based challenge.  A default virtual host can be detected by
initiating TLS connections to the host with random SNI values within
the namespace used for the TLS-based challenge (the "acme.invalid"
namespace for "tls-sni-02").
11.2.  Use of DNSSEC Resolvers
[I-D.ietf-appsawg-http-problem]
mnot, m. and E. Wilde, "Problem Details for HTTP APIs",
draft-ietf-appsawg-http-problem-03 (work in progress),
[RFC2314]  Kaliski, B., "PKCS #10: Certification Request Syntax
Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998,
[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
[RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
[RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
[RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
[W3C.CR-cors-20130129]
Web Consortium CR CR-cors-20130129, January 2013,
<http://www.w3.org/TR/2013/CR-cors-20130129>.
[W3C.WD-capability-urls-20140218]
Tennison, J., "Good Practices for Capability URLs", World
Wide Web Consortium WD WD-capability-urls-20140218,
February 2014,
<http://www.w3.org/TR/2014/WD-capability-urls-20140218>.

redpajama_set_name: RedPajamaCommonCrawl


This lab test measures good cholesterol. The higher the HDL number is the better the chances are for reducing your risk for heart disease.
High density lipoprotein (HDL) is considered good cholesterol. HDL carries excess cholesterol back to the liver so it can be removed. Higher levels of HDL is desired as this may reduce the risk for coronary heart disease. HDL can be raised by eating good fats and doing workouts that raise the heart rate.
High density lipoprotein (HDL) is measured in milligrams per deciliter (mg/dL).
High density lipoprotein (HDL) less than 40 mg/dL is considered low.
High density lipoprotein (HDL) greater than 60 mg/dL is considered high.
HDL less than 40 mg/dL for men and less than 50 mg/dL for women is considered low and a major risk factor for heart disease. HDL greater than 60 mg/dL is considered high and is protective against heart disease.


text:
Horst Gerhard Haberl
Roman Haubenstock-Ramati, Amerika (1962/64), opera, Oper Graz, 1992, photo: Peter Manninger
Générik Vapeur, Bivouac (1988), performance, at Grazer Combustion, corner of Sporgasse and Hofgasse, Graz, 1993, photo: stefanharing.com
Die Sehnsucht der Pinguine—Eine Bilderreise (penguin design © anaplus), poster motif for steirischer herbst '90; photo: courtesy of the artist
Botho Strauß, Angelas Kleider (1991), play, directed by Leander Haußmann, with Götz Argus, Schauspielhaus Graz, 1991, photo: Peter Manninger
Horst Gerhard Haberl, poster for steirischer herbst '94, Erzherzog-Johann-Allee, Graz, 1994, photo: stefanharing.com
Pierre-Alain Hubert and Alfred Pokorny, Die Funken fliegen ("Hôtel des étincelles"), pyrotechnic performance and fireworks, at Grazer Combustion, Kasemattenbühne, Graz, 1993, photo: stefanharing.com
La Fura dels Baus, Noun (1990), performance, Waagner-Biro-Halle, Graz, 1991, photo: stefanharing.com
Claudia Pöllabauer, herbstbar 1 (1995), intervention, Lichtschwert in front of Oper Graz, 1995, photo: steirischer herbst archive / Philipp
MANUELA, evening's dancing, at JE T'AIME. The Love Song, Kammersaal Graz, 1993, photo: steirischer herbst archive
Christoph Schlingensief, Hurra, Jesus! Ein Hochkampf (1995), play, with Joachim Tomaschewsky, Mario Garzaner, and Steffen Höld, Schauspielhaus Graz, 1995, photo: Peter Manninger
Following a battle in Austrian cultural politics over who would succeed Peter Vujica, Horst Gerhard Haberl ultimately prevailed over the artist and media theorist Richard Kriesche. As a member of the Program Advisory Board since 1969, Haberl, like Vujica, had been closely connected with steirischer herbst since its first years. A former employee of Wilfried Skreiner at the Neue Galerie, Haberl had moved to the Graz-based shoe company Humanic in 1969, where he created the innovative advertising slogan "Franz," and was later art director and head of advertising of the company-owned Galerie H.
The same year, Haberl established the interdisciplinary artists' group pool with Richard Kriesche and Karl Neubacher, and, in 1974, the poolerie action space. As a curator, Haberl was responsible for various spectacular steirischer herbst exhibitions that were international and intermedial in their orientation: Körpersprache—Bodylanguage in a tent in the Volksgarten in Graz (1973), Der Amerikanische Video-Underground (The Video Underground in America; part of trigon 73: Audiovisuelle Botschaften [Audiovisual Messages], 1973), Kunst als Lebensritual (Art as a Life Ritual) at the poolerie (1974), and Die Barocken Wilden (The Wild Ones of the Baroque) at the Alte Galerie and Mythen der Zukunft (Myths of the Future) at various locations in Graz (1983).
As the second artistic director, Haberl looked for a conceptual linchpin for steirische herbst in the sociopolitical context of contemporary art and its expanded concept of art. In cooperation with the philosopher Peter Strasser—and with Werner Krause (theater, literature) and Cathrin Pichler (visual art, as of 1992) on the program committee—he conceived a "sort of corporate philosophy" for steirischer herbst '89, which would redefine the presentation and discussion of cross-boundary phenomena in art and the cultural behavior of the 1990s.1 A "festival of contemporary culture" was to replace the concept of the avant-garde of the 1960s and 1970s, which had become obsolete, and the fatigue resulting from the innovations of the 1980s. "The ideals of the countermovement are diligence, precision, interpretation, and the development of new fields of relationships, resulting in the establishment of new forms of cultural behavior" (program booklet, 1990).
steirischer herbst was to provide a place for encounters with "nomadic" strategies in art at the end of the postmodern age. Haberl positioned the years of his artistic direction, based on Gilles Deleuze and Félix Guattari, under the umbrella concept of a "nomadology of the 1990s," which linked the individual overarching themes with one another. He simultaneously proclaimed a paradigm shift for the next decade. "With the nomadology of the 1990s, steirischer herbst intends to span a bridge to the culture of mobility, as one possible third path besides the avant-garde and the postmodern," as Haberl wrote in the program booklet for 1990.
This reorientation was accompanied by an increasing globalization and the resulting nomadization of the art world in the 1990s, as reflected in the establishment of innumerable new biennials all over the world. But even more than globalization or global refugee movements, Haberl and Strasser were interested in "new aspects of an intellectual mobility, a lived interdisciplinarity, and a nomadizing sensibility," which "on the one hand, reflect the sociopolitical context of the contemporary behavior in art and culture, and, on the other, are oriented contrary to the either/or fixation of disparate disciplines in art, science, technology, politics, et cetera."2
To provide a foundation for the theoretical superstructure of a principle of nomadic thinking, Haberl and Strasser initiated the Herbstschrift as a literary forum for the "nomadology of the 1990s." Authors such as Vilém Flusser, Peter Sloterdijk, Adolf Holl, Franz Schuh, Thomas Macho, Peter Jirak, and Peter Strasser contributed essays to the first volume, herbstbuch eins.
The first guiding theme during Haberl's time as artistic director was auf, und, davon (Up, and, Away). The idiosyncratic punctuation referred to "the reflexive, to a moving-away-from, to possibilities that make it possible to hope again"—very much in the spirit of the keynote speaker, Vilém Flusser: "For nomads, ownership of concepts is madness. And for settled individuals, undefined wandering is senseless rambling. However, we no longer see a nothingness, but rather a concrete (if also invisible) field of relationships."3 Corresponding to the nomadic principle of a tent, Haberl organized an architecture competition for a mobile event hall as a "symbol of cultural and intellectual mobility" at the Alte Remise in 1990.
Under Haberl's artistic direction, with Johannes Frankfurter as dramaturge, there were spectacular theater performances by Botho Strauß (1991), Werner Schwab (1992, 1993), and Urs Widmer (1993), performances by international guests such as Brigitte Fürle (1991) and Christoph Schlingensief (1995), and musical theater by Beat Furrer (1994). In addition, there were art performances such as the monumental sculpture Lichtschwert (Light Sword) by Hartmut Skerbisch (1992) and events such as Grazer Combustion (1993)—a "controversial cycle at, in, and around the Schloßberg in Graz, in the form of an exhibition staging and a concentrated series of performances," as well as a pop song revue. Particular attention was given to the perception of steirischer herbst outside of Graz with project series such as the Mürztaler Werkstatt, the Hör-Fest Steinach, the Schreams cultural initiative, or the Kult-Ur-Weg-Pischelsdorf.
Haberl's time as artistic director ended in 1995 with the overarching theme "art is over, the game goes on," which summarized his tenure in a suggestive way. Two years before, in cooperation with Peter Strasser, he had developed a concept for a content-related restructuring of steirischer herbst, which related to the planned construction of a new Kunsthaus in Graz and based on the insight that "the limited duration of a festival is not sufficient for presenting future-oriented aesthetic issues or corresponding interdisciplinary objects of research and making them legible." However, the concept failed, according to Haberl, due to the partisan pragmatism on the regional level.
The trigon biennale also took place for the last time in 1995. It was no longer relevant due to the departure of Wilfried Skreiner, the increasing interdisciplinary orientation of the festival, and the political upheavals that followed the dissolution of Yugoslavia.
Horst Gerhard Haberl's departure is marked by a note of bitterness. Peter Strasser, a leading member in his advisory council, commented, "If I had not been aware at the time of the baseness of which so-called civilized people are capable—I was able to experience it then."4 According to Strasser, Haberl had been calumniated for such a long period of time "that the media started to enjoy [reporting] on what they called 'the outdated festival.'"
Horst Gerhard Haberl, "Das nomadische Prinzip," in Nomadologie der Neunziger: steirischer herbst Graz 1990 bis 1995, ed. Horst Gerhard Haberl and Peter Strasser (Ostfildern: Cantz, 1995).
Haberl, "Das nomadische Prinzip," p. 17.
Cited in Haberl, "auf, und, davon," p. 5.
Peter Strasser, "Der Höhepunkt H.G.H.," in herbstbuch: 1968–2017, ed. Martin Behr et al. (Vienna: Styria, 2017), p. 189.
Photo: Christian Jungwirth
(1941, Graz)
Exhibition and project curator, arts editor, editor and author of numerous publications and television features (ORF) on contemporary art
Studied art history and philosophy
1967–73 Collaborator and Curator at Neue Galerie Graz
1969–84 Art Director and Director of the "Future Department" at Humanic AG, Graz/Vienna (afterwards Art Consultant until 1995)
1970–76 Founding President of the artists' group pool, Graz/Vienna, Coeditor of the arts magazines pfirsich and pferscha
1973–84 Founder and Director of the Interdisciplinary Communication and Exhibition Space for Contemporary Art galerie H, Graz
1978–80 Artistic Director of the International Biennial Exhibition of Graphic and Visual Art at Wiener Secession
1984–88 Art critic and Director of the culture pages at Kleine Zeitung, Graz
1990–95 Director of steirischer herbst
1992–2004 Professor for Art Education and Design Theory at Hochschule der Bildenden Künste Saar, Saarbrücken (HBKsaar)
1993–2001 President of HBKsaar
2006 Hanns-Koren-Kulturpreis des Landes Steiermark
Publications (selection)
Körpersprache/Body-language (pfirsich 9/10). Graz: Pool, 1973.
Kunst als Lebensritual / Art as Living Ritual (pfirsich 12/14). Graz: Pool, 1974.
Friederike Pezold (pfirsich 15). Graz: Pool, 1975.
Expansion: Internationale Biennale für Graphik und Visuelle Kunst. Vienna: Verein Zur Durchführung der Internationalen Biennale für Graphik und Visuelle Kunst, 1979.
Die barocken Wilden. Alte Galerie am Landesmuseum Joanneum. Graz: Droschl, 1983.
"Kunst als Kommunikationsstrategie". Kunstforum International 87 (1987), p. 242 f.
Ed. with Peter Strasser: Nomadologie der Neunziger: steirischer herbst, 1990 bis 1995. Ostfildern: Cantz, 1995.
Colophon, Terms and Conditions
Special thanks to our
patrons and sponsors
for their generous support
We use cookies to make our services as user-friendly as possible and to collect information about our website. By using our site, you agree to the usage of cookies.


text:
Hospitalized because of the COVID-19, Boris Johnson made "great progress"
magictr | April 11, 2020 | Politic | No Comments
LONDON | british prime minister Boris Johnson, suffering from the new coronavirus and hospitalized for almost a week, because of "great progress" announced on Saturday that one of its spokespersons.
The conservative leader, 55-year-old was released Thursday night of the intensive care unit, where he was held since Monday. He was transferred to another service hospital london St Thomas ' where he is placed under close supervision for the initial phase of his recovery ", according to previous statements.
"The prime minister continues to make great progress," said Saturday a spokesman.
The day before already, the services of Boris Johnson had announced that he was starting to " walk a little ". "Morale remains good ", had he been previously reported, specifying that the first minister was in "the initial phase" of his recovery and his return to the orders of the executive would depend on " the opinion of his medical team ".
Diagnosed positive Covid-19 at the end of march, Boris Johnson is to this day the only head of government of a great power to have been contaminated by the virus, which has led to nearly 9,000 deaths in the United Kingdom, one of the european countries hardest hit.
It is the head of the diplomacy, Dominic Raab, who is temporarily acting in the absence of Boris Johnson, who is "not out of the woods yet" and must "take the time" to recover from his infection Covid-19, said his father, Stanley Johnson, Friday on the BBC.
"I can't believe that you'd come out and go back directly to Downing Street and take over the reins without a period of readjustment," added Mr. Johnson's father.
The government must decide next week on a possible extension of the containment, which began on 23 march and, in principle, expected to last three weeks until Monday.
If no formal decision is expected before the end of next week, the message hammered by the authorities is not to release the measures of social distancing adopted, particularly during the long weekend of spring Easter.
Bogdan, Timoshenko, Avakov. Tsarev called the main candidates for the post of Prime Minister
Of american bases honoring the confederate generals could be renamed
No Comments | Jun 9, 2020
Air Transport: in Europe, a re-launch in slow motion
Green light to the launch on Thursday of the mars rover, Perseverance


text:
Big Boost For Female Police Officers
The Director of Peacekeeping in the Sierra Leone Police (SLP), Superintendent John Tumbay has disclosed that a new contingent of one hundred and sixty (160) personnel would soon leave for Somalia on peacekeeping mission.
According to the Director, about 30% of the personnel would be female, whilst he praised the current status of Sierra Leone's peacekeeping personnel in various Africa Union (AU) and United Nation Peacekeeping Missions around the world.
He commended the Executive Management Board of the SLP for purchasing standard equipment for the Somalia operations and urged the Government of Sierra Leone (GoSL) to continue supporting the SLP.
Meanwhile, Supt. John Tumbay has disclosed that the SLP has planned to send 100% female officers to a future peacekeeping mission around the world.
According to the Director, Sierra Leone will be the second African country to do so after Rwanda, noting that India was the first nation to have introduced such initiative.
The Director disclosed that despite having a good number of female police officers serving in various peacekeeping missions around the world, the SLP has decided to come up with the all-female initiative due to the cultural and religious practices in some of the war affected countries they would be deploying as peacekeepers. He noted that countries like Somalia and Sudan are complete Islamic states where adultery is an abomination.
He asserted that the initiative would help rebrand the gender image of the SLP globally and set an example for other nations to emulate.


I love this idea. Last week i was scouring the internet for some more inquiry ideas for my classroom when i came across genius hour.
In one carl barks comic book the blackboard in a kindergarten classroom has a slightly illegible possibly nonsensical mathematical expression written on it.
Classroom blackboard decoration ideas for school. Stock embroidery designs for a wide range of embroidery machines. Discover the best banners in best sellers. Find the top 100 most popular items in amazon office products best sellers.
Early head start teacher i wayne metropolitan community action agency highland park mi. Closing date for job. Heres a collection of ideas to help you create a hollywood theme in your classroom.
Find the top 100 most popular items in amazon office products best sellers. Discover the best school classroom decorations in best sellers. We sympathize with families that may be affected by the federal government shutdown.
Classroom themes are increasingly more and more popular. Our students here at e k are currently receiving free breakfasts and lunches and. The following lesson plans and activities are designed to build such skills as creative writing observing vocabulary development and art appreciation.
I actually plan to use this at the end of my school year so it can showcase their argument and rhetorical skills learned over the school year.


Brand new, never played! Shop stock sold from a brick and mortar Toronto-based record store. No price gouging!
New RSD Title! Still sealed! In retail environment, may show shop wear.
new copy, still sealed RSD 2019 LAST ONE!!
RSD 2019. NEW, factory sealed.
First time on Vinyl for thes 2 tracks.
Record Store Day 2019 Release - Buy from official RSD SHOP.


Comprehensive Care realizes there are many factors that go in to reducing work related incidents and maintaining a sound functional workforce. We have developed a series of Specialty Service Programs designed in aiding in these areas. Each program is designed to work independently or they can be grouped with other programs to maximize the impact.
An Early Intervention Wellness and Injury Prevention Program is a tool by which the individual employee's wellness and interaction with their job responsibilities and work station are systematically studied so that their causes and contributing factors can be identified and eliminated.
The services listed below are provided by trained specialists.
Complete the job demands analysis, and enter job demands, media, and procedure information into a spreadsheet.
Conduct industrial ergonomic risk assessments.
Provide and document risk reduction recommendations.
Track all early intervention activity during monthly review meetings.
c. Conservative treatment (including stretching and strengthening) will result in progressive healing.
Job Site Analysis (JSA) is a systematic review of job positions within a workplace to identify potential issues or hazards. Once an issue or hazard has been identified, control methods can be reviewed to eliminate or control that issue or hazard.
The first step in completing a job site analysis is to develop an inventory (list) of all jobs / occupations in the workplace. This list is to include all temporary, part and full time employees, ranging from entry level positions to the General Manager. This information is to be recorded in a log. Common ongoing issues and hazards should also be recorded on this log and include conditions that pose a risk and are applicable to more than one position in the workplace (i.e. heat from an oven can effect more than one job position).
The second step is to identify the specific job tasks that are involved in each position (i.e. move packages, operate a forklift, assemble a product, etc.). Once each task has been identified, the third step is to analyze each task for potential or actual issues or hazards and losses. Each of the potential or actual issues or hazards should be classified by severity.
The fourth step is to identify control measures for each of the issues or hazards, implement the controls, and follow up to ensure effectiveness. Control measures are only effective if they contain the issue or hazard, do not create any additional issues or hazards and are used by workers. All issues or hazards that are classified as significant must have a safe work procedure developed for the tasks associated with the specific issue or hazard. Steps two to four can be recorded on the Job Site Analysis and Control Measures form.
An Accident Investigation Program is a management tool by which accidents or injuries are systematically studied so that their causes and contributing factors can be identified and eliminated. Comprehensive Care will work with your company to develop a program specific to your company's environment and needs.
Using our over 20 years of human resource and safety experience Comprehensive Care will assist in the revision and implementation of your employee handbooks. Comprehensive Care will ensure that all aspects are covered and are compliant with your protocols as they relate to your specific industry segment.
Management Services. We have formed joint ventures with both Methodist Hospital and Prompt Ambulance to allow for 24 hour coverage. These alliances will allow our clients to receive prompt care during our off hours. The physicians and staff have been trained by our doctors as to our policies, procedures, and philosophies as it relates to worker's comp injury care and drug screen / breath alcohol protocols.
Services can be performed at your facility or either one of the Methodist Hospital Campuses.
Comprehensive Care offers transportation services 24/7.
If an employee tests positive on a Saliva Alcohol Test, they will need to immediately report to either Comp Care or Methodist Northlake for Breath Alcohol Testing for confirmation.