text:
|D. Gillmor
|Intended status: Informational
|April 15, 2019
|Expires: October 17, 2019
Abuse-Resistant OpenPGP Keystores
OpenPGP transferable public keys are composite certificates, made up of primary keys, direct key signatures, user IDs, identity certifications ("signature packets"), subkeys, and so on. They are often assembled by merging multiple certificates that all share the same primary key, and are distributed in public keystores.
Unfortunately, since many keystores permit any third-party to add a certification with any content to any OpenPGP certificate, the assembled/merged form of a certificate can become unwieldy or undistributable. Furthermore, keystores that are searched by user ID can be made unusable for specific names or addresses by public submission of bogus data. And finally, keystores open to public submission can also face simple resource exhaustion from flooding with bogus submissions, or legal or other risks from uploads of toxic data.
This draft documents techniques that an archive of OpenPGP certificates can use to mitigate the impact of these various attacks.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 17, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
OpenPGP keystores that handle submissions from the public are subject to a range of attacks by malicious submitters.
This section describes four distinct attacks that public keystores should consider.
The rest of the document describes some mitigations that can be used by keystores that are concerned about these problems but want to continue to offer some level of service for certificate discovery, certificate update, or certificate validation.
Many public keystores (including both the [SKS] keyserver network and [MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the form of third-party certifications) to any certificate, bloating that certificate to the point of being impossible to effectively retrieve. For example, some OpenPGP implementations simply refuse to process certificates larger than a certain size.
This kind of Denial-of-Service attack makes it possible to make someone else's certificate unretrievable from the keystore, preventing certificate discovery. It also makes it possible to swamp a certificate that has been revoked, preventing certificate update, potentially leaving the client of the keystore with the compromised certificate in an unrevoked state locally.
Additionally, even without malice, OpenPGP certificates can potentially grow without bound.
Public keystores that are used for certificate discovery may also be vulnerable to attacks that flood the space of known user IDs. In particular, if the keystore accepts arbitrary certificates from the public and does no verification of the user IDs, then any client searching for a given user ID may need to review and process an effectively unbounded set of maliciously-submitted certificates to find the non-malicious certificates they are looking for.
For example, if an attacker knows that a given system consults a keystore looking for certificates which match the e-mail address email@example.com, the attacker may upload hundreds or thousands of certificates containing user IDs that match that address. Even if those certificates would not be accepted by a client (e.g., because they were not certified by a known-good authority), the client typically still has to wade through all of them in order to find the non-malicious certificates.
If the keystore does not offer a discovery interface at all (that is, if clients cannot search it by user ID), then user ID flooding is of less consequence.
A public keystore that accepts arbitrary OpenPGP material and is append-only is at risk of being overwhelmed by sheer quantity of malicious uploaded packets. This is a risk even if the user ID space is not being deliberately flooded, and if individual certificates are protected from flooding by any of the mechanisms described later in this document.
The keystore itself can become difficult to operate if the total quantity of data is too large, and if it is a synchronizing keyserver, then the quantities of data may impose unsustainable bandwidth costs on the operator as well.
Effectively mitigating against keystore flooding requires either abandoning the append-only property that some keystores prefer, or imposing very strict controls on initial ingestion.
Like any large public dataset, it's possible that a keystore ends up hosting some content that is legally actionable in some jurisdictions, including libel, child pornography, material under copyright or other "intellectual property" controls, blasphemy, hate speech, etc.
A public keystore that accepts and redistributes arbitrary content may face risk due to uploads of toxic data.
These steps can be taken by any keystore that wants to avoid obviously malicious abuse. They can be implemented on receipt of any new packet, and are based strictly on the structure of the packet itself.
While [RFC4880] permits OpenPGP packet sizes of arbitrary length, OpenPGP certificates rarely need to be so large. An abuse-resistant keystore SHOULD reject any OpenPGP packet larger than 8383 octets. (This cutoff is chosen because it guarantees that the packet size can be represented as a one- or two-octet [RFC4880] "New Format Packet Length", but it could be reduced further)
This may cause problems for user attribute packets that contain large images, but it's not clear that these images are concretely useful in any context. Some keystores MAY extend this limit for user attribute packets specifically, but SHOULD NOT allow even user attributes packets larger than 65536 octets.
[RFC4880] indicates that User IDs are expected to be UTF-8 strings. An abuse-resistant keystore MUST reject any user ID that is not valid UTF-8.
Some abuse-resistant keystores MAY only accept User IDs that meet even stricter conventions, such as an [RFC5322] name-addr or addr-spec, or a URL like "ssh://host.example.org".
As simple text strings, User IDs don't need to be nearly as long as any other packets. An abuse-resistant keystore SHOULD reject any user ID packet larger than 1024 octets.
Some abuse-resistant keystores may restrict themselves to publishing only certificates with User IDs that match a specific pattern. For example, [RFC7929] encourages publication in the DNS of only certificates whose user IDs refer to e-mail addresses within the DNS zone. [I-D.koch-openpgp-webkey-service] similarly aims to restrict publication to certificates relevant to the specific e-mail domain.
[RFC4880] signature packets contain an "unhashed" block of subpackets. These subpackets are not covered by any cryptographic signature, so they are ripe for abuse.
An abuse-resistant keysetore SHOULD strip out all unhashed subpackets.
Note that some certifications only identify the issuer of the certification by an unhashed Issuer ID subpacket. If a certification's hashed subpacket section has no Issuer ID or Issuer Fingerprint (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an abuse-resistant keystore that has cryptographically validated the certification SHOULD make the unhashed subpackets contain only a single subpacket. That subpacket should be of type Issuer Fingerprint, and should contain the fingerprint of the issuer.
A special exception may be made for unhashed subpackets in a third-party certification that contain attestations from the certificate's primary key as described in Section 10.
Due to size concerns, some abuse-resistant keystores MAY choose to ignore user attribute packets entirely, as well as any certifications that cover them.
An abuse-resistant keystore MUST NOT accept any certification that has the "Exportable Certification" subpacket present and set to 0. While most keystore clients will not upload these "local" certifications anyway, a reasonable public keystore that wants to minimize data has no business storing or distributing these certifications.
Many OpenPGP packets have time-of-creation timestamps in them. An abuse-resistant keystore with a functional real-time clock MAY decide to only accept packets whose time-of-creation is in the past.
Note that some OpenPGP implementations may pre-generate OpenPGP material intended for use only in some future window (e.g. "Here is the certificate we plan to use to sign our software next year; do not accept signatures from it until then."), and may use modified time-of-creation timestamps to try to achieve that purpose. This material would not be distributable ahead of time by an abuse-resistant keystore that adopts this mitigation.
An aggressively abuse-resistant keystore MAY decide to only accept certifications that meet a specific profile. For example, it MAY reject certifications with unknown subpacket types, unknown notations, or certain combinations of subpackets. This can help to minimize the amount of room for garbage data uploads.
Any abuse-resistant keystore that adopts such a strict posture should clearly document what its expected certificate profile is, and should have a plan for how to extend the profile if new types of certification appear that it wants to be able to distribute.
Note that if the profile is ever restricted (rather than extended), and the restriction is applied to the material already present, such a keystore is no longer append-only (please see Section 7).
An abuse-resistant keystore capable of cryptographic validation MAY retain a list of designated authorities, typically in the form of a set of known public keys. Upon receipt of a new OpenPGP certificate, the keystore can decide whether to accept or decline each user ID of the certificate based whether that user ID has a certification that was issued by one or more of the designated authorities.
If no user IDs are certified by designated authority, such a keystore SHOULD decline the certificate and its primary key entirely. Such a keystore SHOULD decline to retain or propagate all certifications associated with each accepted user ID except for first-party certifications and certifications by the designated authorities.
The operator of such a keystore SHOULD have a clear policy about its set of designated authorities.
Given the ambiguities about expiration and revocation, such a keyserver SHOULD ignore expiration and revocation of authority certifications, and simply accept and retain as long as the cryptographic signature is valid.
Note that if any key is removed from the set of designated authorities, and that change is applied to the existing keystore, such a keystore may no longer be append-only (please see Section 7).
The maintainer of the keystore may keep a specific list of "known-bad" material, and decline to accept or redistribute items matching that blocklist. The material so identified could be anything, but most usefully, specific public keys or User IDs could be blocked.
Note that if a blocklist grows to include an element already present in the keystore, it will no longer be append-only (please see Section 7).
Some keystores may choose to apply a blocklist only at retrieval time and not apply it at ingestion time. This allows the keystore to be append-only, and permits synchronization between keystores that don't share a blocklist, and somewhat reduces the attacker's incentive for flooding the keystore (see Section 5 for more discussion).
Note that development and maintenance of a blocklist is not without its own potentials for abuse. For one thing, the blocklist may itself grow without bound. Additionally, a blocklist may be socially or politically contentious as it may describe data that is toxic (Section 3) in one community or jurisdiction but not another. There needs to be a clear policy about how it is managed, whether by delegation to specific decision-makers, or explicit tests. Furthermore, the existence of even a well-intentioned blocklist may be an "attractive nuisance," drawing the interest of would-be censors or other attacker interested in controlling the ecosystem reliant on the keystore in question.
Most of the abuse mitigations described in this document are described as being applied at certificate ingestion time. It's also possible to apply the same mitigations when a certificate is retrieved from the keystore (that is, during certificate update or certificate discovery). Applying an abuse mitigation at retrieval time may help a client defend against a user ID flooding (Section 2.2) or certificate flooding (Section 2.1) attack. However, only mitigations applied at ingestion time are able to mitigate keystore flooding attacks (Section 2.3).
Some mitigations (like the non-append-only mitigations described in Section 7) may be applied as filters at retrieval time, while still allowing access to the (potentially much larger) unfiltered dataset associated given certificate or user ID via a distinct interface.
The rest of this section documents a specific mitigation that is applied only at retrieval time.
Some abuse-resistant keystores may accept and store user IDs but decline to redistribute some or all of them, while still distributing the certifications that cover those redacted user IDs. This draft refers to such a keystore as a "user ID redacting" keystore.
The certificates distributed by such a keystore are technically invalid [RFC4880] "transferable public keys", because they lack a user ID packet, and the distributed certifications cannot be cryptographically validated independently. However, an OpenPGP implementation that already knows the user IDs associated with a given primary key will be capable of associating each certification with the correct user ID by trial signature verification.
A user ID redacting keystore is useful for certificate update by a client that already knows the user ID it expects to see associated with the certificate. For example, a client that knows a given certificate currently has two specific user IDs could access the keystore to learn that one of the user IDs has been revoked, without any other client learning the user IDs directly from the keystore.
It's possible (though non-intuitive) to use a user ID redacting keystore for certificate discovery. Since the keystore retains (but does not distribute) the user IDs, they can be used to select certificates in response to a search. The OpenPGP certificates sent back in response to the search will not contain the user IDs, but a client that knows the full user ID they are searching for will be able to verify the returned certifications.
Certificate discovery from a user ID redacting keystore works better for certificate discovery by exact user ID match than it does for substring match, because a client that discovers a substring match may not be able to reconstruct the redacted user ID.
However, without some additional restrictions on which certifications are redistributed (whether the user ID is redacted or not), certificate discovery can be flooded (see Section 13.1).
To ensure that the distributed certificate is at least structurally a valid [RFC4880] transferable public key, a user ID redacting keystore MAY distribute an empty user ID (an OpenPGP packet of tag 13 whose contents are a zero-octet string) in place of the omitted user ID. This two-octet replacement user ID packet ("\xb4\x00") is called the "unstated user ID".
To facilitate clients that match certifications with specific user IDs, a user ID redacting keystore MAY insert a non-hashed notation subpacket into the certification. The notation will have a name of "uidhash", with 0x80 ("human-readable") flag unset. The value of such a notation MUST be 32 octets long, and contains the SHA-256 cryptographic digest of the UTF-8 string of the redacted user ID.
A certificate update client which receives such a certification after the "unstated user ID" SHOULD compute the SHA-256 digest of all user IDs it knows about on the certificate, and compare the result with the contents of the "uidhash" notation to decide which user ID to try to validate the certification against.
User ID redaction is at best an imperfect process. Even if a keystore redacts a User ID, if it ships a certification over that user ID, an interested client can guess user IDs until it finds one that causes the signature to verify. This is even easier when the space of legitimate user IDs is relatively small, such as the set of commonly-used hostnames
Some mitigations make the acceptance or rejection of packets contingent on data that is already in the keystore or the keystore's developing knowledge about the world. This means that, depending on the order that the keystore encounters the various material, or how it discovers the material, the final set of material retained and distributed by the keystore might be different.
While this isn't necessarily bad, it may be a surprising property for some users of keystores.
An abuse-resistant keystore that is capable of doing cryptographic validation MAY decide to reject certifications that it cannot cryptographically validate.
This may mean that the keystore rejects some packets while it is unaware of the public key of the issuer of the packet.
This is an extension of Section 4.9, but where the set of authorities is just the set of certificates already known to the keystore. An abuse-resistant keystore that adopts this strategy is effectively only crawling the reachable graph of OpenPGP certificates from some starting core.
A keystore adopting the mitigation SHOULD have a clear documentation of the core of initial certificates it starts with, as this is effectively a policy decision.
This mitigation measure may fail due to a compromise of any secret key that is associated with a primary key of a certificate already present in the keystore. Such a compromise permits an attacker to flood the rest of the network. In the event that such a compromised key is identified, it might be placed on a blocklist (see Section 4.10). In particular, if a public key is added to a blocklist for a keystore implementing this mitigation, and it is removed from the keystore, then all certificates that were only "reachable" from the blocklisted certificate should also be simultaneously removed.
Some OpenPGP keystores accept material from the general public over the Internet. If an abuse-resistant keystore observes a flood of material submitted to the keystore from a given Internet address, it MAY choose to throttle submissions from that address. When receiving submissions over IPv6, such a keystore MAY choose to throttle entire nearby subnets, as a malicious IPv6 host is more likely to have multiple addresses.
This requires that the keystore maintain state about recent submissions over time and address. It may also be problematic for users who appear to share an IP address from the vantage of the keystore, including those behind a NAT, using a VPN, or accessing the keystore via Tor.
Some public keystores resist abuse by explicitly filtering OpenPGP material based on a set of external processes. For example, [DEBIAN-KEYRING] adjudicates the contents of the "Debian keyring" keystore based on organizational procedure and manual inspection.
Some keystores resist abuse by declining any certificate until the user IDs have been verified by e-mail. When these "e-mail validating" keystores review a new certificate that has a user ID with an e-mail address in it, they send an e-mail to the associated address with a confirmation mechanism (e.g., a high-entropy HTTPS URL link) in it. In some cases, the e-mail itself is encrypted to an encryption-capable key found in the proposed certificate. If the keyholder triggers the confirmation mechanism, then the keystore accepts the certificate.
Some e-mail validating keystores MAY choose to distribute certifications over all user IDs for any given certificate, but will redact (see Section 5.1) those user IDs that have not been e-mail validated.
[PGP-GLOBAL-DIRECTORY] describes some concerns held by a keystore operator using this approach. [MAILVELOPE-KEYSERVER] is another example.
The following mitigations may cause some previously-retained packets to be dropped after the keystore receives new information, or as time passes. This is entirely reasonable for some keystores, but it may be surprising for any keystore that expects to be append-only (for example, some keyserver synchronization techniques may expect this property to hold).
Furthermore, keystores that drop old data (e.g., superseded certifications) may make it difficult or impossible for their users to reason about the validity of signatures that were made in the past. See Section 11.3 for more considerations.
Note also that many of these mitigations depend on cryptographic validation, so they're typically contextual as well.
A keystore that needs to be append-only, or which cannot perform cryptographic validation MAY omit these mitigations. Alternately, a keystore may omit these mitigations at certificate ingestion time, but apply these mitigations at retrieval time (during certificate update or discovery), and offer a more verbose (non-mitigated) interface for auditors, as described in Section 5.
Note that [GnuPG] anticipates some of these suggestions with its "clean" subcommand, which is documented as:
Compact (by removing all signatures except the selfsig) any user ID that is no longer usable (e.g. revoked, or expired). Then, remove any signatures that are not usable by the trust calculations. Specifically, this removes any signature that does not validate, any signature that is superseded by a later signature, revoked signatures, and signatures issued by keys that are not present on the keyring.
An abuse-resistant keystore SHOULD drop all signature packets that are explicitly superseded. For example, there's no reason to retain or distribute a self-sig by key K over User ID U from 2017 if the keystore have a cryptographically-valid self-sig over <K,U> from 2019.
Note that this covers both certifications and signatures over subkeys, as both of these kinds of signature packets may be superseded.
Getting this right requires a nuanced understanding of subtleties in [RFC4880] related to timing and revocation.
If a signature packet is known to only be valid in the past, there is no reason to distribute it further. An abuse-resistant keystore with access to a functionally real-time clock SHOULD drop all certifications and subkey signature packets with an expiration date in the past.
Note that this assumes that the keystore and its clients all have roughly-synchronized clocks. If that is not the case, then there will be many other problems!
If enough signature packets are dropped, it's possible that some of the things that those signature packets cover are no longer valid.
An abuse-resistant keystore which has dropped all certifications that cover a User ID SHOULD also drop the User ID packet.
Note that a User ID that becomes invalid due to revocation MUST NOT be dropped, because the User ID's revocation signature itself remains valid, and needs to be distributed.
A primary key with no User IDs and no subkeys and no revocations MAY itself also be removed from distribution, though note that the removal of a primary key may make it impossible to cryptographically validate other certifications held by the keystore.
If the primary key of a certificate is revoked via a direct key signature, an abuse-resistant keystore SHOULD drop all the rest of the associated data (user IDs, user attributes, and subkeys, and all attendant certifications and subkey signatures). This defends against an adversary who compromises a primary key and tries to flood the certificate to hide the revocation.
Note that the direct key revocation signature MUST NOT be dropped.
In the event that an abuse-resistant keystore is flooded with direct key revocation signatures, it should retain the hardest, earliest revocation (see also Section 12.1).
In particular, if any of the direct key revocation signatures is a "hard" revocation, the abuse-resistant keystore SHOULD retain the earliest such revocation signature (by signature creation date).
Otherwise, the abuse-resistant keystore SHOULD retain the earliest "soft" direct key revocation signature it has seen.
If either of the above date comparisons results in a tie between two revocation signatures of the same "hardness", an abuse-resistant keystore SHOULD retain the signature that sorts earliest based on a binary string comparison of the direct key revocation signature packet itself.
In combination with some of the dropping mitigations above, a particularly aggressive abuse-resistant keystore MAY choose an implicit expiration date for all signature packets. For example, a signature packet that claims no expiration could be treated by the keystore as expiring 3 years after issuance. This would permit the keystore to eject old packets on a rolling basis.
FIXME: it's not clear what should happen with signature packets marked with an explicit expiration that is longer than implicit maximum. Should it be capped to the implicit date, or accepted?
Warning: This idea is pretty radical, and it's not clear what it would do to an ecosystem that depends on such a keystore. It probably needs more thinking.
In addition to the mitigations above, some keystores may resist abuse by declining to accept any user IDs or certifications whatsoever.
Such a keystore MUST be capable of cryptographic validation. It accepts primary key packets, cryptographically-valid direct-key signatures from a primary key over itself, subkeys and their cryptographically-validated binding signatures (and cross signatures, where necessary).
Clients of an updates-only keystore cannot possibly use the keystore for certificate discovery, because there are no user IDs to match. However, they can use it for certificate update, as it's possible to ship revocations (which are direct key signatures), new subkeys, updates to subkey expiration, subkey revocation, and direct key signature-based certificate expiration updates.
Note that many popular OpenPGP implementations do not implement direct primary key expiration mechanisms, relying instead on user ID expirations. These user ID expiration dates or other metadata associated with a self-certification will not be distributed by an updates-only keystore.
Certificates shipped by an updates-only keystore are technically invalid [RFC4880] "transferable public keys," because they lack a user ID packet. However many OpenPGP implementations will accept such a certificate if they already know of a user ID for the certificate, because the composite certificate resulting from a merge will be a standards-compliant transferable public key.
Slightly more permissive than the updates-only keystore described in Section 8 is a keystore that also permits user IDs and their self-sigs.
A first-party-only keystore only accepts and distributes cryptographically-valid first-party certifications. Given a primary key that the keystore understands, it will only attach user IDs that have a valid self-sig, and will only accept and re-distribute subkeys that are also cryptographically valid (including requiring cross-sigs for signing-capable subkeys as recommended in [RFC4880]).
This effectively solves the problem of abusive bloating attacks on any certificate, because the only party who can make a certificate overly large is the holder of the secret corresponding to the primary key itself.
Note that a first-party-only keystore is still problematic for those people who rely on the keystore for discovery of third-party certifications. Section 10 attempts to address this lack.
It is possible to operate an updates-only keystore that also declines to redistribute user IDs (Section 5.1). This defends against concerns about publishing identifiable information, while enabling full certificate update for those keystore clients that already know the associated user IDs for a given certificate.
We can augment a first-party-only keystore to allow it to distribute third-party certifications as long as the first-party has signed off on the specific third-party certification.
An abuse-resistant keystore SHOULD only accept a third-party certification if it meets the following criteria:
What this means is that a third-party certificate will only be accepted/distributed by the keystore if:
FIXME: it's not clear whether the "ksok" notification is necessary – it's in place to avoid some accidental confusion with any other use of the Third-Party Confirmation signature packet type, but the author does not know of any such use that might collide.
[RFC4880] defines "Key Server Preferences" with a "No-modify" bit. That bit has never been respected by any keyserver implementation that the author is aware of. An abuse-resistant keystore following Section 10 effectively treats that bit as always set, whether it is present in the certificate or not.
Creating such an attestation requires multiple steps by different parties, each of which is blocked by all prior steps:
The complexity and length of such a sequence may represent a usability obstacle to a user who needs a third-party-certified OpenPGP certificate.
No current OpenPGP client can easily create the attestions described in this section. More implementation work needs to be done to make it easy (and understandable) for a user to perform this kind of attestation.
A first-party-only keystore as described in Section 9 might decline to distribute revocations made by the designated revoker. This is a risk to certificate-holder who depend on this mechanism, because an important revocation might be missed by clients depending on the keystore.
FIXME: adjust this document to point out where revocations from a designated revoker SHOULD be propagated, maybe even in first-party-only keystores.
Much of this discussion assumes that primary keys are the only certification-capable keys in the OpenPGP ecosystem. Some proposals have been put forward that assume that subkeys can be marked as certification-capable. If subkeys are certification-capable, then much of the reasoning in this draft becomes much more complex, as subkeys themselves can be revoked by their primary key without invalidating the key material itself. That is, a subkey can be both valid (in one context) and invalid (in another context) at the same time. So questions about what data can be dropped (e.g. in Section 7) are much fuzzier, and the underlying assumptions may need to be reviewed.
If some OpenPGP implementations accept certification-capable subkeys, but an abuse-resistant keystore does not accept certifications from subkeys in general, then interactions between that keystore and those implementations may be surprising.
Online protocols like TLS perform signature and certificate evaluation based entirely on the present time. If a certificate that signs a TLS handshake message is invalid now, it doesn't matter whether it was valid a week ago, because the present TLS session is the context of the evaluation.
But OpenPGP signatures are often evaluated at some temporal remove from when the signature was made. For example, software packages are signed at release time, but those signatures are validated at download time.
Further complicating matters, the composable nature of an OpenPGP certificate means that the certificate associated with any particular signing key (primary key or subkey) can transform over time. So when evaluating a signature that appears to have been made by a given certificate, it may be better to try to evaluate the certificate at the time the signature was made, rather than the present time.
When evaluating a certificate at a time T in the past (for example, when trying to validate a data signature by that certificate that was created at time T), one approach is to discard all packets from the certificate if the packet has a creation time later than T. Then evaluate the resulting certificate from the remaining packets in the context of time T.
However, any such evaluation MUST NOT ignore "hard" OpenPGP key revocations, regardless of their creation date. (see Section 12.1).
If a non-append-only keystore (Section 7) has dropped superseded (Section 7.1) or expired (Section 7.2) certifications, it's possible for the certificate composed of the remaining packets to have no valid first-party certification at the time that a given signature was made. Such a certificate would be invalid according to [RFC4880], and consequently verification of any signature .
However, there is a simple mitigation: anyone distributing a signature (e.g. a software archive) should ship the contemporary signing certificate alongside the signature. If the distributor does this, then the verifier can perform a certificate update (to learn about revocations) against any preferred keystore, including non-append-only keystores, merging what it learns into the distributed contemporary certificate.
Then the signature verifier can follow the certificate evaluation process outlined in Section 11.3.1, using the merged certificate.
The append-only aspect of some OpenPGP keystores encourages a user of the keystore to rely on that keystore as a faithful reporter of history, and one that will not misrepresent or hide the history that they know about. An unfaithful "append-only" keystore could abuse the trust in a number of ways, including withholding revocation certificates, offering different sets of certificates to different clients doing key discovery, and so on.
However, the most widely used append-only OpenPGP keystore, the [SKS] keyserver pool, offers no cryptographically verifiable guarantees that it will actually remain append-only. Users of the pool have traditionally relied on its distributed nature, and the presumption that coordination across a wide range of administrators would make it difficult for the pool to reliably lie or omit data. However, the endpoint most commonly used by clients to access the network is hkps://hkps.pool.sks-keyservers.net, the default for [GnuPG]. That endpoint is increasingly consolidated, and currently consists of hosts operated by only two distinct administrators, increasing the risk of potential misuse.
Offering cryptographic assurances that a keystore could remain append-only is an appealing prospect to defend against these kinds of attack. Many popular schemes for providing such assurances are known as "blockchain" technologies, or global append-only ledgers.
With X.509 certificates, we have a semi-functional Certificate Transparency ([RFC6962], or "CT") ecosystem that is intended to document and preserve evidence of (mis)issuance by well-known certificate authorities (CAs), which implements a type of global append-only ledger. While the CT infrastructure remains vulnerable to certain combinations of colluding actors, it has helped to identify and sanction some failing CAs.
Like other global append-only ledgers, CT itself is primarily a detection mechanism, and has no enforcement regime. If a widely-used CA were identified by certificate transparency to be untrustworthy, the rest of the ecosystem still needs to figure out how to impose sanctions or apply a remedy, which may or may not be possible.
CT also has privacy implications – the certificates published in the CT logs are visible to everyone, for the lifetime of the log.
For spam abatement, CT logs decline all X.509 certificates except those issued by certain CAs (those in popular browser "root stores"). This is an example of the strategy outlined in Section 4.9).
Additional projects that provide some aspects of global append-only ledgers that try to address some of the concerns described here include [KEY-TRANSPARENCY] and [CONIKS], though they are not specific to OpenPGP. Both of these systems are dependent on servers operated by identity providers, however. And both offer the ability to detect a misbehaving identity provider, but no specific enforcement or recovery strategies against such an actor.
It's conceivable that a keystore could piggyback on the CT logs or other blockchain/ledger mechanisms like [BITCOIN] to store irrevocable pieces of data (such as revocation certificates). Further work is needed to describe how to do this in an effective and performant way.
A typical use case for certificate discovery is a user looking for a certificate in order to be able to encrypt an outbound message intended for a given e-mail address, but this is not the only use case.
Another use caes is when the party in control of a particular identity wants to determine whether anyone else is claiming that identity. That is, a client in control of the secret key material associated with a particular certificate with user ID X might search a keystore for all certificates matching X in order to discover whether any other certificates claim it.
This is an important safeguard as part of the ledger-based detection mechanisms described in Section 11.4, but may also be useful for keystores in general.
However, identity monitoring against a keystore that does not defend against user ID flooding (Section 2.2) is expensive and potentially of limited value. In particular, a malicious actor with a certificate which duplicates a given User ID could flood the keystore with similar certificates, hiding whichever one is in malicious use.
Since such a keystore is not considered authoritative by any reasonable client for the user ID in question, this attack forces the identity-monitoring defender to spend arbitrary resources fetching and evaluating each certificate in the flood, without knowing which certificate other clients might be evaluating.
This section collects details about common OpenPGP implementation behavior that are useful in evaluating and reasoning about OpenPGP certificates.
It's useful to classify OpenPGP revocations of key material into two categories: "soft" and "hard".
If the "Reason for Revocation" of an OpenPGP key is either "Key is superseded" or "Key is retired and no longer used", it is a "soft" revocation.
An implementation that interprets a "soft" revocation will typically not invalidate signatures made by the associated key with a creation date that predates the date of the soft revocation. A "soft" revocation in some ways behaves like a non-overridable expiration date.
All other revocations of OpenPGP keys (with any other Reason for Revocation, or with no Reason for Revocation at all) should be considered "hard".
The presence of a "hard" revocation of an OpenPGP key indicates that the user should reject all signatures and certifications made by that key, regardless of the creation date of the signature.
Note that some OpenPGP implementations do not distinguish between these two categories.
A defensive OpenPGP implementation that does not distinguish between these two categories SHOULD treat all revocations as "hard".
An implementation aware of a "soft" revocation or of key or certificate expiry at time T SHOULD accept and process a "hard" revocation even if it appears to have been issued at a time later than T.
[RFC4880] requires a user ID to be a UTF-8 string, but does not constrain it beyond that. In practice, a handful of conventions predominate in how User IDs are formed.
The most widespread convention is a name-addr as defined in [RFC5322]. For example:
Alice Jones <firstname.lastname@example.com>
But a growing number of OpenPGP certificates contain user IDs that are instead a raw [RFC5322] addr-spec, omitting the display-name and the angle brackets entirely, like so:
Some certificates have user IDs that are simply "normal" human names (perhaps display-name in [RFC5322] jargon, though not necessarily conforming to a specific ABNF). For example:
Alice Jones
Still other certificates identify a particular network service by scheme and hostname. For example, the administrator of an ssh host participating in the [MONKEYSPHERE] might choose a user ID for the OpenPGP representing the host like so:
This document offers guidance on mitigating a range of denial-of-service attacks on public keystores, so the entire document is in effect about security considerations.
Many of the mitigations described here defend individual OpenPGP certificates against flooding attacks (see Section 2.1). But only some of these mitigations defend against flooding attacks against the keystore itself (see Section 2.3), or against flooding attacks on the space of possible user IDs (see Section 2.2). Thoughtful threat modeling and monitoring of the keystore and its defenses are probably necessary to maintain the long-term health of the keystore.
Section 11.1 describes a potentially scary security problem for designated revokers.
TODO (more security considerations)
Note that there is an inherent tension between accepting arbitrary certificate uploads and permitting effective certificate discovery. If a keystore accepts arbitrary certificate uploads for redistribution, it appears to be vulnerable to user ID flooding (Section 2.2), which makes it difficult or impossible to rely on for certificate discovery.
In the broader ecosystem, it may be necessary to use gated/controlled certificate discovery mechanisms. For example, both [I-D.koch-openpgp-webkey-service] and [RFC7929] enable the administrator of a DNS domain to distribute certificates associated with e-mail addresses within that domain, while excluding other parties. As a rather different example, [I-D.mccain-keylist] offers certificate discovery on the basis of interest – a client interested in an organization can use that mechanism to learn what certificates that organization thinks are worth knowing about, regardless of the particular DNS domain. Note that this [I-D.mccain-keylist] does not provide the certificates directly, but instead expects the client to be able to retrieve them by certificate fingerprint through some other keystore capable of (and responsible for) certificate update.
Keystores themselves raise a host of potential privacy concerns. Additional privacy concerns are raised by traffic to and from the keystores. This section tries to outline some of the risks to the privacy of people whose certificates are stored and redistributed in public keystores, as well as risks to the privacy of people who make use of the key stores for certificate discovery or certificate update.
TODO (more privacy considerations)
Public OpenPGP keystores often distribute names or e-mail addresses of people. Some people do not want their names or e-mail addresses distributed in a public keystore, or may change their minds about it at some point. Append-only keystores are particularly problematic in that regard. The mitigation in Section 7.4 can help such users strip their details from keys that they control. However, if an OpenPGP certificate with their details is uploaded to a keystore, but is not under their control, it's unclear what mechanisms can be used to remove the certificate that couldn't also be exploited to take down an otherwise valid certificate.
Some jurisdictions may present additional legal risk for keystore operators that distribute names or e-mail addresses of non-consenting parties.
Updates-only keystores (Section 8) and user ID redacting keystores (Section 5.1) may reduce this particular privacy concern because they distribute no user IDs at all.
Third-party certifications effectively map out some sort of social graph. A certification asserts a statement of belief by the issuer that the real-world party identified by the user ID is in control of the subject cryptographic key material. But those connections may be potentially sensitive, and some people may not want these maps built.
A first-party-only keyserver (Section 9) avoids this privacy concern because it distribues no third-party privacy concern.
First-party attested third-party certifications described in Section 10 are even more relevant edges in the social graph, because their bidirectional nature suggests that both parties are aware of each other, and see some value in mutual association.
Even without third-party certifications, the acts of certificate discovery and certificate update represent a potential privacy risk, because the keystore queried gets to learn which user IDs (in the case of discovery) or which certificates (in the case of update) the client is interested in. In the case of certificate update, if a client attempts to update all of its known certificates from the same keystore, that set is likely to be a unique set, and therefore identifies the client. A keystore that monitors the set of queries it receives might be able to profile or track those clients who use it repeatedly.
Clients which want to to avoid such a tracking attack MAY try to perform certificate update from multiple different keystores. To hide network location, a client making a network query to a keystore SHOULD use an anonymity network like [TOR]. Tools like [PARCIMONIE] are designed to facilitate this type of certificate update.
Keystores which permit public access and want to protect the privacy of their clients SHOULD NOT reject access from clients using [TOR] or comparable anonymity networks. Additionally, they SHOULD minimize access logs they retain.
Alternately, some keystores may distribute their entire contents to any interested client, in what can be seen as the most trivial form of private information retrieval. [DEBIAN-KEYRING] is one such example; its contents are distributed as an operating system package. Clients can interrogate their local copy of such a keystore without exposing their queries to a third-party.
If access to the keystore happens over observable channels (e.g., cleartext connections over the Internet), then a passive network monitor could perform the same type profiling or tracking attack against clients of the keystore described in Section 14.3. Keystores which offer network access SHOULD provide encrypted transport.
Even if a keystore offers encrypted transport, the size of queries and responses may provide effective identification of the specific certificates fetched during discovery or update, leaving open the types of tracking attacks described in Section 14.3. Clients of keystores SHOULD pad their queries to increase the size of the anonymity set. And keystores SHOULD pad their responses.
The appropriate size of padding to effectively anonymize traffic to and from keystores is likely to be mechanism- and cohort-specific. For example, padding for keystores accessed via the DNS ([RFC7929] may use different padding strategies that padding for keystores accessed over WKD ([I-D.koch-openpgp-webkey-service]), which may in turn be different from keystores accessed over HKPS ([I-D.shaw-openpgp-hkp]). A keystore which only accepts user IDs within a specific domain (e.g., Section 4.3) or which uses custom process (Section 6.4) for verification might have different padding criteria than a keystore that serves the general public.
Specific padding policies or mechanisms are out of scope for this document.
Section 10.2 describes some outstanding work that needs to be done to help users understand how to produce and distribute a third-party-certified OpenPGP certificate to an abuse-resistant keystore.
Additionally, some keystores present directly user-facing affordances. For example, [SKS] keyservers typically offer forms and listings that can be viewed directly in a web browser. Such a keystore SHOULD be as clear as possible about what abuse mitigations it takes (or does not take), to avoid user confusion.
Experience with the [SKS] keyserver network shows that many users treat the keyserver web interfaces as authoritative, even though the developer and implementor communities explicitly disavow any authoritative role in the ecosystem, and the implementations attempt very few mitigations against abuse, permitting republication of even cryptographically invalid OpenPGP packets. Clearer warnings to end users might reduce this kind of misperception. Or the community could encourage the removal of frequently misinterpreted user interfaces.
This document asks IANA to register two entries in the OpenPGP Notation IETF namespace, both with a reference to this document:
[ RFC Editor: please remove this section before publication ]
This document is currently edited as markdown. Minor editorial changes can be suggested via merge requests at https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore or by e-mail to the author. Please direct all significant commentary to the public IETF OpenPGP mailing list: email@example.com
substantive changes between -01 and -02:
substantive changes between -00 and -01:
This document is the result of years of operational experience and observation, as well as conversations with many different people – users, implementors, keystore operators, etc. A non-exhaustive list of people who have contriubuted ideas or nuance to this document specifically includes:
|Koch, W., carlson, b., Tse, R. and D. Atkins, "OpenPGP Message Format", Internet-Draft draft-ietf-openpgp-rfc4880bis-06, November 2018.
|Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
|Callas, J., Donnerhacke, L., Finney, H., Shaw, D. and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007.
|Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
|"Bitcoin", n.d..
|Felten, E., Freedman, M., Melara, M., Blankstein, A. and J. Bonneau, "CONIKS Key Management System", n.d..
|McDowell, J., "Debian Keyring", n.d..
|Koch, W., "Using the GNU Privacy Guard", n.d..
|Koch, W., "OpenPGP Web Key Directory", Internet-Draft draft-koch-openpgp-webkey-service-07, November 2018.
|McCain, R., Lee, M. and N. Welch, "Distributing OpenPGP Key Fingerprints with Signed Keylist Subscriptions", Internet-Draft draft-mccain-keylist-04, March 2019.
|Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", Internet-Draft draft-shaw-openpgp-hkp-00, March 2003.
|Belvin, G. and R. Hurst, "Key Transparency, a transparent and secure way to look up public keys", n.d..
|Oberndörfer, T., "Mailvelope Keyserver", n.d..
|Gillmor, D. and J. Rollins, "Monkeysphere", n.d..
|Intrigeri, ., "Parcimonie", n.d..
|Symantec Corporation, "PGP Global Directory Key Verification Policy", 2011.
|Resnick, P., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008.
|Laurie, B., Langley, A. and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013.
|Wouters, P., "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP", RFC 7929, DOI 10.17487/RFC7929, August 2016.
|Minsky, Y., Fiskerstrand, K. and P. Pennock, "SKS Keyserver Documentation", March 2018.
|"The Tor Project", n.d..


text:
We use cookies to ensure this site gives you the best user experience possible.
Some of these cookies are essential and have already been set as we want to make sure all the features
of the site work. Others help us to improve by providing insight into how the site is being used.
If you continue without changing your settings, we'll assume that you are happy to receive all cookies
from our site and accept our Privacy Policy.
I accept cookies from this site.
The Dermatology Community Service provides nurse led outpatient clinics for adults and children with Eczema and Psoriasis.
How can people access the service?
Referrals are accepted via the GP Choose and Book system, letter or referral form from GPs, Health Visitors, School nurses, Community Matrons and Nurse Specialists.
Please note that referrals for dermatological conditions other than Eczema or Psoriasis will not be accepted by the Tier Two Dermatology Service.
Wigan Borough Dermatology Referral Form
Management whilst awaiting appointment:
Eczema and psoriasis both improve with the twice daily application of emollients (moisturisers) but these should be used four times a day in acute flares of Eczema and Psoriasis. (please note that aqueous cream is not suitable as a leave-on emollient as it contains Sodium Lauryl Sulphate which is harmful in Eczema and Psoriasis).
Choosing Emollients
Emollients vary in the amount of grease or lipid that they contain and some are mixed with water.
The lighter emollients contain the least grease and most water.
The amount of grease increases as we step up the ladder graduating to the very greasy emollients at the top which are just pure grease.
The lighter the emollient, the easier it tends to be to soak in.
These can be really helpful if the hands are affected, if greasier moisturisers are not acceptable or if the skin is hairy.
However, this can also mean that more applications of emollient may be required to gain control of the skin condition.
Very greasy emollients are messier to apply and can stain bedding and clothing. However, they usually tend to work faster and do not usually contain preservatives.
They are therefore less likely than creams, gels and lotions to cause irritation or stinging.
Ointments and thicker creams also have a great barrier function if the face is affected and it can be useful to apply one of these before going out into the cold or before eating if the mouth is affected to avoid the irritation of food Creams that contain urea can be helpful where the skin is thickened or remains very dry despite the use of a greasy emollient.
These creams do tend to sting more though, especially if the skin is broken.
A greasier emollient at night and a lighter emollient throughout the day may be preferred initially but initially a greasier emollient may be required up to 4 times a day in order to obtain control.
It also depends on how dry the skin is as to how much grease is required.
A general rule is that the drier the skin, the greasier the emollient should be, so for example very dry skin is best treated with an ointment, moderately dry with a cream or gel, and slightly dry with a lotion.
Emollients for sensitive skin are available to purchase at your local pharmacy or supermarket and are also available on NHS prescription.
The choice of emollients that can be prescribed locally is based on the most current specialist recommendations and cost effectiveness.
These choices are demonstrated on the Emollient ladder below:
People with Eczema or Psoriasis should avoid using any soap products (this includes all foaming products such as Sanex, Simple etc as these contain Sodium Lauryl Sulphate which is harmful in Eczema and Psoriasis) and use their emollient instead.
This should be applied to dry skin before entering water and simply washed off before leaving the bath or shower.
The greasier the emollient, usually the more of a 'thicker, soapy' feeling it has. If a face cloth or sponge is used, a clean one each day should be used as damp cloths and sponges provide a breeding ground for bacteria.
The bath water should be warm but not hot. If the water is too hot this may cause itching.
Take care to wash the bath and shower out thoroughly after you have used emollients as these can make them very slippy and dangerous. It is a good idea to use a slip resistant bath or shower mat toavoid any accidents.
It's best to dry the skin by patting gently with the towel as opposed to rubbing and to apply emollient immediately after drying as this will help to trap moisture into the skin.
Topical Steroids
Topical steroids come in lotions, creams, gels and ointments.
They reduce inflammation and itch and should be prescribed only where the skin is inflamed and a definite diagnosis of Eczema or Psoriasis has been made as topical steroids can make fungal infections, rosacea and acne worse.
They should be prescribed to use once to twice daily and applied after the generous application of emollient (as soon as this is no longer visible on the skin).
The steroid should be applied 'accurately' to any inflamed areas until completely clear and then immediately on rebound of the inflammation.
The Strength of steroid should be chosen based on the body area being treated and age of the patient (ie start with a mild steroid in babies or potent for scalp/hands in adults).
If steroid free days are not being achieved after 2 weeks, the diagnosis is certain and infection has been ruled out then the strength of steroid may be increased if the body site being treated allows.
If potent steroids are prescribed in psoriasis they should be done so in combination with a vitamin D analogue or tar treatment in order to prevent rebound.
Mild and Moderate topical steroids are available to purchase at your local pharmacy.
These are also available on NHS prescription along with potent and super potent steroids.
The choice of topical steroids that can be prescribed locally is based on the most current specialist recommendations and cost effectiveness.
These choices are demonstrated on the Steroid ladder below:
Where is the service offered?
Clinics are provided Monday to Friday from 8.30am until 6.00pm at:
Boston House, Frog Lane, Wigan, WN6 7LB
Claire House, Pheonix Way, Lower Ince, WN3 4NW
Leigh Health Centre, Leigh Infirmary, The Ave, Leigh, WN7 1HR
First appointments will last approximately 40 minutes and follow up appointments 20 minutes.
Contact details
Tier Two Dermatology
Boston House
Frog Lane
Telephone: 01942-482230 (Longterm Conditions Suite, Frog Lane)
Fax: 01942 482257
Our leaflets
Eczema - Expert Top Tips
Eczema – need to know more leaflet
Psoriasis – need to know more leaflet

subset: commoncrawl


text:
A clear, effective communication skill is one of the best attributes a person can develop. It equips you to be successful professionally and personally. By … [Read more...]
Effective Communication in the Workplace
Executive Coaching and Leadership Team Development
The truth is there is no BEST way. Regardless of the type of training, there is no one way to do it and one size definitely does not fit all. Each of us has … [Read more...]
Leadership Coaching for Change Management
What do college athletes, Olympic gold medalists and smart business leaders have in common? They rely on coaches to help them reach their greatest potential and teach … [Read more...]
Effective Coaching in the Workplace
As a leader of a group, a team or an organization you must remember to focus on the impact you have on the audience. When you are coaching or evaluating your … [Read more...]
Business Meeting Itinerary and Change Management
Meetings can cost a lot of money if they are not productive. If your manager has put you in charge of leading an upcoming meeting, ensure it goes well by using these … [Read more...]
Effective Business Meetings Equal 37 Billion Dollars per Year
And that dollar figure only applies to the United States! While meetings are a necessary activity, at times you may be sitting there wondering when it will be over, if … [Read more...]
Take Time to Assess the Quality of Your Business Meetings
Meetings can be a powerful tool for your business. If poorly run however, they can be a tremendous waste of time and energy and actually cause more harm than … [Read more...]
Create and Cultivate Great Culture to Secure High Performance
Company culture seems to be a widely circulated term, but one that few people clearly understand. Culture is the 'good stuff" in an organization that makes … [Read more...]
Continually Improve Your Leadership Capabilities
As a leader you must continually build your techniques, capabilities and habits. You need to be able to evaluate honestly where you are, what strengths you have … [Read more...]
Leading A Small But Effective Team
We believe that great teamwork is essential to an organization. It enables businesses to achieve goals that an individual working alone cannot. Employees can … [Read more...]


text:
The change we need will to tackle our trickiest problems will be led and delivered by people.
The team behind the War on Waste is working on a new ABC documentary that will focus on Australia's role in climate change.
Announcing the release of two new PPA resources live on the BRC-A Resource Library
We're excited to announce that City of Sydney and City of Adelaide have a number of grants available for signatories in these LGA's.
The CitySwitch Green Office program has surpassed four million square metres of office space, as ANZ signs on 833 Collins Street in Melbourne.
From blend-your-own smoothie bikes to calorie-free cupcakes, the Museum of Futures to a mind-mapping session, the Better Buildings Cup launched with a flurry of activity recently.
Powering Australia from 100% renewable energy is no longer ambitious. We have more sun, wind and hydro resources than coal, gas and oil combined. And with vision and ambition, we can become the world's renewable energy superpower.
Industry leaders from the hospitality, events and property sectors came together to sign up to the Sydney Single-use Pledge.
Climate-KIC Australia today launched the Australian 2019 edition of the world's largest green business ideas competition, ClimateLaunchpad.
22 - 24 March, 2016
Hilton Sydney, 488 George St, Sydney.
Co-hosted annually by the Green Building Council of Australia (GBCA) and the Property Council of Australia, Green Cities is Australia's premier sustainability conference for the built environment. 2016 marks a decade of Green Cities - and the time has come to dial things up. It's time to be disruptive.
The 2016 event will deliver three days of practical site tours, hands-on masterclasses, fun networking events and inspiring speakers.
Over the past decade, the event has connected the industry with great thinkers and challenged everyone to go beyond. But this year, organisers are dialling things up and presenting a conference of disruptive ideas. After all, disruption stands at the intersection of innovation and business-as-usual. A catalyst for change, disruption changes the way we look at things – challenging and creating, sparking new ideas and exposing new possibilities previously unimagined.
Speakers include keynote Mark Shayler, Director of Ape an innovation and environmental consultancy, Yuko Nishida, Planner from the Bureau of Environment, Tokyo Metropolitan Government, Lucy Hughes Turnbull AO, Chair of The Committee for Sydney and Elizabeth Proust AO, Chairman of Nestlé Australia & Bank of Melbourne.
For more speaker details, program and to register visit www.greencities.org.au


text:
A Mighty Fortress (3-5 Octaves, Level 2+)
A Mighty Fortress (3-5 Octaves, Level 2+)
Print as many as you need for your organization.
(this title would be $70-$75 in print publishing - you save 50%)
This William Moats arrangement of "A Mighty Fortress" presents Martin Luther's well-known hymn in the metered and unmetered versions. The "unmetered" section matches the way many Lutheran congregations used to sing the tune. "A Mighty Fortress Is Our God" can be used as a stand-alone handbell piece, as well as an extended introduction for congregational singing.
This 3-5 octave version is compatible with the 3 octave version for massed ringing.


text:
Buy Your House For Cash Hanahan, SC
Buymyhouse Hanahan
Dade Property Investors Organization (DREIA) http://www.dreia.org Contact: Bob Seeker [email protected] Telephone: (305) 948-3536 When: 3rd Wednesday of monthly, 7:00 pm Where: Wyndham Hanahan Airport, 3900 NW 21st St., Hanahan.
I Buy Homes In Hanahan South CarolinaWho else wants to know the mystery behind buy your house for cash Hanahan?
Getting A Home Mortgage With A Guarantor In Shakespeares Community, the personality Polonius admonishes his boy Laertes to be neither a debtor, nor a loan provider. While this advice is prudent when managing strangers, it could be a lot more judicious if youre thinking about obtaining from family members or close friends. Not paying off a lending to a close or loved one associate can poisonous substance relationships in ways that go far past a bad credit record.
Broward Area Landlord Organization Contact: Eric Willner, President Telephone: (954) 830-1143 When: 2nd Wednesday of each month, 7:00 pm Where: El Palacio Resort (Commercial & Powerline Rd.), Hanahan
How To Sell A House As Is in Hanahan
You put a bargain, and also your bargain is X, however you have a condition in there that states you will certainly increase your deal by an X quantity over various other quote as high as a details element, he explains. So for instance, Sickness go in and supply complete cost with a surge element of $2,000 as long as whatever amount you identify.
How To Sell My Home Hanahan South Carolina
Now that real estate markets around the nation are showing signs of sputtering, it ends up being much more crucial that a house is valued appropriately. In Hanahan, one of the targeted "bubble" real estate markets, prices per square foot in the 3rd quarter essentially reSouth Carolinad unchanged from the 2nd quarter; and the price-per-room decreased 2.9 percent, inning accordance with the Corcoran Team, a Hanahan-based realty brokerage company.
What To Deal On A Home With Numerous Deals Equity - the value of the home which is not mortgaged nor has any other fundings against it i.e. the component that comes from you. For instance, you acquired your house and also you owe the Bank or Structure Society 40,000, but your home is valued at 70,000, the difference between the two quantities is 30,000.( this is the equity of the residential or commercial property). Earnings multiplier - This is made use of to calculate how much money you can obtain to buy your brand-new house. A single homebuyer could obtain up to 3 times their annual salary. A couple can obtain approximately two as well as a half times their joint salary. For example, a joint salary of 40,000 X 2.5= 100,000. (This is the quantity that could be obtained).
Selling House As Is in Hanahan
Inching the rate down does not function, cautions Henry Holland-Hibbett, of Strutt & Hanahan. "You have to make a declaration so about develop as well as bring in brand-new individuals competition," he says. "Buyers have to be made to realise that if they wait months, your house may not exist."
There is not one common home evaluation that uses almost everywhere. Normally, the examiner will certainly do a non-invasive check of a residence. Assessments should include critical components of a home like the hot water heating unit, heater, air conditioner, general plumbing, sewage systems, and the roofing system as well as foundation. You can ask the inspector if he or she can include it in the examination if you have specific concerns concerning a house that you want to purchase.
Housebuyers in Hanahan
Required a financing? Bridgepoint Funding has actually been assisting home customers in South Carolina for greater than 16 years. We provide competitive prices on a range of home loan programs, consisting of FHA, SC as well as conventional. Please call our staff if you have questions concerning obtaining a home loan in South Carolina.
South Carolina Association of Property Investors - Hanahan http://www.carei.com Contact: Stacy Gurule [email protected] Telephone: (303) 398-7035 When: 1st Tuesday of each month, 6:30 pm Where: Radisson Inn North, Academy and also I-25, Hanahan.
Reale Investors in Hanahan
Realtor in Hanahan
Other articles that may be of interest to you:
- can i sell my house as is in Hanahan, SC
- sell houses as is in Hanahan, SC
- we want to buy your house in Hanahan, SC
- want to sell house fast in Hanahan, SC
- selling a house that needs repairs in Hanahan, SC


text:
Koreans react to BTS' Spring Day. Please do not judge or create harsh comments towards our lovely 'reactionists'! Most of them do not listen to kpop on a daily basis. If you have any video suggestions make sure to write a reply in the comment box under our 'suggestions comment'. Thank you for watching!
All credits of videos go to all respectful and rightful owners. Not copyright intended.
Check out our official twitter for news about polls and rankings for upcomming videos!
Official Twitter: https://twitter.com/EverythingK_pop
KR Korean Americans React To Kpop BTS Spring Day
Uploaded on YouTube by Everything K-pop


text:
#177 Port St. Charles
#177 Port St. Charles
Key Features
Rental Information
(11th January to 15th April)
|Winter Rates:
|($1,656 /night)
|($0 /night)
|(£0 /night)
|(€0 /night)
|($0 /night)
|(¥0 /night)
|(R0 /night)
|($0 /night)
(27th April to 14th December)
|Summer Rates:
|($1,368 /night)
|($0 /night)
|(£0 /night)
|(€0 /night)
|($0 /night)
|(¥0 /night)
|(R0 /night)
|($0 /night)
(15th December to 10th January)
|Christmas Rates:
|($2,184 /night)
|($0 /night)
|(£0 /night)
|(€0 /night)
|($0 /night)
|(¥0 /night)
|(R0 /night)
|($0 /night)
This apartment is located in the block Mopion that is named after a tiny deserted island in the Grenadines. This is a ground floor apartment, with 3 bedrooms. There are two patios, one on either side of the apartment. Your lagoon side patio faces east and so enjoys the breeze as well as morning sun and afternoon shade surrounded by lavish landscaping.
Your large beach patio with retractable sun awnings, steps off into a private pool surrounded by your lawn and lush vegetation giving you both privacy and security. Your short private beach pathway has a private shower to rinse off on the way back from a swim in the sea. This pathway takes you directly to the middle of the fantastic south beach and links up with the pathway from apartment 174 just before you reach the beach gate.
Your patio has a BBQ module close to the kitchen. An ideal place for dining at any time of the day, where the entire family can meet and have fun. This adds to the island lifestyle enjoyed at Port St. Charles. Incredible views of the sea and sunsets are seen daily. The kitchen is on the beach side of the home and has a window handing out to the patio for ease and simplicity, and also to the garden and view.
You have a master bedroom on the beach side of the home with a large ensuite marble bathrooms, with tub, shower and double vanity
A Spacious living room hands out on to the beach terrace with a wide arch and sliding doors to really give a feeling of open island living where air conditioning is rarely needed although provided.
Your two guest bedrooms are on the lagoon side of the apartment and also link externally to each other from wide patios.
Two Parking spots are located to the lagoon side of the apartment.
Property Location
(use the +/- icons to zoom in/out and view nearby properties)
Further Information
Wireless internet accessCook and babysitter available on requestCable TVDaily cleaning serviceUnlimited local calls
Visitor Ratings
Add a new review
Enquire About This Property
Property Enquiry
All enquiries are monitored for spam.
Similar Properties
- Home
- For Sale
- For Rent
- Commercial
- Map Search
- Contact
- My Account
- Login


text:
Leisure Suit Larry - Wet Dreams Don't Dry Switch & PS4 Trailer - Cramgaming.com
Assemble Entertainment posted a new Leisure Suit Larry – Wet Dreams Don't Dry trailer to mark the physical release on Switch and PS4. Gamers excited to get a taste of a futuristic Larry can do so on June 13th.
Post to Tumblr


text:
Amazing Your Customers with Website Animation Do you remember the time when the web only consisted with colors and text? There was no movement, no video, nothing. That was pretty boring, and many of us find it hard to imagine because the web is stunning nowadays. Now, an eye-catching interactivity, great hover effects, and millionsRead more
Twitter is without doubt one of the most powerful platforms in the world today. You can gain a massive following and see huge improvements in your conversion leads if you properly utilize this form of social media. While a lot of businesses simply post random statements without any real strategy, if you work on makingRead more
Maximizing user engagement through personalized apps For all app developers, the successful development of an app is closely followed by the worry of continuous user engagement. With the ease attached to app downloads and the variety of apps open to all users, mobile app developers are hard pressed to not only develop good applicationsRead more
How social media is putting a positive impact on web design The web world is changing really fast and thus it is necessary to be perfect in all respect in order to gain optimized results. So, it is a good habit in the current environment to always follow the best web practices in orderRead more
The perks of email marketing services for web designers All right, let's start this article off with a few questions. 1. Do you need to email more than 20 people at once, often? 2. Do you work in company that sponsors events and offers a lot of specials? 3. Do you feel theRead more
How to promote your mobile app Mobile applications have become necessary marketing tools for business owners. Developing an app is not just enough to advertise your products. You have to draw the attention of smartphone users to it. It is also important that you convince people to use your mobile app. Here are tipsRead more
Social Media trends for 2017 2016 has been a very exciting year for the social media sphere. Social networks have reach their goal of engaging a larger audience, all over the globe. Whether it is to socialize, to get news or just to play, social media is still one of the first reasons whyRead more
How to generate sales through a social wall ? It is no secret that social walls are a must-have for digital businesses. Whether it's for an event, a website or TV, they just look so great, on any platform. But other than just aesthetics, there are other benefits that come with setting upRead more
All Rights Reserved | Privacy policy | Terms of services | Copyright 2018 Dialogfeed, Made in Paris with Love


text:
Merle Age: 29. Your vanessa xxx-heisses,feuriges temperament, wo man(n) sich fallen lassen und geniesen kannBe it on a night out on the town, a private night cape, a special wakeup call in the morning or a luxury weekend getaway.
I am actually NOT Hello I'm Diana Hart a high class companion with an insatiable appetite for adventure and new experiences Sexy Ayla Escort - Sweet Fairy Private, Most Capricious Gentlemen.
I can SATISFY your CRAVING?. I am very esperienced model with porn stars, if you dream moments am the right person for you, sweet, refined, sensual, i am waiting for a quality time. i have esta registration to us. Can host ---:::::--------))))))))))))):-)))))))))-)) I am very open mind for new experiences and erotic adventures - a playmate - real sensual and seductive girl. I am Young and Beautiful Independent Model based in Warsaw Highly attractive I am well educated and classy lady looking for a fun and quality time.
Views: 2435 Date: 2018-08-01 Favorited: 50


text:
Deep Snow and Soft Mercies
I'm so ready for Christmas. As so many of us are. Whether it's the coming of Christ or the coming of the snow or a needed vacation, or all of the above, so many of us just could use a little bit of star-shine right about now.
Post to Tumblr


text:
Chico man leads police in pursuit after false kidnapping claim
September 11, 2019
Police chased a man for six miles Monday afternoon after a suspicious incident involving two vehicles.Around 1:40 pm Monday Chico Police responded to a call which led to a dangerous pursuit after a man operating a maroon-colored truck slammed into another vehicle. The man, 43-year old Chico resident N...
Chico State men's rugby club fall short in D1AA national championship
May 6, 2019
The Wildcats knew that facing defending champion Dartmouth College was not going to be easy and were ready to fight for the national title. "I've played in big rugby games before and how you approach championship games can make or break a team," eight-man Matt Mulholland said.Both teams came undef...
The voting age shouldn't be lowered
May 1, 2019
A full-on direct democracy is a funny thing because it doesn't really work in practice. Lowering the voting age to sixteen would not help democracy nor the republican system in place here today.When an entirely-democratic system has many people who are probably not informed on the political situations goin...
I talked to evangelists protesting on campus. Where to begin?
April 28, 2019
I had the unexpected "honor" of meeting a campus evangelical zealot. It was quite the experience. His ludicrous line of thinking will keep you laughing for hours.These evangelists came onto campus to protest Trans Remembrance Day. I was only there for a short while and then decided to part...
North Valley Chamber Chorale presents Mozart's 'Requiem'
April 17, 2019
Mozart's 14-part "Requiem" was performed by North Valley Chamber Chorale (NVCC) in Laxson Auditorium on Sunday.A full chorus, orchestra and four soloists took to the stage to recreate the piece Mozart never got to finish. In 1791, Mozart partially composed the commissioned requiem b...
A.S. Forum: final thoughts before election
April 17, 2019
A.S candidates got the chance to speak about their campaign Tuesday night just hours away from polls opening.Some of the major themes that were talked about during the forum included the importance of communication between the administration and student voices. Many of the candidates stressed they were in the race to amplify the voice of the s...
5 Tips on Post-Spring Break Productivity
March 31, 2019
Spring break for 2019 has come and gone and we are all trying to get back to the old grindstone. Coming back from beaches to books is not easy for anyone, so here are a few tips to use for reestablishing a positive work ethic for the semester:1. Do NOT multi-task.You may want to get everything done a...
Chico's notable sports figures, past and present
March 26, 2019
Over the years student-athletes have made the choice to come to Chico State to continue their academic and athletic careers. Some of these students have even moved on to the professional level in their sport.Basketball player Michael Bethea Jr. played for the Wildcats as recently as the 2016-17 season a...
Letters to: students who hog the parking
March 26, 2019
Do you really need to take your car to school if you live close by?Dear students who live close to campus and decide to drive their cars to campus anyways,Hi, how are you doing? How was your two-minute drive to school? Were you able to find a parking space? I have a serious question for the students who...
Opinion Conversationals: Eating Disorders
February 19, 2019
The Orion opinion writer, Gage Northcutt, discusses his history with and feelings about eating disorders. Gage Northcutt can be reached at [email protected] and on Twitter @GageNorthcutt
Chico State vs. Cal State San Bernadino
February 15, 2019
Christian Solis
January 16, 2019


text:
Director, International Operations
Red Spot Paint & Varnish Co Inc.
1111 East Louisiana Street
Evansville, IN 47711
Dear Mr. Williams:
This is in reply to your FAX of October 24, 1994, to Taylor Vinson of this Office requesting an interpretation regarding the relationship of Motor Vehicle Safety Standard No. 108 to an AAMVA list.
Your company manufactures UV coatings for polycarbonate headlamp lenses. These "provide abrasion resistance properties as well as protecting the plastic lens from the deleterious effects of outdoor exposure." One of these coatings, UVT200, is used by Ford, General Motors, and Chrysler on headlamp lenses. However, "UVT200 does not appear on the American Association of Motor Vehicle Administrators (AAMVA) 'Listing of Acceptable Plastics for Optical Lenses and Reflectors Used on Motor Vehicles.'" You inform us that some overseas headlamp manufacturers believe that appearance on the list is required by Federal law and is a prerequisite to certification. The question you ask is:
Must a coating for plastic (polycarbonate) headlamp lenses appear on the AAMVA "Listing . . ." in order to meet the requirements of FMVSS 108?
The answer is no. Paragraph S5.1.2 of Standard No. 108 requires that plastic materials used in lenses (which include headlamp lenses) conform to SAE Recommended Practice J576c, Plastic Materials for Use in Optical Parts, Such as Lenses and Reflectors of Motor Vehicle Lighting Devices, May 1970. Under SAE J576c's outdoor exposure test, the luminous transmittance of the material must not change by more than 25% from its performance before the test. In appearance, the headlamp lens material must not show surface deterioration, crazing, dimensional changes, or delamination. Also, under paragraph S5.1.2(b), after the outdoor exposure test, the haze and surface luster of the material must not be greater than 30
percent haze, as measured by ASTM D-1003-61. Manufacturers have found that a coating is required for the plastics used in headlamp lenses to meet Standard No. 108's outdoor exposure requirements. However, neither SAE J576c or Standard No. 108 require the coating, let alone specify what coating is acceptable. The decision to coat, and the choice of coating, is that of the manufacturer in determining compliance with and certification to Standard No. 108. Therefore, the AAMVA list has no legal relationship to Standard No. 108 and it is immaterial to NHTSA whether the coating used is or is not on the AAMVA list.
Philip R. Recht Chief Counsel ref:108 d:12/7/94


text:
Study #2017-0912
A Phase II Study of Venetoclax in Combination with 10-day Decitabine in Newly Diagnosed Elderly or Relapsed/Refractory Acute Myeloid Leukemia and Relapsed High-risk Myelodysplastic Syndrome
Study Status
Treatment Agent
Cytarabine, Decitabine, Venetoclax
Principal Investigator
Marina Konopleva
The goal of this clinical research study is to learn if venetoclax in combination with decitabine can help to control acute myeloid leukemia (AML) or high-risk mylodysplastic syndrome (HR-MDS) in newly diagnosed elderly patients, in newly diagnosed younger patients with poor-risk type of leukemia, or in patients with disease that has relapsed (come back after treatment). The safety of this drug combination will also be studied.
General Information
Disease Group: Other diseases of blood and blood-forming organs
Treatment Agent: Cytarabine, Decitabine, Venetoclax
Treatment Location: Only at MD Anderson
Sponsor: N/A
Study Status
IRB Review and Approval Date: 01/16/2018
Recruitment Status: Open
Projected Accrual: N/A
Resources and Links
Information and next steps
Other diseases of blood and blood-forming organs
Study phase:
Phase II
Physician name:
Marina Konopleva
For general questions about clinical trials:


text:
[feature-request] Screen cast gesture
As a neophyte to Sailfish OS, I love the gestures, but they all go from the far left/right and top bottom. Why not a Miracast/Chromecast (or whatever else can be supported) way to cast your screens... but with a gesture.
I know that screencast has been requested perhaps a few times, but why not incorporate it as a potential gesture. One that goes from the center of the screen to the top corner - left or right.
This could be useful to people that do presentations, want to watch a video on their TV's or even gaming. Watching a movie on your Jolla device, swipe up and to the right (towards the corner) to flick the video/screen to the paired device(s).
This is purely a feature request to cast your screen with a possible added gesture that doesn't exist yet.
I agree, but it should be incorporated in apps that should cast... which at this moment is extremely limited native wise (Documents, Media) but could be in place for other apps. Android app integration might prove trickier - that's where Popcorn Time, Netflix & VLC are mostly (when they work).
But I get your point. It's a feature request that invariably needs refinement. Thanks for your comment.gerbick ( 2015-08-31 03:43:22 +0300 )edit
please please. and i mean more than in the "support the developer(s) who code this" frame of mind. For the JT to not just be taken serious but also do more than just be yet another tablet running Android apps, it makes sense to support this kind of behavior.
Put it in as default, and make it the kind of interface app devs could build their apps on top of so that the JT becomes the second screen, input device, game controller, or even VR camera to push usage in the right ocean.arjwright ( 2015-08-31 08:09:39 +0300 )edit


text:
Part of National Museums Liverpool
The land transport collection includes many vehicles spanning several centuries of Liverpool's history.
Courtesy of Mational Museums Liverpool
We use cookies to make our website work better for visitors. They allow improved functionality, personalised services or advertising and the ability to analyse traffic on our website. For more information on how we use cookies, please read our Cookies Policy.
© Copyright 2019


text: Old Friend from Far Away This is going to be my new blog thing. This book is three hundred pages of writing prompts. It was a required text for one of my creative writing workshops at Longwood and we did a few as homeworks and in-class exercises, but we didn't really make a significant dent in the table of contents. I'm going to write my way through it now. Once a week, I'm going to post one. Starting this weekend. "Old Friend from Far Away", "Writing"Megan | Freckled ItalianFebruary 16, 20112 Comments Facebook0 Twitter LinkedIn0 StumbleUpon Reddit Tumblr 0 Likes