One document matched: draft-barnes-atoca-escape-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-barnes-atoca-escape-02.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="ESCAPE">Encoding of Secure Common Alert Protocol Entities
(ESCAPE)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Parkway</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>US</country>
</postal>
<phone>+1 410 290 6169</phone>
</address>
</author>
<author fullname="Andrew Chi" initials="A." surname="Chi">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>10 Moulton St</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<phone>+1 617 873 2574</phone>
</address>
</author>
<date year="2012"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<area>RAI</area>
<workgroup>ATOCA</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>atoca, alert, emergency, s/mime</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Recipients of emergency alerts need to be able to verify that an
alert they receive was issued by an authorized source. The Common
Alerting Protocol (CAP) provides a standard way of encoding alert
information. This document describes a security wrapper for Common
Alerting Protocol objects to allow alerts to be signed by alert
originators.</t>
<t>Please send feedback to the atoca@ietf.org mailing list.</t>
</abstract>
</front>
<middle>
<section anchor="intro-sec" title="Introduction">
<t>Emergency alerting is an increasingly important function of
telecommunications networks, allowing authorities to distribute warnings
of impending danger to large numbers of end users in a short period of
time. However, because emergency alerts are such important messages to
users, there is much more potential for abuse of alerting than other
messaging systems. If an attacker can introduce a false emergency alert,
he may be able to cause mass action, such as the evacuation of a
building or city.</t>
<t>Traditionally, the security of alerting systems has been based mainly
on the security of the system by which authorities provide alerts to
broadcast points, and on the link-layer security of broadcast media that
deliver alerts to end users. For example, alerting systems for cellular
networks typically rely on sending alerts over the cellular control
plane, so that only the local carrier can deliver alerts to an end
device. Alerting via broadcast media such as television or radio is
protected by legal limitations on the ability to transmit above certain
power thresholds in portions of spectrum used for broadcast media (e.g.,
television stations).</t>
<t>In the context of the Internet, it is impossible to rely on
link-layer security because IP runs over many types of link that have no
analogous access controls. Indeed, alerts may transit multiple different
types of network en route to end devices. For example, if an alert is
delivered to a device that routes between cellular, Ethernet, and 802.11
interfaces, the router may need to translate an alert delivered by the
cellular control plane into an IP datagram that can be delivered over
Ethernet or 802.11. There is thus a need for an end-to-end security
mechanism for alerts, so that an endpoint can verify that an alert is
authentic even if the alert arrives over an untrusted interface.</t>
<t>This document describes ESCAPE, a secure container format for the
Common Alerting Protocol (CAP) <xref target="CAP"/>. CAP documents
provide information about an emergency alert; ESCAPE-wrapped CAP
documents also provide security information that can authenticate the
originator of the alert. Using this additional information, end alert
recipients can verify that ESCAPE-wrapped alerts were originated by
entities they trust, and reject false alerts from untrusted
entities.</t>
<t>Note that ESCAPE validation is not a complete security solution for
alerting. ESCAPE validation will authenticate the originator of an
alert; it is up to the device to determine whether the originator is
trusted. In general, this will require that devices be provisioned with
credentials for trusted entities, either via manual provisioning (e.g.,
static keys in device firmware) or by some dynamic provisioning
protocol. </t>
<t>Likewise, ESCAPE validation only proves that an alert came from an
authorized originator, not whether the alert is relevant to the
recipient in a more general sense. For example, the recipient may be
outside the target area of the alert (as described by the <spanx
style="verb"><area></spanx> element of the CAP document). Alert
applicability involves more than authenticity: it includes location,
jurisdiction, and possibly other locale-specific factors. Other
specifications may make additional requirements on the contents of CAP
documents, or require endpoints to make checks on encoded CAP document
beyond the basic validity check required by this document.</t>
<section title="Provisioning Requirements">
<t>For purposes of this document, we assume that potential recipients
of ESCAPE objects can be provisioned with two types of credentials:
public keys and "alert token hashes". A public key for an authority is
used to validate digital signatures by that authority. Alert tokens
provide a faster rough authentication. </t>
<t>An alert token is a single-use binary string that is used as a fast
authentication check, according to the process described in <xref
target="RFC2289"/>. Clients are provisioned with a cryptographic hash
that was produced by multiple iterations of a hash function against a
secret binary string. Although the final hash is published to
recipients through some provisioning process, the sequence of
preimages, including the original secret string, are known only to an
authorized server. These preimages are used in reverse order as the
alert tokens. On receiving an alert token, a client hashes it one or
more times to verify that it is indeed a preimage of the publicly
provisioned hash, or optimally, the immediate preimage of the latest
alert token. (Thus, alongside alert tokens, the provisioning system
must specify the hash function used to verify the alert token as well
as an iteration limit.) The detailed steps for verifying an ESCAPE
object using a collection of provisioned public keys and alert tokens
is described in <xref target="sec-sec-verify"/>.</t>
<t>The high-level operation of an ESCAPE-based alerting system can be
summarized as follows:</t>
<t><list style="numbers">
<t>Endpoints are provisioned with public keys and/or alert token
hashes for authorities.</t>
<t>When an authority wishes to generate an alert, it includes an
alert token and signs it using its private key (<xref
target="sec-sec-sign"/>)</t>
<t>The alert is distributed to one or more endpoints.</t>
<t>Along the way, an intermediary may add a signature to the
object (<xref target="sec-sec-re-sign"/>).</t>
<t>When the alert arrives at an endpoint, the endpoint validates
the signature and alert token (<xref target="sec-sec-verify"/>).
If both are valid, it renders the alert to the user.</t>
</list></t>
<t>This document defines procedures for generating, re-signing, and
verifying alerts (steps 2, 4, and 5 above). The mechanisms used for
provisioning trusted credentials (step 1) and for the actual delivery
of alerts (step 3) are beyond the scope of this document.</t>
</section>
<section title="Open Questions">
<t>Should we always apply GZIP to the entire encoded message? Pro:
Slightly smaller message size. Con: Will need to require GZIP for all
messages or add content transfer encoding indication.</t>
<t>Should we allow DER-encoded CAP as well as XML-encoded CAP? Pro:
Smaller message size. Con: Clients need to support two encodings,
although MIME content indication allows simple switching.</t>
<t>Should we constrain crypto algorithms? Pro: Marginally simpler
implementation. Con: Need to maintain a list of supported algorithms.
Could also do this in another document.</t>
<t>Should we require a public-key signature, or allow reliance on
token checks alone? Pro: Enables cases with no public-key operations.
Con: Risk of replay attacks using old tokens.</t>
<t>Should we move the Alert-Token field from the inner (signed) MIME
entity to the outer (unsigned) MIME entity? Pro: Allows relays to add
tokens. Con: Allows relays and attackers to remove or change
tokens.</t>
<t>Should we use JOSE instead of S/MIME? Pro: Simpler to implement;
might make it easier to have multiple, detached signatures with their
own alert tokens. Con: Less mature, fewer libraries.</t>
</section>
</section>
<section anchor="def-sec" title="Definitions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="ESCAPE Encoding">
<t>The ESCAPE format encapsulates a CAP document as an S/MIME object
<xref target="RFC5751"/>. First, the CAP document is encoded as a MIME
entity <xref target="RFC2045"/>, then the MIME entity is signed using
S/MIME.</t>
<section title="Basic MIME encoding">
<t>CAP XML documents have MIME type "application/cap+xml". An alert
originator may choose to apply the gzip compression scheme to the
alert before sending it. If the alert is compressed, the originator
must encode the compressed alert using the base64 encoding scheme
before transmitting it <xref target="RFC1952"/><xref
target="RFC4648"/>. A CAP MIME body thus has the following
properties:<list style="symbols">
<t>A "Content-Type" header field MUST be present, with the single
value "application/cap+xml".</t>
<t>A "Content-Encoding" header field MAY be present. If present,
it MUST have the value "gzip", and there MUST be a
"Content-Transfer-Encoding" header with the value "base64".</t>
<t>The body of the MIME entity MUST be a CAP document, either
directly, or processed through the gzip and base64 encodings.</t>
</list></t>
</section>
<section anchor="sec-alert-token" title="Alert Tokens">
<t>ESCAPE introduces a new MIME header, Alert-Token, which provides a
rough form of authentication. If alert recipients are configured with
an algorithm for checking the validity of a token, along with the
appropriate authentication material, the recipient of an alert message
can check the validity of the value in the Alert-Token field before
performing full S/MIME validation on the ESCAPE object. The
Alert-Token field contains a single opaque binary string, encoded in
base64. The ABNF syntax (<xref target="RFC5234"/>) for the field is as
follows, where "base64" is as defined in <xref target="RFC4566">RFC
4566</xref>. (Here we also follow the usual conventions with regard to
whitespace in MIME headers.)</t>
<figure>
<artwork><![CDATA[
Alert-Token = "Alert-Token" ":" base64
]]></artwork>
</figure>
<t>An ESCAPE MIME entity MAY contain one or more Alert-Token header
fields. Any header fields other than "Content-Type",
"Content-Encoding", "Content-Transfer-Encoding", and "Alert-Token" MAY
be ignored by alert recipients.</t>
<t>The Alert-Token authentication system implements an iterative
hash-preimage scheme based on the same technique used by Lamport's
One-Time Password system <xref target="RFC2289"/>. Such a scheme can
provide rough authentication when the communication channel is
adequately integrity-protected (e.g., by the signature on the ESCAPE
object).</t>
<t>The Alert Originator, such as a government authority, first
generates a sequence of one-time-use alert tokens, which are initially
kept secret, known only to the Alert Originator. To do so, the Alert
Originator chooses an iteration limit (n), and computes a hash chain
starting from a secret binary string (s), and iteratively applies a
cryptographic hash function (h) up to n times:</t>
<figure>
<artwork><![CDATA[
s, h(s), h^2(s), ... , h^(n-1)(s), h^n(s)
]]></artwork>
</figure>
<t>The final hash, h^n(s), is publicly provisioned (out of band) to
the clients, along with the iteration limit, n. All previous elements
of the sequence are initially kept secret by the authority for use as
alert tokens. Note that once a token in the above sequence is public,
so are all subsequent tokens. Each independent authority computes its
own sequence of tokens, so each authority provisions one ordered pair
(final_hash, iteration_limit) to the recipients.</t>
<t>When sending an emergency alert, the Alert Originator inserts an
alert token in an Alert-Token header in the ESCAPE message and
transmits the alert. The value of this token will generally be the
immediate hash-preimage of the previous alert token. An Alert
Recipient device receiving the message verifies the Alert-Token by
iteratively computing the hash value of the alert token until it
matches the most recent public hash, or until the iteration limit is
reached. If a match is found, then the alert token is considered
valid. Otherwise, the alert token is considered invalid.</t>
<t>To diminish the chances of replay, when the Alert Recipient
encounters a valid Alert-Token, it MUST update its record of the "most
recent public hash" and decrement the iteration limit. Replays of the
same token MUST be rejected.</t>
</section>
<section title="S/MIME Encapsulation">
<t>After a CAP message has been encoded into a MIME entity, an S/MIME
signature is applied, following the S/MIME procedures for constructing
a signed message of type "multipart/signed" (Section 3.4 of <xref
target="RFC5751">RFC 5751</xref>). The following constraints apply to
the S/MIME encoding used in ESCAPE messages.<list style="symbols">
<t>The ESCAPE message MUST have type "multipart/signed".</t>
<t>If the ESCAPE message contains header fields other than
"Content-Type", then they MAY be ignored.</t>
<t>The S/MIME body part SHOULD NOT include certificates for
signers, in order to minimize message size.</t>
<t>The S/MIME body part SHOULD identify signers by subject key
identifier (SKI) rather than by subject name, in order to allow
for both certified and uncertified public keys <xref
target="RFC5652"/>. If the SKI is used to identify signers, then
it MUST be equal to the 160-bit SHA-1 hash of the value of the BIT
STRING subjectPublicKey as specified in Section 4.2.1.2 of <xref
target="RFC5280"/>.</t>
</list>Except the constraints above, software to verify ESCAPE
alerts MUST include full S/MIME support, including all defined
cryptographic algorithms <xref target="RFC3370"/><xref
target="RFC5754"/>. Implementations MAY include additional algorithms,
but alert signers SHOULD NOT sign alerts with non-standard algorithms,
since some recipients may not be able to process them.</t>
</section>
<section title="Validity">
<t>An ESCAPE object is valid if and only if all of the following
conditions are true: <list style="symbols">
<t>If the verifying entity is configured with a valid alert token
hash for the cognizant Alert Originator, then there must be at
least one Alert-Token header field containing a valid token.</t>
<t>If the verifying entity is configured with trusted public keys,
then the S/MIME signature on the object must be valid, and must be
verified using a trusted public key.</t>
</list>An entity verifying an ESCAPE object MUST verify both of
these criteria, but MAY check them in either order and omit further
checks after the object fails one check. In particular, performing the
token check before decoding and verifying the CMS signature may avoid
the work of signature verification. </t>
<t>Note that the alert token mechanism is a much weaker form of
authentication than a public-key signature. For example, a malicious
actor that receives an alert token could use it to send bogus alerts
to entities that had not yet received it. An alert recipient that is
not provisioned with trusted public keys should thus treat alerts
verified only by an alert token as suspect (e.g., by providing
warnings in a user interface). A verifying entity SHOULD NOT accept
ESCAPE objects if it is configured with neither trusted public keys
nor valid tokens.</t>
</section>
</section>
<section title="Processing Rules">
<t>There are three main phases in the life-cycle of an ESCAPE object.
First, it is created and signed by an alert originator. Second, it may
pass through an alert relay that adds a signature under its key.
Finally, it is received and verified by an end recipient. This section
describes the steps that each type of entity follows to sign, re-sign or
verify an ESCAPE object.</t>
<section anchor="sec-sec-sign" title="Alert Originator (Signer)">
<t>Inputs:<list style="symbols">
<t>CAP document</t>
<t>Private key for signing, and corresponding subject key
identifier</t>
<t>gzip flag</t>
<t>Token hash sequence (possibly empty), with the index of the
most recently used token hash</t>
</list></t>
<t>Processing steps: <list style="numbers">
<t>Encode the CAP document as a MIME entity.<list style="letters">
<t>Add a "Content-Type" header field with value
"application/cap+xml".</t>
<t>If the gzip flag is set, add a "Content-Encoding" header
field with value "gzip" and a "Content-Transfer-Encoding"
header field with value "base64".</t>
<t>Add an "Alert-Token" header field and insert a previously
unused alert token, from earlier in the hash sequence than the
earliest used token. Update the "earliest used token"
index.</t>
<t>If the gzip flag is set, gzip the CAP document, then gzip
and base64-encode the CAP document and set it as the message
body.</t>
<t>If the gzip flag is not set, set the CAP document as the
message body.</t>
</list></t>
<t>Compute the signature over the MIME entity using the signing
key and create a CMS SignedData structure that identifies the
signer using the corresponding subject key ID.</t>
<t>Combine the CAP MIME entity and the computed CMS SignedData
structure into a "multipart/signed" S/MIME object.</t>
</list></t>
<t>Output: ESCAPE message</t>
</section>
<section anchor="sec-sec-re-sign" title="Alert Relay (Re-signer)">
<t>Inputs:<list style="symbols">
<t>ESCAPE object</t>
<t>Private key for signing and corresponding subject key ID</t>
</list></t>
<t>Processing steps:<list style="numbers">
<t>Extract the CAP MIME entity and CMS SignedData object from the
ESCAPE message.</t>
<t>Compute the signature over the CAP MIME entity using the
signing key.</t>
<t>Append the signature value and subject key ID to the CMS
SignedData object as a new SignerInfo.</t>
<t>Combine the CAP MIME entity and the computed CMS SignedData
structure into a "multipart/signed" S/MIME object.</t>
</list></t>
<t>Output: ESCAPE message</t>
</section>
<section anchor="sec-sec-verify" title="Alert Recipient (Verifier)">
<t>Inputs:<list style="symbols">
<t>ESCAPE object</t>
<t>Set of trusted public keys (possibly empty)</t>
<t>Set of trusted alert token hashes, with corresponding iteration
limits (possibly empty)</t>
</list></t>
<t>Processing steps:<list style="numbers">
<t>Extract the CAP MIME entity and the CMS SignedData object from
the ESCAPE message.</t>
<t>Check that the MIME headers for the CAP MIME entity have the
correct values. <list style="symbols">
<t>Content-Type must be "application/cap+xml"</t>
<t>Content-Encoding must be "gzip" or absent</t>
<t>Content-Transfer-Encoding must be present and equal to
"base64" if Content-Encoding is present, otherwise absent.</t>
</list>If any of these headers are invalid, then return the CAP
message is malformed. Return FALSE.</t>
<t>Extract the CAP entity body. If the Content-Encoding is "gzip",
then base64-decode and un-gzip the CAP entity body.</t>
<t>If the set of trusted alert token hashes includes a token hash
for the cognizant Alert Originator, then verify that the
Alert-Token values in the CAP MIME entity is a valid token, using
the algorithm described in <xref target="sec-alert-token"/>. If no
valid alert token is provided, then return FALSE.</t>
<t>If the set of trusted public keys is non-empty, then verify
that at least one of the SignerInfos within the CMS SignedData
object contains a valid signature under a trusted key. If no
valid, trusted signature is found, then return FALSE.</t>
<t>Return TRUE.</t>
</list></t>
<t>Output: Verification status</t>
</section>
</section>
<section title="Examples">
<t>Consider the following CAP message:</t>
<figure>
<artwork><![CDATA[
<?xml version = "1.0" encoding = "UTF-8"?>
<alert xmlns = "urn:oasis:names:tc:emergency:cap:1.1">
<identifier>43b080713727</identifier>
<sender>hsas@dhs.gov</sender>
<sent>2003-04-02T14:39:01-05:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Public</scope>
<info>
<category>Security</category>
<event>Homeland Security Advisory System Update</event>
<urgency>Immediate</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
<senderName>U.S. Government,
Department of Homeland Security</senderName>
<headline>Homeland Security Sets Code ORANGE</headline>
<description>The Department of Homeland Security has
elevated the Homeland Security Advisory System threat level
to ORANGE / High in response to intelligence which may
indicate a heightened threat of terrorism.</description>
<instruction> A High Condition is declared when there is a
high risk of terrorist attacks. In addition to the
Protective Measures taken in the previous Threat Conditions,
Federal departments and agencies should consider agency-
specific Protective Measures in accordance with their
existing plans.</instruction>
<web>http://www.dhs.gov/dhspublic/display?theme=29</web>
<parameter>
<valueName>HSAS</valueName>
<value>ORANGE</value>
</parameter>
<resource>
<resourceDesc>Image file (GIF)</resourceDesc>
<uri>http://www.dhs.gov/dhspublic/getAdvisoryImage</uri>
</resource>
<area>
<areaDesc>U.S. nationwide and interests worldwide</areaDesc>
</area>
</info>
</alert>
]]></artwork>
</figure>
<t>Suppose an alert signer has the following RSA key pair, encoded as a
PEM-encoded private key and self-signed certificate <xref
target="RFC1421"/>:</t>
<figure>
<artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAMqjkUYoHtH+uLPo
w3FNAlpHyT5BG0KWjN6hG7LUgh2GP+c2wmyavn9+ShwEe1CG9qgwa1apqNl/7BTY
UoRTCsSMlg43N+3X5OJSVHSALhR/IDcItf32jLUUD88lgKUoXI145GpeXRG3OARx
vA0ONhvC6MdSB0gW8jx/7Vz6q+mPAgMBAAECgYB2sqtlMhkjnxaoY/8f/iETqxsp
uU9ziOaJfkvQTATPsJT8JiprHZXa7qoQkVt+hyAy0vH9OLJsfS9X4oMrec1C22Jm
1EUqOqg+CXLye0OPSYckZukEPAt3EyQNBg4BIZFWC4ouKVcy0UECuL5X6oZ5Z5us
nMJ0wHI8n6ghiY620QJBAPFm6sNOOZqs0jFutbHWm5eQ7vbNynGYcm4S2v7Esnyn
GKy2iMf8MMiJjqmJiYQ47wn/Rm5rljNu/eTPNopcKhkCQQDW5JGsV6piWLN4fvg9
tpv0OG/mqJUBwjEejGg0LzupQiHociEg+cm+IPP61NX/MXoQXQIoFKcc6nXXq4rt
+PXnAkEAiurg2nefqqUdaJj/MlH/w98BxUFz6J8D6tgq8kWbOSSnjGyWlg9Iu359
fI7Ldi2VUbl3fH+pNfv/W7bq+gBDsQJBAMKNsa18uQ/NCr9/BLSqzUswhW8pFa6/
58SmjfkhAjzdWOGf4op+W749C2b+prgiTUbfTgKHoDy3sPUPo/qLueUCQQCdIdRB
3SrfM1gedy2h20RiFu6Ew1GCFSK2DUv60BcZJmbazVCNFQq8wBtHuqHew/7hxmtA
DtxHTLote/VHyOj7
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIICKTCCAZKgAwIBAgIJAIGuauj9u0i0MA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTExMDAzMjEzNDIzWhcNMTIxMDAyMjEzNDIzWjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDKo5FGKB7R/riz6MNxTQJaR8k+QRtClozeoRuy1IIdhj/nNsJsmr5/fkocBHtQ
hvaoMGtWqajZf+wU2FKEUwrEjJYONzft1+TiUlR0gC4UfyA3CLX99oy1FA/PJYCl
KFyNeORqXl0RtzgEcbwNDjYbwujHUgdIFvI8f+1c+qvpjwIDAQABoyEwHzAdBgNV
HQ4EFgQUKcxEepHj4Yr7+WDTS28DWxXcIvMwDQYJKoZIhvcNAQEFBQADgYEAVYsY
/ZghXf3TfAR6eW6MmQpzPR0oBO9JHjf4Wic87WkxCFPNW/pSIMO67ZoIOjU4b0Is
VOmcyPSHP8q0a0DS4f3rt9wF6VypcxLtaqkFD4lMRaoYNPvSwTSEBJj5yioPYsl7
OV5UgywTR5QueYK7YFyY+7gwUksTwtka6IIBlTk=
-----END CERTIFICATE-----
]]></artwork>
</figure>
<t>Then if the signer signs the alert with the above private key and the
token "foobar", he will create the following ESCAPE message:</t>
<figure>
<artwork><![CDATA[
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg="sha1";
boundary="----C16CFF6F1CB606631B8BBD4B5B43051F"
------C16CFF6F1CB606631B8BBD4B5B43051F
Alert-Token: asdfasdfasdf
Content-Type: application/cap+xml
<?xml version = "1.0" encoding = "UTF-8"?>
<alert xmlns = "urn:oasis:names:tc:emergency:cap:1.1">
<identifier>43b080713727</identifier>
<sender>hsas@dhs.gov</sender>
<sent>2003-04-02T14:39:01-05:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Public</scope>
<info>
<category>Security</category>
<event>Homeland Security Advisory System Update</event>
<urgency>Immediate</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
<senderName>U.S. Government,
Department of Homeland Security</senderName>
<headline>Homeland Security Sets Code ORANGE</headline>
<description>The Department of Homeland Security has
elevated the Homeland Security Advisory System threat level
to ORANGE / High in response to intelligence which may
indicate a heightened threat of terrorism.</description>
<instruction> A High Condition is declared when there is a
high risk of terrorist attacks. In addition to the
Protective Measures taken in the previous Threat Conditions,
Federal departments and agencies should consider agency-
specific Protective Measures in accordance with their
existing plans.</instruction>
<web>http://www.dhs.gov/dhspublic/display?theme=29</web>
<parameter>
<valueName>HSAS</valueName>
<value>ORANGE</value>
</parameter>
<resource>
<resourceDesc>Image file (GIF)</resourceDesc>
<uri>http://www.dhs.gov/dhspublic/getAdvisoryImage</uri>
</resource>
<area>
<areaDesc>U.S. nationwide and interests worldwide</areaDesc>
</area>
</info>
</alert>
------C16CFF6F1CB606631B8BBD4B5B43051F
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
MIIBxQYJKoZIhvcNAQcCoIIBtjCCAbICAQMxCTAHBgUrDgMCGjALBgkqhkiG9w0B
BwExggGTMIIBjwIBA4AUKcxEepHj4Yr7+WDTS28DWxXcIvMwBwYFKw4DAhqggdgw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDA0
MTUzMzM4WjAjBgkqhkiG9w0BCQQxFgQUG0dU/Z+LJg/29/4nvzkou4Bion4weQYJ
KoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl
AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBDIjpmJ2uP
nbFJqb35p7dGKdoWyh0Q0LUKr9SxOWkmvK9K6AB/Bodzlo1U5hGVqX10p7HqUWW9
SMt3DXB8sxSbEOrD0HUsdsQvmoulfWNAX5ZphS7jvy1LeR9qrYp8zyzUd1bWSOZA
kQKwpg6PRyVYArqG8uAD00CW0elL34WKLQ==
------C16CFF6F1CB606631B8BBD4B5B43051F--]]></artwork>
</figure>
<t>If the signer also applies the GZIP encoding and attaches the token,
he will create the following ESCAPE message:</t>
<figure>
<artwork><![CDATA[
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg="sha1";
boundary="----C6A0932DF53B0609D38DC49A7E492DB3"
------C6A0932DF53B0609D38DC49A7E492DB3
Alert-Token: foobar
Content-Type: application/cap+xml
Content-Transfer-Encoding: base64
Content-Encoding: gzip
H4sIADZhik4AA4VUW27bMBD8L5A7LPzVArUpJynSCopSI2keQF+onQMw5NoiQpE
CSdnx7bukJFtBi/ZL4nBn9sktrl5qDVt0XlkDlzCZz7IJoBFWKrOJwOPqdvpxcl
XCyZuCa3QBiGF8vGqdyS33yueG1+jzIHKs0W2Ivs8Fb/L5bD6JRCiURBPUWqErz
8+eso/Zxfzs4vSiYKMLgGTq0Ug6VZ77z7Lys43dFqwHjyahPM2ys2l2Ps1OV/Pz
/OxTns2n2Yc8y5J16Pz6wEPry4UILdd00R17mdpvVvsGy0VMq2DDsSMKS78/2ye
tBPHSqacps7bJCKAQPODGun25RNE6FfYFO0AAHYHMcBsjurc1am4kDMawkFvlyR
aWex+whsdGErtgnf1IoO2qWj7UNUqVbAZoZOWJF3UpGvrBWIgeGBkJSpYrQ+BX9
Yw6RnxAXmnFin+nxpaPs+UM7ixJmZriet9Z3GDDXYgA2DX8kdvQs6TQa1bIpVYG
/1KJJQYP11Yi/Pi1+H73pWAH454s0QunmkCDWq4q/J9/qLjvmKhxSxWTEIj1/x6
EyiEPQCTUiR9sHxMwuFebCpQBh76xxmO8pMqh1ip2A2FXKVFBzfedb2WkigMBHC
okbkCTAkkuKOyAzlmnfD0r2DjBPmdlfHCt6KBF5/3akmZEQHmQKDR3JLmr0MQEH
UaYd/wq2pP689hVAB4CF89+Bg8GuOzFKJFYn8T76WxA8rpF+Ibct5QtBP5MHlRy
Ao3DrbKth1WXySEm3w/HLVLruab4hiZRUFR1HqukSM5XttUSBFFoBbjuYj9NZN+
goJUg/hoHRcCFsE7yVG4VqhiRcn2vXyjBuLkaarKnor6q4DDbO3wqqxCanLHdbj
frtwyjb5MePJPKk8D+ipRrvDz9VLBI6dmUEc10iOsoAQRtuW4xTfr9crEs2PH82
qQchrs79YJspHh8gJSsbZ0YSQzIDQ0KbQIqGayVRnh793D7rmCvro9CaXuof+e7
wTA8g6Qbt4s6hHeM5BgdDR3vzmNHEU3u08owPJZ9R/1NvY/vhKRoEnbWaRnxgh0
YI23Wi8dly4ZtS2hc0+XJm9+QWcJ8tAYAAA==
------C6A0932DF53B0609D38DC49A7E492DB3
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
MIIBxQYJKoZIhvcNAQcCoIIBtjCCAbICAQMxCTAHBgUrDgMCGjALBgkqhkiG9w0B
BwExggGTMIIBjwIBA4AUKcxEepHj4Yr7+WDTS28DWxXcIvMwBwYFKw4DAhqggdgw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDA0
MDEyODIyWjAjBgkqhkiG9w0BCQQxFgQUh4vjrIyFiLJE0T6IK4OksdV+zBAweQYJ
KoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl
AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB4SiBnr3vC
T//nsi1NuSsb5/uSfBvJjtlTyr1SuqLaanqbeSoASflaqu6N/07LZpQI4m1PRq8V
Qa/4HO0IDLAuYlwdXUoHQWcqePla6WHTp4U6s358JFkr2bg47nZ6Sgr41MMdC+9P
OYWrmvTPTQOX/vbSUFAApJg4QP3O6PKunA==
------C6A0932DF53B0609D38DC49A7E492DB3--
]]></artwork>
</figure>
</section>
<section anchor="iana-sec" title="IANA Considerations">
<t>This document requires no action by IANA.</t>
</section>
<section anchor="sec-cons-sec" title="Security Considerations">
<t>This document defines a secure alert format that allows alert
originators to apply S/MIME digital signatures to a CAP alerts <xref
target="RFC5751"/>, and to enclose an additional rough authenticator
based on a one-time password scheme <xref target="RFC2289"/>. The
security considerations discussed in the specifications for those
security mechanisms apply here as well.</t>
<t>This document does not address the question of which signers or alert
tokens should be accepted as authorized alert originators. There is a
need for some out of band process for provisioning public keys and alert
token hashes to potential alert recipients. Obviously, if that process
can be exploited to cause alert recipients to trust an unauthorized
public key, then affected recipients will be at risk of accepting
inappropriate alerts under that public key (assuming the attacker can
deliver the alert to the recipient). The risk is lower with regard to
alert token hashes, because they are only used as a rough check to avoid
signature verification on obviously bogus alerts. If an attacker can
cause only unauthorized alert hashes to be provisioned as trusted, and
not unauthorized public keys, then he will only be able to waste
resources on recipient devices by forcing them to verify bogus
signatures.</t>
<t>Finally, a note on the choice of security technology. The CAP
specification does provide for alert signing, using XML-DSig. In this
document, we use S/MIME as a simpler mechanism for signing. Because
S/MIME signs over a serialization of an XML document rather than the
logical structure of the document, it does not require XML
canonicalization (as XML-DSig does). Using S/MIME also means that ESCAPE
can accommodate alerts that are not encoded in XML, such as DER-encoded
CAP alerts, both because the signature computation is agnostic to the
format of the signed content and because MIME provides content type
indication.</t>
</section>
<section anchor="ack-sec" title="Acknowledgements">
<t>[TODO]</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<reference anchor="CAP">
<front>
<title>Common Alerting Protocol v1.1</title>
<author fullname="" initials="A" surname="Botterell">
<organization/>
</author>
<author initials="E." surname="Jones">
<organization>J</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date month="October" year="2005"/>
</front>
</reference>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1421.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1952.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2289.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3370.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5754.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-atoca-requirements"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:26:58 |