Each value can contain a set of attributes (each possibly a multi-
valued attribute) encrypted for a set of predetermined recipients.
The cleartext that is encrypted has the type:
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
The DER encoding of the ACClearAttrs structure is used as the
encryptedContent field of the EnvelopedData. The DER encoding MUST
be embedded in an OCTET STRING.
The acIssuer and acSerial fields are present to prevent ciphertext
stealing. When an AC verifier has successfully decrypted an
encrypted attribute, it MUST then check that the AC issuer and
serialNumber fields contain the same values. This prevents a
malicious AC issuer from copying ciphertext from another AC (without
knowing its corresponding plaintext).
The procedure for an AC issuer when encrypting attributes is
illustrated by the following (any other procedure that gives the same
result MAY be used):
1. Identify the sets of attributes that are to be encrypted for
each set of recipients.
2. For each attribute set which is to be encrypted:
2.1. Create an EnvelopedData structure for the data for this
set of recipients.
2.2. Encode the ContentInfo containing the EnvelopedData as a
value of the encAttrs attribute.
2.3. Ensure the cleartext attributes are not present in the
to-be-signed AC.
3. Add the encAttrs (with its multiple values) to the AC.
Note that there may be more than one attribute of the same type (the
same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain
the same attribute type both in clear and in encrypted form (and
indeed several times if the same recipient is associated with more
than one EnvelopedData). One approach implementers may choose, would
be to merge attribute values following decryption in order to re-
establish the "once only" constraint.
name id-aca-encAttrs
OID { id-aca 6}
Syntax ContentInfo
values Multiple Allowed
If an AC contains attributes, apparently encrypted for the AC
verifier, the decryption process MUST not fail. If decryption does
fail, the AC MUST be rejected.
7.2 Proxying
When a server acts as a client for another server on behalf of the AC
holder, the server MAY need to proxy an AC. Such proxying MAY have
to be done under the AC issuer's control, so that not every AC is
proxiable and so that a given proxiable AC can be proxied in a
targeted fashion. Support for chains of proxies (with more than one
intermediate server) MAY also be required. Note that this does not
involve a chain of ACs.
In order to meet this requirement we define another extension,
ProxyInfo, similar to the targeting extension.
When this extension is present, the AC verifier must check that the
entity from which the AC was received was allowed to send it and that
the AC is allowed to be used by this verifier.
The proxying information consists of a set of proxy information, each
of which is a set of targeting information. If the verifier and the
sender of the AC are both named in the same proxy set, the AC can
then be accepted (the exact rule is given below).
The effect is that the AC holder can send the AC to any valid target
which can then only proxy to targets which are in one of the same
proxy sets as itself.
The following data structure is used to represent the
targeting/proxying information.
ProxyInfo ::= SEQUENCE OF Targets
As in the case of targeting, the targetCert CHOICE MUST NOT be used.
A proxy check succeeds if either one of the conditions below is met:
1. The identity of the sender, as established by the underlying
authentication service, matches the holder field of the AC, and
the current server "matches" any one of the proxy sets. Recall
that "matches" is as defined section 4.3.2.
2. The identity of the sender, as established by the underlying
authentication service, "matches" one of the proxy sets (call it
set "A"), and the current server is one of the targetName fields
in the set "A", or the current server is a member of one of the
targetGroup fields in set "A".
When an AC is proxied more than once, a number of targets will be on
the path from the original client, which is normally, but not always,
the AC holder. In such cases, prevention of AC "stealing" requires
that the AC verifier MUST check that all targets on the path are
members of the same proxy set. It is the responsibility of the AC-
using protocol to ensure that a trustworthy list of targets on the
path is available to the AC verifier.
name id-pe-ac-proxying
OID { id-pe 10 }
syntax ProxyInfo
criticality MUST be TRUE
7.3 Use of ObjectDigestInfo
In some environments, it may be required that the AC is not linked
either to an identity (via entityName) or to a PKC (via
baseCertificateID). The objectDigestInfo CHOICE in the holder field
allows support for this requirement.
If the holder is identified with the objectDigestInfo field, then the
AC version field MUST contain v2 (the integer 1).
The idea is to link the AC to an object by placing a hash of that
object into the holder field of the AC. For example, this allows
production of ACs that are linked to public keys rather than names.
It also allows production of ACs which contain privileges associated
with an executable object such as a Java class. However, this
profile only specifies how to use a hash over a public key or PKC.
That is, conformant ACs MUST NOT use the otherObjectTypes value for
the digestedObjectType.
To link an AC to a public key, the hash must be calculated over the
representation of that public key which would be present in a PKC,
specifically, the input for the hash algorithm MUST be the DER
encoding of a SubjectPublicKeyInfo representation of the key. Note:
This includes the AlgorithmIdentifier as well as the BIT STRING. The
rules given in [PKIXPROF] for encoding keys MUST be followed. In
this case, the digestedObjectType MUST be publicKey and the
otherObjectTypeID field MUST NOT be present.
Note that if the public key value used as input to the hash function
has been extracted from a PKC, it is possible that the
SubjectPublicKeyInfo from that PKC is NOT the value which should be
hashed. This can occur if DSA Dss-parms are inherited as described
in section 7.3.3 of [PKIXPROF]. The correct input for hashing in
this context will include the value of the parameters inherited from
the CA's PKC, and thus may differ from the SubjectPublicKeyInfo
present in the PKC.
Implementations which support this feature MUST be able to handle the
representations of public keys for the algorithms specified in
section 7.3 of [PKIXPROF]. In this case, the digestedObjectType MUST
be publicKey and the otherObjectTypeID field MUST NOT be present.
In order to link an AC to a PKC via a digest, the digest MUST be
calculated over the DER encoding of the entire PKC, including the
signature value. In this case the digestedObjectType MUST be
publicKeyCert and the otherObjectTypeID field MUST NOT be present.
7.4 AA Controls
During AC validation a relying party has to answer the question: is
this AC issuer trusted to issue ACs containing this attribute? The
AAControls PKC extension MAY be used to help answer the question.
The AAControls extension is intended to be used in CA and AC issuer
PKCs.
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
The AAControls extension is used as follows:
The pathLenConstraint, if present, is interpreted as in [PKIXPROF].
It restricts the allowed distance between the AA CA (a CA directly
trusted to include AAControls in its PKCs), and the AC issuer.
The permittedAttrs field specifies a set of attribute types that any
AC issuer below this AA CA is allowed to include in ACs. If this
field is not present, it means that no attribute types are explicitly
allowed.
The excludedAttrs field specifies a set of attribute types that no AC
issuer is allowed to include in ACs. If this field is not present,
it means that no attribute types are explicitly disallowed.
The permitUnSpecified field specifies how to handle attribute types
which are not present in either the permittedAttrs or excludedAttrs
fields. TRUE (the default) means that any unspecified attribute type
is allowed in ACs; FALSE means that no unspecified attribute type is
allowed.
When AAControls are used, the following additional checks on an AA's
PKC chain MUST all succeed for the AC to be valid:
1. Some CA on the ACs certificate path MUST be directly trusted to
issue PKCs which precede the AC issuer in the certification path;
call this CA the "AA CA".
2. All PKCs on the path from the AA CA, down to and including the AC
issuer's PKC, MUST contain an AAControls extension; however, the
AA CA's PKC need not contain this extension.
3. Only those attributes in the AC which are allowed, according to
all of the AAControls extension values in all of the PKCs from the
AA CA to the AC issuer, may be used for authorization decisions;
all other attributes MUST be ignored. This check MUST be applied
to the set of attributes following attribute decryption, and the
id-aca-encAttrs type MUST also be checked.
name id-pe-aaControls
OID { id-pe 6 }
syntax AAControls
criticality MAY be TRUE
8. Security Considerations
The protection afforded for private keys is a critical factor in
maintaining security. Failure of AC issuers to protect their private
keys will permit an attacker to masquerade as them, potentially
generating false ACs or revocation status. Existence of bogus ACs
and revocation status will undermine confidence in the system. If
the compromise is detected, all ACs issued by the AC issuer MUST be
revoked. Rebuilding after such a compromise will be problematic, so
AC issuers are advised to implement a combination of strong technical
measures (e.g., tamper-resistant cryptographic modules) and
appropriate management procedures (e.g., separation of duties) to
avoid such an incident.
Loss of an AC issuer's private signing key may also be problematic.
The AC issuer would not be able to produce revocation status or
perform AC renewal. AC issuers are advised to maintain secure backup
for signing keys. The security of the key backup procedures is a
critical factor in avoiding key compromise.
The availability and freshness of revocation status will affect the
degree of assurance that should be placed in a long-lived AC. While
long-lived ACs expire naturally, events may occur during its natural
lifetime which negate the binding between the AC holder and the
attributes. If revocation status is untimely or unavailable, the
assurance associated with the binding is clearly reduced.
The binding between an AC holder and attributes cannot be stronger
than the cryptographic module implementation and algorithms used to
generate the signature. Short key lengths or weak hash algorithms
will limit the utility of an AC. AC issuers are encouraged to note
advances in cryptology so they can employ strong cryptographic
techniques.
Inconsistent application of name comparison rules may result in
acceptance of invalid targeted or proxied ACs, or rejection of valid
ones. The X.500 series of specifications defines rules for comparing
distinguished names. These rules require comparison of strings
without regard to case, character set, multi-character white space
substrings, or leading and trailing white space. This specification
and [PKIXPROF] relaxes these requirements, requiring support for
binary comparison at a minimum.
AC issuers MUST encode the distinguished name in the AC
holder.entityName field identically to the distinguished name in the
holder's PKC. If different encodings are used, implementations of
this specification may fail to recognize that the AC and PKC belong
to the same entity.
If an attribute certificate is tied to the holder's PKC using the
baseCertificateID component of the Holder field and the PKI in use
includes a rogue CA with the same issuer name specified in the
baseCertificateID component, this rogue CA could issue a PKC to a
malicious party, using the same issuer name and serial number as the
proper holder's PKC. Then the malicious party could use this PKC in
conjunction with the AC. This scenario SHOULD be avoided by properly
managing and configuring the PKI so that there cannot be two CAs with
the same name. Another alternative is to tie ACs to PKCs using the
publicKeyCert type in the ObjectDigestInfo field. Failing this, AC
verifiers have to establish (using other means) that the potential
collisions cannot actually occur, for example, the CPSs of the CAs
involved may make it clear that no such name collisions can occur.
Implementers MUST ensure that following validation of an AC, only
attributes that the issuer is trusted to issue are used in
authorization decisions. Other attributes, which MAY be present MUST
be ignored. Given that the AA controls PKC extension is optional to
implement, AC verifiers MUST be provided with this information by
other means. Configuration information is a likely alternative
means. This becomes very important if an AC verifier trusts more
than one AC issuer.
There is often a requirement to map between the authentication
supplied by a particular security protocol (e.g. TLS, S/MIME) and the
AC holder's identity. If the authentication uses PKCs, then this
mapping is straightforward. However, it is envisaged that ACs will
also be used in environments where the holder may be authenticated
using other means. Implementers SHOULD be very careful in mapping
the authenticated identity to the AC holder.
9. IANA Considerations
Attributes and attribute certificate extensions are identified by
object identifiers (OIDs). Many of the OIDs used in this document
are copied from X.509 [X.509-2000]. Other OIDs were assigned from an
arc delegated by the IANA. No further action by the IANA is
necessary for this document or any anticipated updates.
10. References
[CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein,
"Certificate Management Messages over CMS", RFC2797,
April 2000.
[CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key
Infrastructure - Certificate Management Protocols", RFC
2510, March 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC2630,
June 1999.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC2634, June 1999.
[KRB] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC1510, September 1993.
[LDAP] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC2251, December 1997.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
Adams, "X.509 Internet Public Key Infrastructure -
Online Certificate Status Protocol - OCSP", RFC2560,
June 1999.
[PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
Lists CRL Profile", RFC3279, April 2002.
[PKIXPROF] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC3280,
April 2002.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[URL] Berners-Lee, T., Masinter L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC1738, December 1994.
[X.208-1988] CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.
[X.501-88] CCITT Recommendation X.501: The Directory - Models.
1988.
[X.501-1993] ITU-T Recommendation X.501 : Information Technology -
Open Systems Interconnection - The Directory: Models,
1993.
[X.509-1988] CCITT Recommendation X.509: The Directory -
Authentication Framework. 1988.
[X.509-1997] ITU-T Recommendation X.509: The Directory -
Authentication Framework. 1997.
[X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key
and Attribute Certificate Frameworks. 2000
Appendix A: Object Identifiers
This (normative) appendix lists the new object identifiers which are
defined in this specification. Some of these are required only for
support of optional features and are not required for conformance to
this profile. This specification mandates support for OIDs which
have arc elements with values that are less than 2^32, (i.e. they
MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less
than 2^31 (i.e. less than or equal to 2,147,483,647). This allows
each arc element to be represented within a single 32 bit word.
Implementations MUST also support OIDs where the length of the dotted
decimal (see [LDAP], section 4.1.2) string representation can be up
to 100 bytes (inclusive). Implementations MUST be able to handle
OIDs with up to 20 elements (inclusive). AA's SHOULD NOT issue ACs
which contain OIDs that breach these requirements.
The following OIDs are imported from [PKIXPROF]:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
The following new ASN.1 module OID is defined:
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }
The following AC extension OIDs are defined:
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
The following PKC extension OIDs are defined:
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
The following attribute OIDs are defined:
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
id-at-clearance OBJECT IDENTIFIER ::=
{ joint-iso-ccitt(2) ds(5) module(1)
selected-attribute-types(5) clearance (55) }
Appendix B: ASN.1 Module
PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert(12)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
-- IMPORTed module OIDs MAY change if [PKIXPROF] changes
-- PKIX Certificate Extensions
Attribute, AlgorithmIdentifier, CertificateSerialNumber,
Extensions, UniqueIdentifier,
id-pkix, id-pe, id-kp, id-ad, id-at
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5)
pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
GeneralName, GeneralNames, id-ce
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5)
pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ;
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
-- { id-aca 5 } is reserved
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72}
id-at-clearance OBJECT IDENTIFIER ::=
{ joint-iso-ccitt(2) ds(5) module(1)
selected-attribute-types(5) clearance (55) }
-- Uncomment this if using a 1988 level ASN.1 compiler
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion -- version is v2,
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
AttCertVersion ::= INTEGER { v2(1) }
Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- used to directly authenticate the
-- holder, for example, an executable
}
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- MUST NOT be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
}
AttCertIssuer ::= CHOICE {
v1Form GeneralNames, -- MUST NOT be used in this
-- profile
v2Form [0] V2Form -- v2 only
}
V2Form ::= SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- issuerName MUST be present in this profile
-- baseCertificateID and objectDigestInfo MUST
-- NOT be present in this profile
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
Targets ::= SEQUENCE OF Target
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName,
targetCert [2] TargetCert
}
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
IetfAttrSyntax ::= SEQUENCE {
policyAuthority[0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories
[2] SET OF SecurityCategory OPTIONAL
}
ClassList ::= BIT STRING {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
topSecret (5)
}
SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ProxyInfo ::= SEQUENCE OF Targets
END
Author's Addresses
Stephen Farrell
Baltimore Technologies
39/41 Parkgate Street
Dublin 8
IRELAND
EMail: stephen.farrell@baltimore.ie
Russell Housley
RSA Laboratories
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: rhousley@rsasecurity.com
Acknowledgements
Russ Housley thanks the management at SPYRUS, who supported the
development of this specification while he was employed at SPYRUS.
Russ Housley also thanks the management at RSA Laboratories, who
supported the completion of the specification after a job change.
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.