Internet DRAFT - draft-hallambaker-securitypolicy
draft-hallambaker-securitypolicy
Internet Engineering Task Force P. Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended status: Standards Track R. Stradling
Expires: May 2, 2012 Comodo CA Ltd.
October 30, 2011
Security Policy Distribution Format (SPDF)
draft-hallambaker-securitypolicy-01
Abstract
This document describes a format for distributing collections of
security policy statments as static documents.
Individual security policy statements are expressed in a HTTP
compatible header syntax. Lists of security policy statements are
signed for exchange. Strong references to static data objects are
formed using Named Information (ni) URI specifiers.
Status of this Memo
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 http://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 May 2, 2012.
Copyright Notice
Copyright (c) 2011 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
(http://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
Hallam-Baker & Stradling Expires May 2, 2012 [Page 1]
Internet-Draft Security Policy Distribution Format October 2011
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.
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Risks . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1.1. Protocol Downgrade Attack . . . . . . . . . . . . 5
2.1.1.2. CA Downgrade Attack . . . . . . . . . . . . . . . 6
2.1.1.3. Use of Revoked Certificate . . . . . . . . . . . . 6
2.1.2. Security Policy Origination . . . . . . . . . . . . . 6
2.1.2.1. Explicit . . . . . . . . . . . . . . . . . . . . . 6
2.1.2.2. Heuristic . . . . . . . . . . . . . . . . . . . . 7
2.1.3. Distribution . . . . . . . . . . . . . . . . . . . . . 7
2.2. Security Policy Statements . . . . . . . . . . . . . . . . 8
2.2.1. Controlling Protocol Downgrade Attack . . . . . . . . 8
2.2.2. Mitigating CA Substitution Attack . . . . . . . . . . 10
2.2.3. Emergency Certificate Revocation . . . . . . . . . . . 10
2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Common Syntax . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2.1. dns-name . . . . . . . . . . . . . . . . . . . . . 11
2.3.2.2. date-time . . . . . . . . . . . . . . . . . . . . 11
2.3.2.3. protocol-id . . . . . . . . . . . . . . . . . . . 12
2.3.2.4. ni-uri . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2.5. data-uri . . . . . . . . . . . . . . . . . . . . . 12
2.3.2.6. tls-version . . . . . . . . . . . . . . . . . . . 12
2.3.3. Common Parameters . . . . . . . . . . . . . . . . . . 12
2.3.3.1. Domain=<dns-name> . . . . . . . . . . . . . . . . 12
2.3.3.2. Protocol=<protocol-id>* . . . . . . . . . . . . . 12
2.3.3.3. UTC=<date-time> . . . . . . . . . . . . . . . . . 13
2.3.3.4. Expire=<date-time> . . . . . . . . . . . . . . . . 13
2.3.3.5. Common . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4. Statement: CA-PIN: <ni-uri> . . . . . . . . . . . . . 13
2.3.4.1. Match= 'key' | 'csk' | 'cert' | 'path' . . . . . . 13
2.3.4.2. After=<date-time> . . . . . . . . . . . . . . . . 14
2.3.4.3. Before=<date-time> . . . . . . . . . . . . . . . . 14
2.3.4.4. Unpin=<ni-uri> . . . . . . . . . . . . . . . . . . 14
2.3.5. Statement: Unpin: <data-uri> . . . . . . . . . . . . . 14
2.3.6. Statement: Revoke: <uri> . . . . . . . . . . . . . . . 14
2.3.7. Statement: Action: <action> . . . . . . . . . . . . . 14
2.3.8. Statement: Report: <dns-name> . . . . . . . . . . . . 15
Hallam-Baker & Stradling Expires May 2, 2012 [Page 2]
Internet-Draft Security Policy Distribution Format October 2011
2.3.9. Statement: TLS: <level> . . . . . . . . . . . . . . . 15
2.3.9.1. min=<tls-version> . . . . . . . . . . . . . . . . 15
2.3.9.2. max=<tls-version> . . . . . . . . . . . . . . . . 16
3. Distribution Format . . . . . . . . . . . . . . . . . . . . . 16
3.1. Cryptographic Message Syntax Properties . . . . . . . . . 16
3.2. JSON Packaging . . . . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Hallam-Baker & Stradling Expires May 2, 2012 [Page 3]
Internet-Draft Security Policy Distribution Format October 2011
1. Definitions
1.1. Requirements Language
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 [RFC2119]
1.2. Defined Terms
The following terms are used in this document:
Certificate An X.509 Certificate, as specified in RFC 5280
[RFC5280].
Certification Policy (CP) Specifies the criteria that a
Certification Authority undertakes to meet in its issue of
certificates.
Certification Practices Statement (CPS) Specifies the means by which
the criteria of the Certification Policy are met. In most cases
this will be the document against which the operations of the
Certification Authority are audited.
Certification Authority (CA) An entity that issues Certificates in
accordance with a specified Certification Policy.
Domain The set of resources associated with a DNS Domain Name.
Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and
revisions.
Domain Name System (DNS) The Internet naming system specified in RFC
1035 [RFC1035] and revisions.
DNS Security (DNSSEC) Extensions to the DNS that provide
authentication services as specified in RFC 4033 [RFC4033] and
revisions.
Public Key Infrastructure X.509 (PKIX) Standards and specifications
issued by the IETF that apply the X.509 [X.509] certificate
standards specified by the ITU to Internet applications as
specified in RFC 5280 [RFC5280] and related documents.
Resource Record (RR) A set of attributes bound to a Domain Name.
Hallam-Baker & Stradling Expires May 2, 2012 [Page 4]
Internet-Draft Security Policy Distribution Format October 2011
Relying Party A party that makes use of an application whose
operation depends on use of a Certificate for making a security
decision.
Relying Application An application whose operation depends on use of
a Certificate for making a security decision.
2. Introduction
Recent compromises of critical infrastructure have highlighted the
weaknesses that result from the fact that on the Internet, security
is an option, not the default.
Security Policy provides a mechanism for advising parties of the
minimum degree of security that they should accept for a
communication and thus preventing downgrade attacks.
2.1. Requirements
Security Policy statements provide a mechanism for advising parties
of the risk of a downgrade attack and the enforcement actions that
are appropriate based on the quality of the security policy
information available.
While the natural inclination of security specialists is to advise
that a security policy violation always result in a hard failure with
the corresponding transaction being aborted, this approach imposes a
high cost for false positives. Previous attempts to employ security
policy data (e.g. in DKIM) have faced objections from those fearing
that the false positive rate will be unacceptably high.
Recent events have demonstrated that the value of reporting a
security policy violation is considerably higher than than security
policy enforcement on a limited scale. While security policy
enforcement has the potential to protect the individual Internet
user, reporting a violation to the appropriate parties has the
potential to protect the entire community of Internet users.
2.1.1. Risks
2.1.1.1. Protocol Downgrade Attack
In a protocol downgrade attack the attacker causes client software to
communicate en-clair when TLS or some other security enhancement is
offered.
Hallam-Baker & Stradling Expires May 2, 2012 [Page 5]
Internet-Draft Security Policy Distribution Format October 2011
2.1.1.2. CA Downgrade Attack
In a CA downgrade attack the attacker applies for a certificate from
a different issuer to that authorized by the Domain name holder or
for a category of certificate with lest strict validation
requirements.
2.1.1.3. Use of Revoked Certificate
Although PKIX specifies two mechanisms for certificate status
checking, many clients will accept certificates when access to the
certificate status checking infrastructure fails.
2.1.1.3.1. Use of Expired Certificate
Although use of expired certificates is discouraged, the frequency
with which use of expired certificates occurs from administrative
oversight prevents strict enforcement.
2.1.2. Security Policy Origination
Security policy statements may be obtained from explicit statements
by domain name holders or obtained heuristically from observation of
the network.
2.1.2.1. Explicit
A domain name holder MAY specify security policy explicitly through
publication mechanisms that include:
Publishing statements in Security Policy Distribution Format
Security Policy Statements in HTTP headers
Security Policy Statements in DNS records
Out of band contact with remediation parties.
Statements to a Certification Authority at certificate issue.
Even though a statement is explicit, an enforcement point may only
learn of its existence through heuristic means. For example
observing DNS traffic, use of Web crawlers and HTTPS inspection.
Publication of an explicit Security policy Statement requires a
considerable commitment of time and effort for a large site.
Hallam-Baker & Stradling Expires May 2, 2012 [Page 6]
Internet-Draft Security Policy Distribution Format October 2011
2.1.2.2. Heuristic
Security policy data MAY also be determined heuristically by
observation of network traffic. If a site has been using a
particular CA for many years and a certificate is suddenly detected
from an obscure issuer, questions may be asked.
While the quality of heuristic data may fall short of that required
to abort transactions by itself, it can still provide a useful basis
for reporting potential violations and for enforcement when combined
with data from other sources.
2.1.3. Distribution
Security Policy Statements set expectations for security, thus
overriding the Internet default security expectation of 'none'.
Security Policy Statements may be used to protect individual Internet
users through client enforcement and communities of users through
reporting.
A Security Policy Statments are designed to permit distribution
through a variety of means including:
Embedded in application code Many clients have security policy
statements embedded into the application code. For example code
to look for specific certificates that are known to be invalid.
While this is a highly effective means of enforcement it requires
users to upgrade their client software in response to every
compromise.
Local Configuration Files Some client applications support local
security policy configuration but the configuration options are
limited and there is no standard format for distributing the
configuration. A standard for specifying Security Policy
potentially allows every client application to enforce the same
security policy whether it be a Web browser, mail client or Web
Services application.
Data driven updates Data driven update of security policy overcomes
the principal limitation of security policy distribution through
embedded code and local configuration files. Security Policy can
be updated in response to threats and reliably enforced without
the need to perform online queries for each network operation.
The principal disadvantage being that it is only possible to push
out security policy statements for selected of domains.
Hallam-Baker & Stradling Expires May 2, 2012 [Page 7]
Internet-Draft Security Policy Distribution Format October 2011
Protocol Headers Distribution of security policy in protocol headers
overcomes the scaling limitation of data driven updates but only
provides security after first contact. If the attacker can
compromise the first contact they can compromise all subsequent
contacts.
DNS Records DNS provides a scalable means for distribution of
security policy statements through realtime query and response.
If the relying party can ensure a connection to a trustworthy DNS
service, they can protect their security but an attacker that can
block access to a trustworthy DNS service can force the relying
party to choose between security and availability.
Irregular Security Policy distribution is hard because the
adversaries encountered to date include nation state actors with
complete control of the local network infrastructure. It is thus
not possible to address every possible need in a standard based
approach since the adversary can block deployment of the necessary
standards.
It follows that standards based techniques SHOULD be supplemented
by resort to irregular methods where necessary.
Each distribution mechanism provides a tradeoff between scope,
effectiveness and resilience.
The formats described in this document is targetted at distribution
of Local Security Policy and as data driven updates. With
appropriate format the same semantics could be carried in alternative
distribution media such as protocol headers and DNS records.
2.2. Security Policy Statements
Security Policy Statements are used to inform relying parties that
host(s) support a particular level of security, thus permitting
relying parties to avoid downgrade attacks.
Security Policy Statement lists are formatted as a sequence of HTTP
format headers. Each header contains a single statement policy
statement.
2.2.1. Controlling Protocol Downgrade Attack
The TLS statement provides a control against protocol downgrade
attacks. The following statement specifies that every Web server in
the domain example.com offers the use of TLS security enhancement.
TLS: optional;Domain=*.example.com;Protocol=_http._tcp;
Hallam-Baker & Stradling Expires May 2, 2012 [Page 8]
Internet-Draft Security Policy Distribution Format October 2011
UTC=2011-10-25T17:23;Expire=2011-10-28T00:00
A security policy statement that advises relying parties that
security is always offers permits a 'promiscuous security approach'
to be adopted in which clients are advised that the default mode of
connection SHOULD be with TLS security enhancements.
When a domain is in the scope of multiple statements the principle of
closest match is applied. The following TLS statements specify
exceptions to the previous statement.
The following policy statement declares that use of TLS is REQUIRED
for the authentication server login.example.com, that clients MUST
perform strict HTTPS processing rules and that a minimum TLS version
of 3.1 MUST be used.
TLS: strict;Domain=login.example.com;Protocol=_http._tcp;
UTC=2011-10-25:17:23;Expire=2011-10-28T00:00;min=3.1
Action: Block ;Domain=payments.example.com;
UTC=2011-10-25:17:23;Expire=2011-10-28T00:00
Exceptions MAY also be used to specify a lower level of security.
This is useful when a broad security policy is being deployed in
stages and some hosts do not yet comply with the requirements.
The following statement specifies that the host test.example.com does
not have a defined security policy.
TLS: unknown;Domain=test.example.com;
UTC=2011-10-25T17:23;Expire=2011-10-28T00:00
A security policy statement MAY specify a user interface action that
relying parties are advised to take when a security policy violation
is detected. This may range from advising the relying party that
they MUST ignore the violation to advising them that they SHOULD
block all communication.
A security policy statement MAY provide a means of reporting security
policy violations. While client enforcement of security policy can
protect one user, reporting of a violation has the potential to help
protect the whole community. Such reporting is orthogonal to the
relying party action.
The following statement specifies that relying parties MUST ignore
security policy violations for all hosts in *.example.com except to
report them in machine readable format to the specified reporting
address. An action statement of this form would typically be used
during beta testing of a security policy deployment.
Hallam-Baker & Stradling Expires May 2, 2012 [Page 9]
Internet-Draft Security Policy Distribution Format October 2011
Action: Ignore ;Domain=*.example.com;
UTC=2011-10-25T17:23;Expire=2011-10-28T00:00
Report: security@example.com; format=iodef;Domain=*.example.com;
UTC=2011-10-25T17:23;Expire=2011-10-28T00:00
2.2.2. Mitigating CA Substitution Attack
The CA-PIN and UNPIN statements provide a controll against a CA
substitution attack.
The following statement specifies that the domain *.example.com is
under control against server certificate substitution attacks and
that X.509v3 certificates conformant with the specified criteria are
valid for that domain. If a certificate is presented for a host in
the domain that does not conform to the criteria specified in any
security policy statement in the enclosing Security Policy Statement
list it MUST be considered untrustworthy.
CA-PIN: ni:///sha-256;RpmvP1PSoV5788nW64mHZbkLinRVdZQi; match=path;
Domain=*.example.com; UTC=2011-10-25:17:23;Expire=2011-10-28T00:00
unpin=ni:///sha-256;2UADniDyBYLOISFHDCMdcbQpw3ctAI7o
The unpin parameter in the above statement contains the digest value
of a piece of data to be released to revoke the corresponding CA-PIN
statement.
The following UNPIN statement revokes the CA-PIN statement above by
releasing the private data used to create the unpin digest.
UNPIN: data:base64;RpmvP1PSoV5788nW64mHZbkLinRVdZQi;
pin=ni:///sha-256;2UADniDyBYLOISFHDCMdcbQpw3ctAI7o
2.2.3. Emergency Certificate Revocation
Although X.509v3 and PKIX specify mechanisms for advising relying
parties of the status of certificates, these approaches must by
necessity rely on access to the information sources used to
distribute the status information (CRLs, OCSP tokens).
Emergency Certificate Revocation advises a relying party that a
certificate has been found to be invalid and there is a very high
risk that the certificate will be used for a malicious purpose.
The following Revoke statement revokes the CA certificate that will
eventually be attached in an appendix.
Revoke: ni:///sha-256;6cNTPy-7cu9A0fnNuFSWaQXO9_Gmlf-T
Hallam-Baker & Stradling Expires May 2, 2012 [Page 10]
Internet-Draft Security Policy Distribution Format October 2011
2.3. Syntax
Encoding is 7 bit ASCII as for headers.
2.3.1. Common Syntax
All Security Policy Statements have a common syntax based on the
syntax used in HTTP and SMTP message format.
Forgetting about the traditional white space and line wrapping
considerations, the syntax has the format has the following common
syntax:
statement = header-tag ":" values
header-tag = token
values = principal-value *("," principal-value)
*( ";" parameter )
principal-value = dns-name | uri | quoted-string
parameter = attribute | attribute "=" value
attribute = token
value = token | quoted-string
WS = " " | tab
2.3.2. Data Types
Principal values and parameter values take one of the following
types.
2.3.2.1. dns-name
A DNS Domain name specifier. [cite]
A wildcard may be specified using the asterisk character '*'. Domain
names MUST not occur amywhere other than as leftmost label in a
domain name.
The form *.example.com is valid but sub.*.example.com,
www*.example.com and *x.example.com are invalid.
2.3.2.2. date-time
A Date-Time value in XML time value format
Time values MUST be in UTC.
Hallam-Baker & Stradling Expires May 2, 2012 [Page 11]
Internet-Draft Security Policy Distribution Format October 2011
2.3.2.3. protocol-id
Specified an internet protocol by means of an SRV protocol prefix as
specified in [RFC2782].
2.3.2.4. ni-uri
Specifies a reference to static data content by means of an ni scheme
URI.
Support for the SHA-256 algorithm is REQUIRED.
2.3.2.5. data-uri
A data URI formatted in accordance with [RFC2397].
2.3.2.6. tls-version
The TLS version number specified as major '.' minor. Where the
values of major and minor are as specified by the TLS specification
[RFC4346].
TLS 1.1 has the version number 3.1
2.3.3. Common Parameters
The following parameters MAY occur in any Security Policy Statement.
2.3.3.1. Domain=<dns-name>
The domain(s) to which the security policy statement applies.
The wildcard character '*' MAY be used to indicate that the security
policy statement also applies to subdomains within the specified
domain.
To facilitate mapping of security policy originated in DNS records,
the rules for use of wildcards are the same as those defined for
DNSSEC. I.e. wildcards SHALL only occur as the first label in a DNS
name, if a domain is in the scope of multiple security policy
statements, the principle of closest match is applied.
2.3.3.2. Protocol=<protocol-id>*
A list of protocols to which the Security Policy applies. Protocols
are identified by their SRV prefix labels.
Hallam-Baker & Stradling Expires May 2, 2012 [Page 12]
Internet-Draft Security Policy Distribution Format October 2011
2.3.3.3. UTC=<date-time>
The time at which the security policy statement was obtained. This
MAY be earlier than the time at which the SPDF document is signed but
SHOULD NOT be later.
2.3.3.4. Expire=<date-time>
The time at which the security policy statement expires. This MUST
NOT be earlier than the time at which the SPDF document was signed.
2.3.3.5. Common
The common parameter is used to provide a simple means of compression
when specifying lists of Security Policy headers. If the Common
header is specified, all unspecified common parameters take their
value from the preceding header.
2.3.4. Statement: CA-PIN: <ni-uri>
The CA-PIN statement is used to prevent a certificate issuer
downgrade attack. A certificate SHALL be in violation of the
specified security policy if the domain in question was within the
scope of at least one CA-PIN statement at the time in question and
the certificate does not comply with the requirements of any CA-PIN
statements that were active at the time in question.
The principal parameter of a CA-PIN statement is an ni URI that
specifies the criteria for the pinning.
2.3.4.1. Match= 'key' | 'csk' | 'cert' | 'path'
Specifies whether the specified Named Information URI applies to an
end entity subject key (key), a certificate signing subject key
(csk), an end entity certificate (cert) or a certificate signing
certificate (path). If no match is specified, the 'key' match is the
default.
2.3.4.1.1. Calculating the digest of a Subject Key.
Is calculated over the subjectKeyInfo structure within the
certificate.
2.3.4.1.2. Calculating the digest of a Certificate.
The digest of a certificate is calculated over the binary certificate
value.
Hallam-Baker & Stradling Expires May 2, 2012 [Page 13]
Internet-Draft Security Policy Distribution Format October 2011
2.3.4.2. After=<date-time>
The statement is only to be applied to certificates issued after the
specified date and time.
2.3.4.3. Before=<date-time>
The statement is only to be applied to certificates issued before the
specified date and time.
2.3.4.4. Unpin=<ni-uri>
A Named Information URI that specifies the digest of an unpinning
value. Disclosure of the unpinning value has the effect of revoking
the corresponding security policy statement to which it is attached.
The unpinning value SHOULD be a randomly chosen nonce with sufficient
ergodicity to make determination by brute force attack infeasible.
2.3.5. Statement: Unpin: <data-uri>
An unpinning value for a previously distributed CA pinning statement
encoded as Base64.
2.3.6. Statement: Revoke: <uri>
The Revoke statement is used to declare that a certificate is
invalid.
While the functionality of the Revoke statement overlaps the
capabilities and functionality of the existing PKIX revocation
schemes (CRLs and OCSP), it is intended for a different field of use.
In particular the Revoke statement SHOULD NOT be employed except as a
last resort mechanism for use in situations that are not adequately
addressed by the existing certificate status infrastructure and the
risk of relying on the revoked certificate is unacceptably high.
2.3.7. Statement: Action: <action>
Specifies the action that SHOULD be performed in the case that a
security policy violation is detected. Valid actions are 'Ignore',
'Advise', 'Fail' and 'Block':
Hallam-Baker & Stradling Expires May 2, 2012 [Page 14]
Internet-Draft Security Policy Distribution Format October 2011
Ignore The client SHOULD ignore policy violations. This option is
intended for use in testing Security Policy configuration prior to
requesting enforcement.
Advise The client SHOULD advise the user when policy violations
occur but not impede access to the corresponding network resource.
Fail The client SHOULD advise the user that a policy violation has
occurred and discourage (but not prevent) access to the
corresponding network resource.
Block The client SHOULD advise the user that a policy violation has
occurred and prevent access to the corresponding network resource.
Note that the specification of client actions is independent of
reporting requests.
2.3.8. Statement: Report: <dns-name>
This part is to be aligned with whatever is agreed in PKIX for use in
CAA.
2.3.9. Statement: TLS: <level>
Specifies the use of TLS:
refused Use of TLS is not supported.
unknown Use of TLS is unkown.
optional (default) Use of TLS is optional.
required Use of TLS is required.
strict Use of TLS is required with Strict Transport Security.
Additional parameters MAY be specified to further control the mode of
use of TLS. For example the minimum version of the protocol to be
used. [[While this could be extended to include cipher suites it is
believed that the existing protocol is sufficiently proofed against
downgrade attack on cipher suites. If this should be found not to be
the case it would likely drive an urgent update of the protocol
version.]]
2.3.9.1. min=<tls-version>
Specifies the minimum version of the TLS protocol to which the
security policy applies (default is SSL 1.0).
Hallam-Baker & Stradling Expires May 2, 2012 [Page 15]
Internet-Draft Security Policy Distribution Format October 2011
2.3.9.2. max=<tls-version>
Specifies the maximum version of the TLS protocol to which the
security policy applies (default is no maximum version).
3. Distribution Format
A SPDF document consists of a Cryptographic Message Syntax object
[RFC5652] that contains a list of Security Policy statements. SPDF
documents SHOULD be signed and MAY be encrypted.
3.1. Cryptographic Message Syntax Properties
[TBS details of CMS options that MUST be supported, crib this from
SMIME]
3.2. JSON Packaging
[TBS optional, not sure if it is actually very usefull for this
particular application but...]
4. Security Considerations
TBS
5. IANA Considerations
TBS
Need to create a registry for the statements and parameters.
6. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
August 1998.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
Hallam-Baker & Stradling Expires May 2, 2012 [Page 16]
Internet-Draft Security Policy Distribution Format October 2011
February 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[X.509] International Telecommunication Union, "ITU-T
Recommendation X.509 (11/2008): Information technology -
Open systems interconnection - The Directory: Public-key
and attribute certificate frameworks", ITU-T
Recommendation X.509, November 2008.
Authors' Addresses
Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com
Rob Stradling
Comodo CA Ltd.
Email: rob.stradling@comodo.com
Hallam-Baker & Stradling Expires May 2, 2012 [Page 17]
