From: Nikos Mavrogiannopoulos Date: Thu, 1 Feb 2001 13:10:18 +0000 (+0000) Subject: drafts and rfcs were moved to protocol/ directory X-Git-Tag: gnutls-0-1-0-srp~52 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=7a4e7aa2b2e1f6b7617feff5469796fe6b00fd89;p=thirdparty%2Fgnutls.git drafts and rfcs were moved to protocol/ directory --- diff --git a/doc/protocol/draft-ietf-pkix-ac509prof-05.txt b/doc/protocol/draft-ietf-pkix-ac509prof-05.txt new file mode 100644 index 0000000000..7bd8e4e54a --- /dev/null +++ b/doc/protocol/draft-ietf-pkix-ac509prof-05.txt @@ -0,0 +1,2184 @@ + + + +PKIX Working Group S. Farrell +INTERNET-DRAFT Baltimore Technologies +Expires in six months R. Housley + SPYRUS + 8 August 2000 + + An Internet Attribute Certificate + Profile for Authorization + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of [RFC2026]. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + +Abstract + + This specification defines a profile for the use of X.509 Attribute + Certificates in Internet Protocols. Attribute certificates may be + used in a wide range of applications and environments covering a + broad spectrum of interoperability goals and a broader spectrum of + operational and assurance requirements. The goal of this document is + to establish a common baseline for generic applications requiring + broad interoperability as well as limited special purpose + requirements. The profile places emphasis on attribute certificate + support for Internet electronic mail, IPSec, and WWW security + applications. + + + + + + + + + + +Farrell & Housley [Page 1] + +INTERNET-DRAFT August 2000 + + +Table of Contents + + Status of this Memo.............................................1 + Abstract........................................................1 + Table of Contents...............................................1 + 1. Introduction.................................................3 + 1.1 Delegation and AC chains...............................4 + 1.2 Attribute Certificate Distribution ("push" vs. "pull").4 + 1.3 Document Structure.....................................5 + 2. Terminology..................................................6 + 3. Requirements.................................................7 + 4. Attribute Certificate Profile................................8 + 4.1 X.509 Attribute Certificate Definition.................8 + 4.2 Profile of Standard Fields............................10 + 4.2.1 Version.........................................10 + 4.2.2 Holder..........................................10 + 4.2.3 Issuer..........................................11 + 4.2.4 Signature.......................................12 + 4.2.5 Serial Number...................................12 + 4.2.6 Validity Period.................................12 + 4.2.7 Attributes......................................13 + 4.2.8 Issuer Unique Identifier........................13 + 4.2.9 Extensions......................................13 + 4.3 Extensions............................................14 + 4.3.1 Audit Identity..................................14 + 4.3.2 AC Targeting....................................15 + 4.3.3 Authority Key Identifier........................16 + 4.3.4 Authority Information Access....................16 + 4.3.5 CRL Distribution Points.........................17 + 4.3.6 No Revocation Available.........................17 + 4.4 Attribute Types.......................................17 + 4.4.1 Service Authentication Information..............18 + 4.4.2 Access Identity.................................18 + 4.4.3 Charging Identity...............................19 + 4.4.4 Group...........................................19 + 4.4.5 Role............................................19 + 4.4.6 Clearance.......................................20 + 4.5 Profile of AC issuer's PKC............................21 + 5. Attribute Certificate Validation............................22 + 6. Revocation..................................................23 + 7. Optional Features...........................................24 + 7.1 Attribute Encryption..................................24 + 7.2 Proxying..............................................25 + 7.3 Use of ObjectDigestInfo...............................26 + 7.4 AA Controls...........................................27 + 8. Security Considerations.....................................29 + 9. References..................................................31 + Author's Addresses.............................................32 + Full Copyright Statement.......................................32 + Appendix A: Object Identifiers.................................33 + Appendix B: ASN.1 Module.......................................34 + + + +Farrell & Housley [Page 2] + +INTERNET-DRAFT August 2000 + + +1. Introduction + + The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" + in this document are to be interpreted as described in [RFC2119]. + + X.509 public key certificates (PKCs) [X.509-1997, X.509-2000, + PKIXPROF] bind an identity and a public key. An attribute + certificate (AC) is a structure similar to a PKC; the main + difference being that the AC contains no public key. An AC may + contain attributes that specify group membership, role, security + clearance, or other authorization information associated with the AC + holder. The syntax for the AC is defined in Recommendation X.509, + making the term "X.509 certificate" ambiguous. + + Some people constantly confuse PKCs and ACs. An analogy may make the + distinction clear. A PKC can be considered to be like a passport: it + identifies the holder, tends to last for a long time, and should not + be trivial to obtain. An AC is more like an entry visa: it is + typically issued by a different authority and does not last for as + long a time. As acquiring an entry visa typically requires + presenting a passport, getting a visa can be a simpler process. + + Authorization information may be placed in a PKC extension or placed + in a separate attribute certificate (AC). The placement of + authorization information in PKCs is usually undesirable for two + reasons. First, authorization information often does not have the + same lifetime as the binding of the identity and the public key. + When authorization information is placed in a PKC extension, the + general result is the shortening of the PKC useful lifetime. Second, + the PKC issuer is not usually authoritative for the authorization + information. This results in additional steps for the PKC issuer to + obtain authorization information from the authoritative source. + + For these reasons, it is often better to separate authorization + information from the PKC. Yet, authorization information also needs + to be bound to an identity. An AC provides this binding; it is + simply a digitally signed (or certified) identity and set of + attributes. + + An AC may be used with various security services, including access + control, data origin authentication, and non-repudiation. + + PKCs can provide an identity to access control decision functions. + However, in many contexts the identity is not the criterion that is + used for access control decisions, rather the role or group- + membership of the accessor is the criterion used. Such access + control schemes are called role-based access control. + + When making an access control decision based on an AC, an access + control decision function may need to ensure that the appropriate AC + holder is the entity that has requested access. One way in which the + linkage between the request or identity and the AC can be achieved + is the inclusion of a reference to a PKC within the AC and the use + +Farrell & Housley [Page 3] + +INTERNET-DRAFT August 2000 + + + of the private key corresponding to the PKC for authentication + within the access request. + + ACs may also be used in the context of a data origin authentication + service and a non-repudiation service. In these contexts, the + attributes contained in the AC provide additional information about + the signing entity. This information can be used to make sure that + the entity is authorized to sign the data. This kind of checking + depends either on the context in which the data is exchanged or on + the data that has been digitally signed. + +1.1 Delegation and AC chains + + The X.509 standard [X.509-2000] defines authorization as the + "conveyance of privilege from one entity that holds such privilege, + to another entity". An AC is one authorization mechanism. + + An ordered sequence of ACs could be used to verify the authenticity + of a privilege asserter's privilege. In this way, chains or paths of + ACs could be employed to delegate authorization. + + Since the administration and processing associated with such AC + chains is complex and the use of ACs in the Internet today is quite + limited, this specification does NOT RECOMMEND the use of AC chains. + Other (future) specifications may address the use of AC chains. This + specification deals with the simple cases where one authority issues + all of the ACs for a particular set of attributes. However, this + simplification does not preclude the use of several different + authorities, each of which manages a different set of attributes. + For example, group membership may be included in one AC issued by + one authority, and security clearance may be included in another AC + issued by another authority. + + This means that conformant implementations are only REQUIRED to be + able to process a single AC at a time. Processing of more than one + AC, one after another, may be necessary. Note however, that + validation of an AC MAY require validation of a chain of PKCs, as + specified in [PKIXPROF]. + +1.2 Attribute Certificate Distribution ("push" vs. "pull") + + As discussed above, ACs provide a mechanism to securely provide + authorization information to, for example, access control decision + functions. However, there are a number of possible communication + paths for ACs. + + In some environments it is suitable for a client to "push" an AC to + a server. This means that no new connections between the client and + server are required. It also means that no search burden is imposed + on servers, which improves performance and that the AC verifier is + only presented with what it "needs to know." In inter-domain cases + where the client's rights should be assigned within client's "home" + domain, the "push" model is especially suitable. + +Farrell & Housley [Page 4] + +INTERNET-DRAFT August 2000 + + + In other cases, it is more suitable for a client simply to + authenticate to the server and for the server to request or "pull" + the client's AC from an AC issuer or a repository. A major benefit + of the "pull" model is that it can be implemented without changes to + the client or to the client-server protocol. The "pull" model is + especially suitable for inter-domain cases where the client's rights + should be assigned within the server's domain, rather than within + the client's domain. + + There are a number of possible exchanges involving three entities: + the client, the server, and the AC issuer. In addition, a directory + service or other repository for AC retrieval MAY be supported. + + Figure 1 shows an abstract view of the exchanges that may involve + ACs. This profile does not specify a protocol for these exchanges. + + + +--------------+ + | | Server Acquisition + | AC issuer +----------------------------+ + | | | + +--+-----------+ | + | | + | Client | + | Acquisition | + | | + +--+-----------+ +--+------------+ + | | AC "push" | | + | Client +-------------------------+ Server | + | | (part of app. protocol) | | + +--+-----------+ +--+------------+ + | | + | Client | Server + | Lookup +--------------+ | Lookup + | | | | + +---------------+ Repository +---------+ + | | + +--------------+ + + Figure 1: AC Exchanges + +1.3 Document Structure + + Section 2 defines some terminology. Section 3 specifies the + requirements that this profile is intended to meet.; Section 4 + contains the profile of the X.509 AC. Section 5 specifies rules for + AC validation. Section 6 specifies rules for AC revocation checks. + Section 7 specifies optional features which MAY be supported; + however, support for these features is not required for conformance + to this profile. Finally, appendices contain the list of OIDs + required to support this specification and an ASN.1 module. + + + +Farrell & Housley [Page 5] + +INTERNET-DRAFT August 2000 + + +2. Terminology + + For simplicity, we use the terms client and server in this + specification. This is not intended to indicate that ACs are only to + be used in client-server environments. For example, ACs may be used + in the S/MIME v3 context, where the mail user agent would be both a + "client" and a "server" in the sense the terms are used here. + + Term Meaning + + AA Attribute Authority, the entity that issues the + AC, synonymous in this specification with "AC + issuer" + AC Attribute Certificate + AC user any entity that parses or processes an AC + AC verifier any entity that checks the validity of an AC and + then makes use of the result + AC issuer the entity which signs the AC, synonymous in this + specification with "AA" + AC holder the entity indicated (perhaps indirectly) in the + holder field of the AC + Client the entity which is requesting the action for + which authorization checks are to be made + Proxying in this specification, Proxying is used to mean + the situation where an application server acts as + an application client on behalf of a user. + Proxying here does not mean granting of authority. + PKC Public Key Certificate - uses the type ASN.1 + Certificate defined in X.509 and profiled in RFC + 2459. This (non-standard) acronym is used in order + to avoid confusion about the term "X.509 + certificate". + Server the entity which requires that the authorization + checks are made + + + + + + + + + + + + + + + + + + + + +Farrell & Housley [Page 6] + +INTERNET-DRAFT August 2000 + + +3. Requirements + + This AC profile meets the following requirements. + + Time/Validity requirements: + + 1. Support for short-lived as well as long-lived ACs. Typical + short-lived validity periods might be measured in hours, as + opposed to months for PKCs. Short validity periods allow ACs to + be useful without a revocation mechanism. + + Attribute Types: + + 2. Issuers of ACs should be able to define their own attribute + types for use within closed domains. + 3. Some standard attribute types should be defined which can be + contained within ACs. Examples include "access identity," + "group," "role," "clearance," "audit identity," and "charging + identity." + 4. Standard attribute types should be defined in a manner that + permits an AC verifier to distinguish between uses of the same + attribute in different domains. For example, the + "Administrators group" as defined by Baltimore and the + "Administrators group" as defined by SPYRUS should be easily + distinguished. + + Targeting of ACs: + + 5. It should be possible to "target" an AC at one, or a small + number of, servers. This means that a trustworthy non-target + server will reject the AC for authorization decisions. + + Push vs. Pull + + 6. ACs should be defined so that they can either be "pushed" by + the client to the server, or "pulled" by the server from a + repository or other network service, including an online AC + issuer. + + + + + + + + + + + + + + + + +Farrell & Housley [Page 7] + +INTERNET-DRAFT August 2000 + + +4. Attribute Certificate Profile + + ACs may be used in a wide range of applications and environments + covering a broad spectrum of interoperability goals and a broader + spectrum of operational and assurance requirements. The goal of + this document is to establish a common baseline for generic + applications requiring broad interoperability and limited special + purpose requirements. In particular, the emphasis will be on + supporting the use of attribute certificates for informal Internet + electronic mail, IPSec, and WWW applications. + + This section presents a profile for ACs that will foster + interoperability. This section also defines some private extensions + for the Internet community. + + While the ISO/IEC/ITU documents use the 1993 (or later) version of + ASN.1; this document uses the 1988 ASN.1 syntax, as has been done + for PKCs [PKIXPROF]. The encoded certificates and extensions from + either ASN.1 version are bit-wise identical. + + Where maximum lengths for fields are specified, these lengths refer + to the DER encoding and do not include the ASN.1 tag or length + fields. + + Conforming implementations MUST support the profile specified in + this section. + +4.1 X.509 Attribute Certificate Definition + + X.509 contains the definition of an AC given below. All types that + are not defined in this document can be found in [PKIXPROF]. + + AttributeCertificate ::= SEQUENCE { + acinfo AttributeCertificateInfo, + signatureAlgorithm AlgorithmIdentifier, + signatureValue BIT STRING + } + + AttributeCertificateInfo ::= SEQUENCE { + version AttCertVersion DEFAULT v1, + holder Holder, + issuer AttCertIssuer, + signature AlgorithmIdentifier, + serialNumber CertificateSerialNumber, + attrCertValidityPeriod AttCertValidityPeriod, + attributes SEQUENCE OF Attribute, + issuerUniqueID UniqueIdentifier OPTIONAL, + extensions Extensions OPTIONAL + } + + AttCertVersion ::= INTEGER { v1(0), v2(1) } + + + +Farrell & Housley [Page 8] + +INTERNET-DRAFT August 2000 + + + + 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 + -- if present, version must be v2 + } + + ObjectDigestInfo ::= SEQUENCE { + digestedObjectType ENUMERATED { + publicKey (0), + publicKeyCert (1), + otherObjectTypes (2) }, + -- otherObjectTypes MUST NOT + -- be used in this profile + otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, + digestAlgorithm AlgorithmIdentifier, + objectDigest BIT STRING + } + + AttCertIssuer ::= CHOICE { + v1Form GeneralNames, -- v1 or v2 + v2Form [0] V2Form -- v2 only + } + + V2Form ::= SEQUENCE { + issuerName GeneralNames OPTIONAL, + baseCertificateID [0] IssuerSerial OPTIONAL, + objectDigestInfo [1] ObjectDigestInfo OPTIONAL + -- at least one of issuerName, baseCertificateID + -- or objectDigestInfo MUST be present + } + + IssuerSerial ::= SEQUENCE { + issuer GeneralNames, + serial CertificateSerialNumber, + issuerUID UniqueIdentifier OPTIONAL + } + + AttCertValidityPeriod ::= SEQUENCE { + notBeforeTime GeneralizedTime, + notAfterTime GeneralizedTime + } + + + + + + + + +Farrell & Housley [Page 9] + +INTERNET-DRAFT August 2000 + + + Although the Attribute syntax is defined in [PKIXPROF], we repeat + the definition here for convenience. + + Attribute ::= SEQUENCE { + type AttributeType, + values SET OF AttributeValue + -- at least one value is required + } + + AttributeType ::= OBJECT IDENTIFIER + + AttributeValue ::= ANY DEFINED BY AttributeType + + Implementers should note that the DER encoding (see [X.509- + 1988],[X.208-1988]) of the SET OF values requires ordering of the + encodings of the values. Though this issue arises with respect to + distinguished names, and has to be handled by [PKIXPROF] + implementations, its is much more significant in this context, since + the inclusion of multiple values is much more common in ACs. + +4.2 Profile of Standard Fields + + For all GeneralName fields in this profile the otherName (except as + noted below), x400Address, ediPartyName and registeredID options + MUST NOT be used. The use of Kerberos [KRB] principal names, + encoded into the otherName, SHOULD however, be supported using the + krb5PrincipalName OID and the KerberosName syntax as defined in + [PKINIT]. + + Conforming implementations MUST be able to support the dNSName, + directoryName, uniformResourceIdentifier, and iPAddress fields in + all cases where GeneralName is used. This is compatible with the + GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7). + +4.2.1 Version + + The version field MUST be the default value of v1. That is, the + version field is not present in the DER encoding, except when the + holder is identified using the optional objectDigestInfo field, as + specified in section 7.3. + +4.2.2 Holder + + For any environment where the AC is passed in an authenticated + message or session and where the authentication is based on the use + of an X.509 PKC, the holder field SHOULD use the baseCertificateID. + + With the baseCertificateID option, the holder's PKC serialNumber and + issuer MUST be identical to the AC holder field. The PKC issuer MUST + have a non-empty distinguished name which is to be present as the + single value of the holder.baseCertificateID.issuer construct in the + directoryName field. The AC holder.baseCertificateID.issuerUID field + MUST only be used if the holder's PKC contains an issuerUniqueID + +Farrell & Housley [Page 10] + +INTERNET-DRAFT August 2000 + + + field. If both the AC holder.baseCertificateID.issuerUID and the PKC + issuerUniqueID fields are present, then the same value MUST be + present in both fields. Thus, the baseCertificateID is only usable + with PKC profiles (like [PKIXPROF]) which mandate that the PKC + issuer field contain a non-empty distinguished name value. + + Note: An empty distinguished name is a distinguished name where the + SEQUENCE OF relative distinguished names is of zero length. In a DER + encoding this has the value '3000'H. + + If the holder field uses the entityName option and the underlying + authentication is based on a PKC, then the entityName MUST be the + same as the PKC subject field, unless the PKC subject field contains + an empty distinguished name. If the PKC subject field contains an + empty distinguished name, then the entityName field MUST be + identical to one of the values of the PKC subjectAltName field + extension. Note that [PKIXPROF] mandates that the subjectAltNames + extension be present if the PKC subject is an empty distinguished + name. See the security consideration section which mentions some + name collision problems that may arise when using the entityName + option. + + In any other case where the holder field uses the entityName option, + then only one name SHOULD be present. + + Implementations conforming to this profile are not required to + support the use of the objectDigest field. However, section 7.3 + specifies how this optional feature MAY be used. + + Any protocol conforming to this profile SHOULD specify which AC + holder option is to be used and how this fits with the supported + authentication schemes defined in that protocol. + +4.2.3 Issuer + + ACs conforming to this profile MUST use the v1Form choice, which + MUST contain one and only one GeneralName, which MUST contain a non- + empty distinguished name in the directoryName field. This means that + all AC issuers MUST have non-empty distinguished names. + + Part of the reason for the use of the v1Form field is that it means + that the AC issuer does not have to know which PKC the AC verifier + will use for it (the AC issuer). Using the baseCertificateID field + to reference the AC issuer would mean that the AC verifier would + have to trust the PKC that the AC issuer chose (for itself) at AC + creation time. + + + + + + + + +Farrell & Housley [Page 11] + +INTERNET-DRAFT August 2000 + + +4.2.4 Signature + + Contains the algorithm identifier used to validate the AC signature. + + This MUST be one of the signing algorithms defined in [PKIXALGS]. + + id-dsa-with-sha1 MUST be supported by all AC users. The other + algorithms MAY be supported. + +4.2.5 Serial Number + + For any conforming AC, the issuer/serialNumber pair MUST form a + unique combination, even if ACs are very short-lived. + + AC issuers MUST force the serialNumber to be a positive integer, + that is, the sign bit in the DER encoding of the INTEGER value MUST + be zero - this can be done by adding a leading (leftmost) '00'H + octet if necessary. This removes a potential ambiguity in mapping + between a string of octets and an integer value. + + Given the uniqueness and timing requirements above serial numbers + can be expected to contain long integers. AC users MUST be able to + handle serialNumber values longer than 4 octets. Conformant ACs MUST + NOT contain serialNumber values longer than 20 octets. + + There is no requirement that the serial numbers used by any AC + issuer follow any particular ordering, in particular, they need not + be monotonically increasing with time. Each AC issuer MUST ensure + that each AC that it issues contain a unique serial number. + +4.2.6 Validity Period + + The attrCertValidityPeriod (a.k.a. validity) field specifies the + period for which the AC issuer certifies that the binding between + the holder and the attributes fields will be valid. + + The generalized time type, GeneralizedTime, is a standard ASN.1 type + for variable precision representation of time. The GeneralizedTime + field can optionally include a representation of the time + differential between the local time zone and Greenwich Mean Time. + + For the purposes of this profile, GeneralizedTime values MUST be + expressed in Coordinated universal time (UTC) (also known as + Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times + are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. + GeneralizedTime values MUST NOT include fractional seconds. + (Note: this is the same as specified in [PKIXPROF], section + 4.1.2.5.2.) + + AC users MUST be able to handle an AC which, at the time of + processing, has parts of its validity period or all its validity + period in the past or in the future (a post-dated AC). This is valid + for some applications, such as backup. + +Farrell & Housley [Page 12] + +INTERNET-DRAFT August 2000 + + + +4.2.7 Attributes + + The attributes field gives information about the AC holder. When the + AC is used for authorization this will often contain a set of + privileges. + + The attributes field contains a SEQUENCE OF Attribute. Each + Attribute MAY contain a SET OF values. For a given AC, each + AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That + is, only one instance of each attribute can occur in a single AC, + but each instance can be multi-valued. + + AC users MUST be able to handle multiple values for all attribute + types. + + An AC MUST contain at least one attribute. That is, the SEQUENCE OF + Attributes MUST NOT be of zero length. + + Some standard attribute types are defined in section 4.5. + +4.2.8 Issuer Unique Identifier + + This field MUST NOT be used unless it is also used in the AC + issuer's PKC, in which case it MUST be used. Note that [PKIXPROF] + states that this field SHOULD NOT be used by conforming CAs, but + that applications SHOULD be able to parse PKCs containing the field. + +4.2.9 Extensions + + The extensions field generally gives information about the AC as + opposed to information about the AC holder. + + An AC that has no extensions conforms to the profile; however, + section 4.3 defines the extensions that MAY be used with this + profile, and whether or not they may be marked critical. If any + other critical extension is used, then the AC does not conform to + this profile. However, if any other non-critical extension is used, + then the AC does conform to this profile. + + The extensions defined for ACs provide methods for associating + additional attributes with holders. This profile also allows + communities to define private extensions to carry information unique + to those communities. Each extension in an AC may be designated as + critical or non-critical. An AC using system MUST reject an AC if + it encounters a critical extension it does not recognize; however, a + non-critical extension may be ignored if it is not recognized. + Section 4.3 presents recommended extensions used within Internet ACs + and standard locations for information. Communities may elect to + use additional extensions; however, caution should be exercised in + adopting any critical extensions in ACs, which might prevent use in + a general context. + + +Farrell & Housley [Page 13] + +INTERNET-DRAFT August 2000 + + +4.3 Extensions + +4.3.1 Audit Identity + + In some circumstances it is required (e.g. by data protection/data + privacy legislation) that audit trails do not contain records which + directly identify individuals. This circumstance may make the use of + the AC holder field unsuitable for use in audit trails. + + To allow for such cases, an AC MAY contain an audit identity + extension. Ideally it SHOULD be infeasible to derive the AC holder's + identity from the audit identity value without the co-operation of + the AC issuer. + + The value of the audit identity along with the AC issuer/serial + SHOULD then be used for audit/logging purposes. If the value of the + audit identity is suitably chosen, then a server/service + administrator can use audit trails to track the behavior of an AC + holder without being able to identify the AC holder. + + The server/service administrator in combination with the AC issuer + MUST be able to identify the AC holder in cases where misbehavior is + detected. This means that the AC issuer MUST be able to determine + the actual identity of the AC holder from the audit identity. + + Of course, auditing could be based on the AC issuer/serial pair; + however, this method doesn't allow tracking the same AC holder with + multiple ACs. Thus, an audit identity is only useful if it lasts for + longer than the typical AC lifetime. Auditing could also be based on + the AC holder's PKC issuer/serial; however, this will often allow + the server/service administrator to identify the AC holder. + + As the AC verifier might otherwise use the AC holder or some other + identifying value for audit purposes, this extension MUST be + critical when used. + + Protocols that use ACs will often expose the identity of the AC + holder in the bits on-the-wire. In such cases, an opaque audit + identity does not make use of the AC anonymous, it simply ensures + that the ensuing audit trails do not contain identifying + information. + + The value of an audit identity MUST be longer than zero octets. The + value of an audit identity MUST NOT be longer than 20 octets. + + name id-pe-ac-auditIdentity + OID { id-pe 4 } + syntax OCTET STRING + criticality MUST be TRUE + + + + + +Farrell & Housley [Page 14] + +INTERNET-DRAFT August 2000 + + +4.3.2 AC Targeting + + To target an AC, the target information extension, imported from + [X.509-2000], MAY be used to specify a number of servers/services. + The intent is that the AC SHOULD only be usable at the specified + servers/services. An (honest) AC verifier who is not amongst the + named servers/services MUST reject the AC. + + If this extension is not present, then the AC is not targeted and + may be accepted by any server. + + In this profile, the targeting information simply consists of a list + of named targets or groups. + + The following syntax is used to represent the targeting information: + + 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 + } + + The targetCert CHOICE within the Target structure is only present to + allow future compatibility with [X.509-2000] and MUST NOT be used. + + The targets check passes if the current server (recipient) is one of + the targetName fields in the Targets SEQUENCE, or if the current + server is a member of one of the targetGroup fields in the Targets + SEQUENCE. In this case, the current server is said to "match" the + targeting extension. + + How the membership of a target within a targetGroup is determined is + not defined here. It is assumed that any given target "knows" the + names of the targetGroups to which it belongs or can otherwise + determine its membership. For example, the targetGroup specifies a + DNS domain, and the AC verifier knows the DNS domain to which it + belongs. For another example, the targetGroup specifies "PRINTERS," + and the AC verifier knows whether or not it is a printer or print + server. + + Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF + Targets". Conforming AC issuer implementations MUST only produce one + "Targets" element. Confirming AC users MUST be able to accept a + "SEQUENCE OF Targets". If more than one Targets element is found in + + +Farrell & Housley [Page 15] + +INTERNET-DRAFT August 2000 + + + an AC, then the extension MUST be treated as if all Target elements + had been found within one Targets element. + + name id-ce-targetInformation + OID { id-ce 55 } + syntax SEQUENCE OF Targets + criticality MUST be TRUE + +4.3.3 Authority Key Identifier + + The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY + be used to assist the AC verifier in checking the signature of the + AC. The [PKIXPROF] description should be read as if "CA" meant "AC + issuer." As with PKCs this extension SHOULD be included in ACs. + + Note: An AC where the issuer field used the baseCertificateID CHOICE + would not need an authorityKeyIdentifier extension as it is + explicitly linked to the key in the referred certificate. However, + as this profile states (in section 4.2.3) that ACs MUST use the + v1Form CHOICE, this duplication does not arise. + + name id-ce-authorityKeyIdentifier + OID { id-ce 35 } + syntax AuthorityKeyIdentifier + criticality MUST be FALSE + +4.3.4 Authority Information Access + + The authorityInformationAccess extension, as defined in [PKIXPROF], + MAY be used to assist the AC verifier in checking the revocation + status of the AC. Support for the id-ad-caIssuers accessMethod is + NOT REQUIRED by this profile since AC chains are not expected. + + The following accessMethod is used to indicate that revocation + status checking is provided for this AC, using the OCSP protocol + defined in [OCSP]: + + id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } + + The accessLocation MUST contain a URI, and the URI MUST contain an + HTTP URL [URL] that specifies the location of an OCSP responder. The + AC issuer MUST, of course, maintain an OCSP responder at this + location. + + name id-ce-authorityInfoAccess + OID { id-pe 1 } + syntax AuthorityInfoAccessSyntax + criticality MUST be FALSE + + + + + + +Farrell & Housley [Page 16] + +INTERNET-DRAFT August 2000 + + +4.3.5 CRL Distribution Points + + The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY + be used to assist the AC verifier in checking the revocation status + of the AC. See section 6 for details on revocation. + + If the crlDistributionPoints extension is present, then exactly one + distribution point MUST be present. The crlDistributionPoints + extension MUST use the DistributionPointName option, which MUST + contain a fullName, which MUST contain a single name form. That name + MUST contain either a distinguished name or a URI. The URI MUST be + either an HTTP URL or an LDAP URL [URL]. + + name id-ce-cRLDistributionPoints + OID { id-ce 31 } + syntax CRLDistPointsSyntax + criticality MUST be FALSE + +4.3.6 No Revocation Available + + The noRevAvail extension, defined in [X.509-2000], allows an AC + issuer to indicate that no revocation information will be made + available for this AC. + + This extension MUST be non-critical. An AC verifier that does not + understand this extension might be able to find a revocation list + from the AC issuer, but the revocation list will never include an + entry for the AC. + + name id-ce-noRevAvail + OID { id-ce 56 } + syntax NULL (i.e. '0500'H is the DER encoding) + criticality MUST be FALSE + +4.4 Attribute Types + + Some of the attribute types defined below make use of the + IetfAttrSyntax type, also defined below. The reasons for using this + type are: + + 1. It allows a separation between the AC issuer and the attribute + policy authority. This is useful for situations where a single + policy authority (e.g. an organization) allocates attribute + values, but where multiple AC issuers are deployed for + performance or other reasons. + 2. The syntaxes allowed for values are restricted to OCTET STRING, + OBJECT IDENTIFIER, and UTF8String, which significantly reduces + the complexity associated with matching more general syntaxes. + All multi-valued attributes using this syntax are restricted so + that each value MUST use the same choice of value syntax. For + example, AC issuers must not use one value with an oid and a + second value with a string. + + +Farrell & Housley [Page 17] + +INTERNET-DRAFT August 2000 + + + IetfAttrSyntax ::= SEQUENCE { + policyAuthority [0] GeneralNames OPTIONAL, + values SEQUENCE OF CHOICE { + octets OCTET STRING, + oid OBJECT IDENTIFIER, + string UTF8String + } + } + + In the descriptions below, each attribute type is tagged as either + "Multiple Allowed" or "One Attribute value only; multiple values + within the IetfAttrSyntax". This refers to the SET OF + AttributeValue, the AttributeType still only occurs once, as + specified in section 4.2.7. + +4.4.1 Service Authentication Information + + The SvceAuthInfo attribute identifies the AC holder to the + server/service by a name, and the attribute MAY include optional + service specific authentication information. Typically this will + contain a username/password pair for a "legacy" application. + + This attribute provides information that can be presented by the AC + verifier to be interpreted and authenticated by a separate + application within the target system. Note that this is a different + use to that intended for the accessIdentity attribute in 4.4.2 + below. + + This attribute type will typically be encrypted when the authInfo + field contains sensitive information, such as a password. + + name id-aca-authenticationInfo + OID { id-aca 1 } + Syntax SvceAuthInfo + values: Multiple allowed + + SvceAuthInfo ::= SEQUENCE { + service GeneralName, + ident GeneralName, + authInfo OCTET STRING OPTIONAL + } + +4.4.2 Access Identity + + The accessIdentity attribute identifies the AC holder to the + server/service. For this attribute the authInfo field MUST NOT be + present. + + This attribute is intended to be used to provide information about + the AC holder, that can be used by the AC verifier (or a larger + system of which the AC verifier is a component) to authorize the + actions of the AC holder within the AC verifier's system. Note that + + +Farrell & Housley [Page 18] + +INTERNET-DRAFT August 2000 + + + this is a different use to that intended for the svceAuthInfo + attribute described in 4.4.1 above. + + name id-aca-accessIdentity + OID { id-aca 2 } + syntax SvceAuthInfo + values: Multiple allowed + +4.4.3 Charging Identity + + The chargingIdentity attribute identifies the AC holder for charging + purposes. In general, the charging identity will be different from + other identities of the holder. For example, the holder's company + may be charged for service. + + name id-aca-chargingIdentity + OID { id-aca 3 } + syntax IetfAttrSyntax + values: One Attribute value only; multiple values within the + IetfAttrSyntax + +4.4.4 Group + + The group attribute carries information about group memberships of + the AC holder. + + name id-aca-group + OID { id-aca 4 } + syntax IetfAttrSyntax + values: One Attribute value only; multiple values within the + IetfAttrSyntax + +4.4.5 Role + + The role attribute, specified in [X.509-2000], carries information + about role allocations of the AC holder. + + The syntax used for this attribute is: + + RoleSyntax ::= SEQUENCE { + roleAuthority [0] GeneralNames OPTIONAL, + roleName [1] GeneralName + } + + The roleAuthority field MAY be used to specify the issuing authority + for the role specification certificate. There is no requirement that + a role specification certificate necessarily exists for the + roleAuthority. This differs from [X.500-2000], where the + roleAuthority field is assumed to name the issuer of a role + specification certificate. For example, to distinguish the + administrator role as defined by "Baltimore" from that defined by + "SPYRUS", one could put the value "administrator" in the roleName + + +Farrell & Housley [Page 19] + +INTERNET-DRAFT August 2000 + + + field and the value "Baltimore" or "SPYRUS" in the roleAuthority + field. + + The roleName field MUST be present, and roleName MUST use the + uniformResourceIdentifier CHOICE of the GeneralName. + + name id-at-role + OID { id-at 72 } + syntax RoleSyntax + values: Multiple allowed + +4.4.6 Clearance + + The clearance attribute, specified in [X.501-1993], carries + clearance (associated with security labeling) information about the + AC holder. + + The policyId field is used to identify the security policy to which + the clearance relates. The policyId indicates the semantics of the + classList and securityCategories fields. + + This specification includes the classList field exactly as is + specified in [X.501-1993]. Additional security classification + values, and their position in the classification hierarchy, may be + defined by a security policy as a local matter or by bilateral + agreement. The basic security classification hierarchy is, in + ascending order: unmarked, unclassified, restricted, confidential, + secret, and top-secret. + + An organization can develop its own security policy that defines + security classification values and their meanings. However, the BIT + STRING positions 0 through 5 are reserved for the basic security + classification hierarchy. + + If present, the SecurityCategory field provides further + authorization information. The security policy identified by the + policyId field indicates the syntaxes that are allowed to be present + in the securityCategories SET. An OBJECT IDENTIFIER identifies each + of the allowed syntaxes. When one of these syntaxes is present in + the securityCategories SET, the OBJECT IDENTIFIER associated with + that syntax is carried in the SecurityCategory.type field. + + Clearance ::= SEQUENCE { + policyId OBJECT IDENTIFIER, + classList ClassList DEFAULT {unclassified}, + securityCategories + SET OF SecurityCategory OPTIONAL + } + + ClassList ::= BIT STRING { + unmarked (0), + unclassified (1), + restricted (2) + +Farrell & Housley [Page 20] + +INTERNET-DRAFT August 2000 + + + confidential (3), + secret (4), + topSecret (5) + } + + SecurityCategory ::= SEQUENCE { + type [0] IMPLICIT OBJECT IDENTIFIER, + value [1] ANY DEFINED BY type + } + + -- This is the same as the original syntax which was defined + -- using the MACRO construct, as follows: + -- SecurityCategory ::= SEQUENCE { + -- type [0] IMPLICIT SECURITY-CATEGORY, + -- value [1] ANY DEFINED BY type + -- } + -- + -- SECURITY-CATEGORY MACRO ::= + -- BEGIN + -- TYPE NOTATION ::= type | empty + -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) + -- END + + + + name { id-at-clearance } + OID { joint-iso-ccitt(2) ds(5) module(1) + selected-attribute-types(5) clearance (55) } + syntax Clearance - imported from [X.501-1993] + values Multiple allowed + +4.5 Profile of AC issuer's PKC + + The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage + extension in the PKC MUST NOT explicitly indicate that the AC + issuer's public key cannot be used to validate a digital signature. + In order to avoid confusion regarding serial numbers and + revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, + an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST + NOT have a basicConstraints extension with the cA BOOLEAN set to + TRUE. + + + + + + + + + + + + + +Farrell & Housley [Page 21] + +INTERNET-DRAFT August 2000 + + +5. Attribute Certificate Validation + + This section describes a basic set of rules that all valid ACs MUST + satisfy. Some additional checks are also described which AC + verifiers MAY choose to implement. + + To be valid an AC MUST satisfy all of the following: + + 1. The AC signature must be cryptographically correct, and the AC + issuer's entire PKC certification path MUST be verified in + accordance with [PKIXPROF]. + 2. The AC issuer's PKC MUST also conform to the profile specified + in section 4.5 above. + 3. The AC issuer MUST be directly trusted as an AC issuer (by + configuration or otherwise). + 4. The time for which the AC is being evaluated MUST be within the + AC validity. If the evaluation time is equal to either + notBeforeTime or notAfterTime, then the AC is timely and this + check succeeds. Note that in some applications, the evaluation + time MAY not be the same as the current time. + 5. The AC targeting check MUST pass as specified in section 4.3.2. + 6. If the AC contains an unsupported critical extension, then the + AC MUST be rejected. + + Support for an extension in this context means: + + 1. The AC verifier MUST be able to parse the extension value. + 2. Where the extension value SHOULD cause the AC to be rejected, + the AC verifier MUST reject the AC. + + Additional Checks: + + 1. The AC MAY be rejected on the basis of further AC verifier + configuration. For example, an AC verifier may be configured to + reject ACs which contain or lack certain attributes. + 2. If the AC verifier provides an interface that allows + applications to query the contents of the AC, then the AC + verifier MAY filter the attributes from the AC on the basis of + configured information. For example, an AC verifier might be + configured not to return certain attributes to certain servers. + + + + + + + + + + + + + + +Farrell & Housley [Page 22] + +INTERNET-DRAFT August 2000 + + +6. Revocation + + In many environments, the validity period of an AC is less than the + time required to issue and distribute revocation information. + Therefore, short-lived ACs typically do not require revocation + support. However, long-lived ACs and environments where ACs enable + high value transactions MAY require revocation support. + + Two revocation schemes are defined, and the AC issuer should elect + the one that is best suited to the environment in which the AC will + be employed. + + "Never revoke" scheme: + + ACs may be marked so that the relying party understands that no + revocation status information will be made available. The + noRevAvail extension is defined in section 4.3.6, and the + noRevAvail extension MUST be present in the AC to indicate use + of this scheme. + + Where no noRevAvail is not present, then the AC issuer is + implicitly stating that revocation status checks are supported, + and some revocation method MUST be provided to allow AC + verifiers to establish the revocation status of the AC. + + "Pointer in AC" scheme: + + ACs may "point" to sources of revocation status information, + using either an authorityInfoAccess extension or a + crlDistributionPoints extension within the AC. + + For AC users, the "never revoke" scheme MUST be supported, and the + "pointer in AC" scheme SHOULD be supported. If only the "never + revoke" scheme is supported, then all ACs that do not contain a + noRevAvail extension, MUST be rejected. + + For AC issuers, the "never revoke" scheme MUST be supported. If all + ACs that will ever be issued by that AC issuer, will contain a + noRevAvail extension, then the "pointer in AC" scheme need not be + supported. If any AC can be issued that does not contain the + noRevAvail extension, then the "pointer in AC" scheme MUST be + supported. + + + An AC verifier MAY use any source for AC revocation status + information. + + + + + + + + +Farrell & Housley [Page 23] + +INTERNET-DRAFT August 2000 + + +7. Optional Features + + This section specifies features that MAY be implemented. Conformance + to this profile does NOT require support for these features; + however, if these features are offered, they MUST be offered as + described below. + +7.1 Attribute Encryption + + Where an AC will be carried in clear within an application protocol + or where an AC contains some sensitive information like a legacy + application username/password, then encryption of AC attributes MAY + be needed. + + When a set of attributes are to be encrypted within an AC, the + Cryptographic Message Syntax, EnvelopedData structure [CMS] is used + to carry the ciphertext and associated per-recipient keying + information. + + This type of attribute encryption is targeted. Before the AC is + signed, the attributes are encrypted for a set of predetermined + recipients. + + The AC then contains the ciphertext inside its signed data. The + EenvelopedData (id-envelopedData) ContentType is used, and the + content field will contain the EnvelopedData type. + + The ciphertext is included in the AC as the value of an encAttrs + attribute. Only one encAttrs attribute can be present in an AC; + however, the encAttrs attribute MAY be multi-valued, and each of its + values will contain an independent EnvelopedData. + + 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). + +Farrell & Housley [Page 24] + +INTERNET-DRAFT August 2000 + + + + 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 attributes 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, then the decryption process MUST not fail. If decryption + does fail, then 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 + +Farrell & Housley [Page 25] + +INTERNET-DRAFT August 2000 + + + the sender of the AC are both named in the same proxy set then the + AC can 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. + +Farrell & Housley [Page 26] + +INTERNET-DRAFT August 2000 + + + 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, then 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 + + +Farrell & Housley [Page 27] + +INTERNET-DRAFT August 2000 + + + 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 + + + + + + + + + + + + + +Farrell & Housley [Page 28] + +INTERNET-DRAFT August 2000 + + +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. + + 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 + +Farrell & Housley [Page 29] + +INTERNET-DRAFT August 2000 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Farrell & Housley [Page 30] + +INTERNET-DRAFT August 2000 + + +9. References + + [CMC] Myers, M., et al. "Certificate Management Messages over + CMS", RFC2797. + [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key + Infrastructure - Certificate Management Protocols", + RFC2510. + [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. + [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", + RFC2634. + [KRB] Kohl, J., Neuman, C., "The Kerberos Network + Authentication Service (V5)", RFC 1510. + [LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol + (v3)", RFC 2251. + [OCSP] Myers, M., et al., " X.509 Internet Public Key + Infrastructure - Online Certificate Status Protocol - + OCSP", RFC 2560. + [PKIXALGS] Polk, T., Bassham, L., "Internet X.509 Public Key + Infrastructure Representation of Public Keys and Digital + Signatures in Internet X.509 Public Key Infrastructure + Certificates", draft-ietf-pkix-pkalgs-00.txt, work-in- + progress. + [PKINIT] Tung, B., et al., "Public Key Cryptography for Initial + Authentication in Kerberos", draft-ietf-cat-kerberos-pk- + init-11.txt, work-in-progress. + [PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet + Public Key Infrastructure - X.509 Certificate and CRL + Profile", draft-ietf-pkix-new-part1-02.txt, work-in- + progress. + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", RFC 2026, BCP 9, October 1996. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119. + [URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform + Resource Locators (URL)", RFC 1738. + [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 + + + +Farrell & Housley [Page 31] + +INTERNET-DRAFT August 2000 + + +Author's Addresses + + Stephen Farrell + Baltimore Technologies + 61/62 Fitzwilliam Lane + Dublin 2 + IRELAND + + tel: +353-1-647-3000 + email: stephen.farrell@baltimore.ie + + Russell Housley + SPYRUS + 381 Elden Street + Suite 1120 + Herndon, VA 20170 + USA + + tel: +1-703-707-0696 + email: housley@spyrus.com + +Full Copyright Statement + + Copyright (C) The Internet Society (date). 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. In addition, + the ASN.1 module presented in Appendix B may be used in whole or in + part without inclusion of the copyright notice. 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 shall 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. + + + + + +Farrell & Housley [Page 32] + +INTERNET-DRAFT August 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) } + + +Farrell & Housley [Page 33] + +INTERNET-DRAFT August 2000 + + +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 EXPLICIT 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, + +Farrell & Housley [Page 34] + +INTERNET-DRAFT August 2000 + + + signatureAlgorithm AlgorithmIdentifier, + signatureValue BIT STRING + } + + AttributeCertificateInfo ::= SEQUENCE { + version AttCertVersion DEFAULT v1, + holder Holder, + issuer AttCertIssuer, + signature AlgorithmIdentifier, + serialNumber CertificateSerialNumber, + attrCertValidityPeriod AttCertValidityPeriod, + attributes SEQUENCE OF Attribute, + issuerUniqueID UniqueIdentifier OPTIONAL, + extensions Extensions OPTIONAL + } + + AttCertVersion ::= INTEGER {v1(0), 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 + -- if present, version must be v2 + } + + 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, -- v1 or v2 + v2Form [0] V2Form -- v2 only + } + + V2Form ::= SEQUENCE { + issuerName GeneralNames OPTIONAL, + baseCertificateID [0] IssuerSerial OPTIONAL, + objectDigestInfo [1] ObjectDigestInfo OPTIONAL + -- at least one of issuerName, baseCertificateID + -- or objectDigestInfo must be present + } + + +Farrell & Housley [Page 35] + +INTERNET-DRAFT August 2000 + + + 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 OBJECT IDENTIFIER, + classList ClassList DEFAULT {unclassified}, + securityCategories + SET OF SecurityCategory OPTIONAL + } + + ClassList ::= BIT STRING { + +Farrell & Housley [Page 36] + +INTERNET-DRAFT August 2000 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + +Farrell & Housley [Page 37] + \ No newline at end of file diff --git a/doc/draft-ietf-tls-camellia-00.txt b/doc/protocol/draft-ietf-tls-camellia-00.txt similarity index 100% rename from doc/draft-ietf-tls-camellia-00.txt rename to doc/protocol/draft-ietf-tls-camellia-00.txt diff --git a/doc/draft-ietf-tls-ciphersuite-02.txt b/doc/protocol/draft-ietf-tls-ciphersuite-03.txt similarity index 84% rename from doc/draft-ietf-tls-ciphersuite-02.txt rename to doc/protocol/draft-ietf-tls-ciphersuite-03.txt index a5f6644467..ac0de90990 100644 --- a/doc/draft-ietf-tls-ciphersuite-02.txt +++ b/doc/protocol/draft-ietf-tls-ciphersuite-03.txt @@ -6,7 +6,7 @@ Network Working Group Pete Chown INTERNET DRAFT Skygate Technology - 15 November 2000 + 22 January 2001 AES Ciphersuites for TLS @@ -57,23 +57,19 @@ Overview Chown [Page 1] -ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 +ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001 therefore a desirable choice. 4. Currently the DHE ciphersuites only allow triple DES (along - with some ``export'' variants which offer reduced key lengths). - At the same time the DHE ciphersuites are the only ones to - offer forward secrecy. + with some ``export'' variants which do not use a satisfactory + key length). At the same time the DHE ciphersuites are the + only ones to offer forward secrecy. This document proposes several new ciphersuites, with the aim of overcoming these problems. - 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 RFC 2119. - Cipher Usage The new ciphersuites proposed here are very similar to the follow­ @@ -96,6 +92,30 @@ Cipher Usage method. The ciphersuites defined here use the following options for this part of the protocol: + + + + + + + + + + + + + + + + + + + +Chown [Page 2] + +ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001 + + CipherSuite Certificate type (if applicable) and key exchange algorithm @@ -106,21 +126,22 @@ Cipher Usage TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon + TLS_RSA_WITH_AES_256_CBC_SHA RSA + TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS + TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA + TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS + TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA + TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon + For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon, please refer to sections 7.4.2 and 7.4.3 of [TLS]. - - -Chown [Page 2] - -ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 - - - The AES supports key lengths of 128, 192 and 256 bits. At the pre­ - sent time, all of these are believed to be secure against even the - best equipped attackers. The overall strength of TLS is such that - there is no gain from using a key length longer than 128 bits. - Accordingly the AES will use 128 bit keys. + The AES supports key lengths of 128, 192 and 256 bits. However, + this document only defines ciphersuites for 128- and 256-bit keys. + This is to avoid unnecessary proliferation of ciphersuites. Rijn­ + dael actually allows for 192- and 256-bit block sizes as well as + the 128-bit blocks mandated by the AES process. The ciphersuites + defined here all use 128-bit blocks. The new ciphersuites will have the following definitions: @@ -131,27 +152,26 @@ ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; - In the absence of an application profile standard specifying other­ - wise: - - 1. Servers MUST provide at least one of - TLS_RSA_WITH_AES_128_CBC_SHA and - TLS_DHE_RSA_WITH_AES_128_CBC_SHA. - - 2. Clients MUST provide both TLS_RSA_WITH_AES_128_CBC_SHA and - TLS_DHE_RSA_WITH_AES_128_CBC_SHA. - - (A TLS implementation which does not follow this requirement is - non-compliant with this RFC. However, it will still be a valid TLS - implementation if it complies with [TLS].) + CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 }; + CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 }; + CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 }; + CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 }; + CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 }; + CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; - Implementations MAY provide any of the other ciphersuites described - above. Security Considerations It is not believed that the new ciphersuites are ever less secure than the corresponding older ones. The AES is believed to be + + + +Chown [Page 3] + +ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001 + + secure, and it has withstood extensive cryptanalytic attack. The ephemeral Diffie-Hellman ciphersuites provide forward secrecy @@ -159,26 +179,19 @@ Security Considerations the maximum benefit from these ciphersuites: 1. The ephemeral keys should only be used once. With the TLS pro­ - tocol as currently defined there is no efficiency gain from - reusing ephemeral keys. + tocol as currently defined there is no significant efficiency + gain from reusing ephemeral keys. 2. Ephemeral keys should be destroyed securely when they are no longer required. - - -Chown [Page 3] - -ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 - - 3. The random number generator used to create ephemeral keys must not reveal past output even when its internal state is compro­ mised. [TLS] describes the anonymous Diffie-Hellman (ADH) ciphersuites as - deprecated. The ADH ciphersuite defined here is not deprecated. - However, when it is used, particular care must be taken: + deprecated. The ADH ciphersuites defined here are not deprecated. + However, when they are used, particular care must be taken: 1. ADH provides confidentiality but not authentication. This means that (if authentication is required) the communicating @@ -195,9 +208,9 @@ ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 compute a MAC of the TLS Finished message. An attacker would have to negotiate two different TLS connections; one with each communicating party. The Finished messages would be different - in each case, because they depend on the master secret. For - this reason, the MACs computed by each party would be differ­ - ent. + in each case, because they depend on the parties' public keys + (among other things). For this reason, the MACs computed by + each party would be different. It is important to note that authentication techniques which do not use the Finished message do not usually provide protection @@ -207,7 +220,15 @@ ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 Copyright - Copyright (C) The Internet Society 2000. All Rights Reserved. + + + +Chown [Page 4] + +ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001 + + + Copyright (C) The Internet Society 2001. 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 @@ -220,14 +241,6 @@ Copyright Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the proce­ dures for copyrights defined in the Internet Standards process must - - - -Chown [Page 4] - -ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 - - be followed, or as required to translate it into languages other than English. @@ -263,6 +276,14 @@ Intellectual Property this standard. Please address the information to the IETF Executive Director. + + + +Chown [Page 5] + +ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001 + + During the development of the AES, NIST published the following statement on intellectual property: @@ -276,14 +297,6 @@ Intellectual Property hereby gives public notice that it may seek redress under the antitrust laws of the United States against any party in the future who might seek to exercise patent rights - - - -Chown [Page 5] - -ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 - - against any user of AES that have not been disclosed to NIST in response to this request for information. @@ -318,11 +331,20 @@ ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 understand that the U.S. Government may, during the course of the lifetime of the AES or during the FIPS pub­ lic review process, modify the algorithm's specifications - (e.g., to protect against a newly discovered vulnerabil­ - ity). Should my submission be selected for inclusion in - the AES, I hereby agree not to place any restrictions on - the use of the algorithm intending it to be available on - a worldwide, non-exclusive, royalty-free basis. + (e.g., to protect against a newly discovered + + + +Chown [Page 6] + +ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001 + + + vulnerability). Should my submission be selected for + inclusion in the AES, I hereby agree not to place any + restrictions on the use of the algorithm intending it to + be available on a worldwide, non-exclusive, royalty-free + basis. I do hereby agree to provide the statements for any patent or patent application identified to cover practice @@ -331,15 +353,6 @@ ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 implementations for the purposes of the AES evaluation process. - - - - -Chown [Page 6] - -ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 - - I understand that NIST will announce the selected algo­ rithm(s) and proceed to publish the draft FIPS for public comment. If my algorithm (or the derived algorithm) is @@ -375,6 +388,14 @@ ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 implementations. + + + +Chown [Page 7] + +ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001 + + [signed] Joan Daemen, Vincent Rijmen @@ -388,14 +409,6 @@ References [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0" RFC-2246. January, 1999. - - - -Chown [Page 7] - -ietf-tls-ciphersuite-02 AES Ciphersuites for TLS 15 November 2000 - - [AES] J. Daemen, V. Rijmen, "The Rijndael Block Cipher" http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf 3rd September 1999. @@ -426,19 +439,6 @@ Author's Address - - - - - - - - - - - - - diff --git a/doc/draft-ietf-tls-https-04.txt b/doc/protocol/draft-ietf-tls-https-04.txt similarity index 100% rename from doc/draft-ietf-tls-https-04.txt rename to doc/protocol/draft-ietf-tls-https-04.txt diff --git a/doc/draft-ietf-tls-misty1-00.txt b/doc/protocol/draft-ietf-tls-misty1-00.txt similarity index 100% rename from doc/draft-ietf-tls-misty1-00.txt rename to doc/protocol/draft-ietf-tls-misty1-00.txt diff --git a/doc/draft-ietf-tls-openpgp-00.txt b/doc/protocol/draft-ietf-tls-openpgp-00.txt similarity index 100% rename from doc/draft-ietf-tls-openpgp-00.txt rename to doc/protocol/draft-ietf-tls-openpgp-00.txt diff --git a/doc/draft-ietf-tls-seedhas-00.txt b/doc/protocol/draft-ietf-tls-seedhas-00.txt similarity index 100% rename from doc/draft-ietf-tls-seedhas-00.txt rename to doc/protocol/draft-ietf-tls-seedhas-00.txt diff --git a/doc/draft-ietf-tls-wireless-00.txt b/doc/protocol/draft-ietf-tls-wireless-00.txt similarity index 100% rename from doc/draft-ietf-tls-wireless-00.txt rename to doc/protocol/draft-ietf-tls-wireless-00.txt diff --git a/doc/draft-ietf-tn3270e-telnet-tls-05.txt b/doc/protocol/draft-ietf-tn3270e-telnet-tls-05.txt similarity index 100% rename from doc/draft-ietf-tn3270e-telnet-tls-05.txt rename to doc/protocol/draft-ietf-tn3270e-telnet-tls-05.txt diff --git a/doc/rfc1422.txt b/doc/protocol/rfc1422.txt similarity index 100% rename from doc/rfc1422.txt rename to doc/protocol/rfc1422.txt diff --git a/doc/rfc1423.txt b/doc/protocol/rfc1423.txt similarity index 100% rename from doc/rfc1423.txt rename to doc/protocol/rfc1423.txt diff --git a/doc/rfc2246.txt b/doc/protocol/rfc2246.txt similarity index 100% rename from doc/rfc2246.txt rename to doc/protocol/rfc2246.txt diff --git a/doc/protocol/rfc2279.txt b/doc/protocol/rfc2279.txt new file mode 100644 index 0000000000..3a3495cbe4 --- /dev/null +++ b/doc/protocol/rfc2279.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group F. Yergeau +Request for Comments: 2279 Alis Technologies +Obsoletes: 2044 January 1998 +Category: Standards Track + + + UTF-8, a transformation format of ISO 10646 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + ISO/IEC 10646-1 defines a multi-octet character set called the + Universal Character Set (UCS) which encompasses most of the world's + writing systems. Multi-octet characters, however, are not compatible + with many current applications and protocols, and this has led to the + development of a few so-called UCS transformation formats (UTF), each + with different characteristics. UTF-8, the object of this memo, has + the characteristic of preserving the full US-ASCII range, providing + compatibility with file systems, parsers and other software that rely + on US-ASCII values but are transparent to other values. This memo + updates and replaces RFC 2044, in particular addressing the question + of versions of the relevant standards. + +1. Introduction + + ISO/IEC 10646-1 [ISO-10646] defines a multi-octet character set + called the Universal Character Set (UCS), which encompasses most of + the world's writing systems. Two multi-octet encodings are defined, + a four-octet per character encoding called UCS-4 and a two-octet per + character encoding called UCS-2, able to address only the first 64K + characters of the UCS (the Basic Multilingual Plane, BMP), outside of + which there are currently no assignments. + + It is noteworthy that the same set of characters is defined by the + Unicode standard [UNICODE], which further defines additional + character properties and other application details of great interest + to implementors, but does not have the UCS-4 encoding. Up to the + + + +Yergeau Standards Track [Page 1] + +RFC 2279 UTF-8 January 1998 + + + present time, changes in Unicode and amendments to ISO/IEC 10646 have + tracked each other, so that the character repertoires and code point + assignments have remained in sync. The relevant standardization + committees have committed to maintain this very useful synchronism. + + The UCS-2 and UCS-4 encodings, however, are hard to use in many + current applications and protocols that assume 8 or even 7 bit + characters. Even newer systems able to deal with 16 bit characters + cannot process UCS-4 data. This situation has led to the development + of so-called UCS transformation formats (UTF), each with different + characteristics. + + UTF-1 has only historical interest, having been removed from ISO/IEC + 10646. UTF-7 has the quality of encoding the full BMP repertoire + using only octets with the high-order bit clear (7 bit US-ASCII + values, [US-ASCII]), and is thus deemed a mail-safe encoding + ([RFC2152]). UTF-8, the object of this memo, uses all bits of an + octet, but has the quality of preserving the full US-ASCII range: + US-ASCII characters are encoded in one octet having the normal US- + ASCII value, and any octet with such a value can only stand for an + US-ASCII character, and nothing else. + + UTF-16 is a scheme for transforming a subset of the UCS-4 repertoire + into pairs of UCS-2 values from a reserved range. UTF-16 impacts + UTF-8 in that UCS-2 values from the reserved range must be treated + specially in the UTF-8 transformation. + + UTF-8 encodes UCS-2 or UCS-4 characters as a varying number of + octets, where the number of octets, and the value of each, depend on + the integer value assigned to the character in ISO/IEC 10646. This + transformation format has the following characteristics (all values + are in hexadecimal): + + - Character values from 0000 0000 to 0000 007F (US-ASCII repertoire) + correspond to octets 00 to 7F (7 bit US-ASCII values). A direct + consequence is that a plain ASCII string is also a valid UTF-8 + string. + + - US-ASCII values do not appear otherwise in a UTF-8 encoded + character stream. This provides compatibility with file systems + or other software (e.g. the printf() function in C libraries) that + parse based on US-ASCII values but are transparent to other + values. + + - Round-trip conversion is easy between UTF-8 and either of UCS-4, + UCS-2. + + + + + +Yergeau Standards Track [Page 2] + +RFC 2279 UTF-8 January 1998 + + + - The first octet of a multi-octet sequence indicates the number of + octets in the sequence. + + - The octet values FE and FF never appear. + + - Character boundaries are easily found from anywhere in an octet + stream. + + - The lexicographic sorting order of UCS-4 strings is preserved. Of + course this is of limited interest since the sort order is not + culturally valid in either case. + + - The Boyer-Moore fast search algorithm can be used with UTF-8 data. + + - UTF-8 strings can be fairly reliably recognized as such by a + simple algorithm, i.e. the probability that a string of characters + in any other encoding appears as valid UTF-8 is low, diminishing + with increasing string length. + + UTF-8 was originally a project of the X/Open Joint + Internationalization Group XOJIG with the objective to specify a File + System Safe UCS Transformation Format [FSS-UTF] that is compatible + with UNIX systems, supporting multilingual text in a single encoding. + The original authors were Gary Miller, Greger Leijonhufvud and John + Entenmann. Later, Ken Thompson and Rob Pike did significant work for + the formal UTF-8. + + A description can also be found in Unicode Technical Report #4 and in + the Unicode Standard, version 2.0 [UNICODE]. The definitive + reference, including provisions for UTF-16 data within UTF-8, is + Annex R of ISO/IEC 10646-1 [ISO-10646]. + +2. UTF-8 definition + + In UTF-8, characters are encoded using sequences of 1 to 6 octets. + The only octet of a "sequence" of one has the higher-order bit set to + 0, the remaining 7 bits being used to encode the character value. In + a sequence of n octets, n>1, the initial octet has the n higher-order + bits set to 1, followed by a bit set to 0. The remaining bit(s) of + that octet contain bits from the value of the character to be + encoded. The following octet(s) all have the higher-order bit set to + 1 and the following bit set to 0, leaving 6 bits in each to contain + bits from the character to be encoded. + + The table below summarizes the format of these different octet types. + The letter x indicates bits available for encoding bits of the UCS-4 + character value. + + + + +Yergeau Standards Track [Page 3] + +RFC 2279 UTF-8 January 1998 + + + UCS-4 range (hex.) UTF-8 octet sequence (binary) + 0000 0000-0000 007F 0xxxxxxx + 0000 0080-0000 07FF 110xxxxx 10xxxxxx + 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx + + 0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx + 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx + 0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx + + Encoding from UCS-4 to UTF-8 proceeds as follows: + + 1) Determine the number of octets required from the character value + and the first column of the table above. It is important to note + that the rows of the table are mutually exclusive, i.e. there is + only one valid way to encode a given UCS-4 character. + + 2) Prepare the high-order bits of the octets as per the second column + of the table. + + 3) Fill in the bits marked x from the bits of the character value, + starting from the lower-order bits of the character value and + putting them first in the last octet of the sequence, then the + next to last, etc. until all x bits are filled in. + + The algorithm for encoding UCS-2 (or Unicode) to UTF-8 can be + obtained from the above, in principle, by simply extending each + UCS-2 character with two zero-valued octets. However, pairs of + UCS-2 values between D800 and DFFF (surrogate pairs in Unicode + parlance), being actually UCS-4 characters transformed through + UTF-16, need special treatment: the UTF-16 transformation must be + undone, yielding a UCS-4 character that is then transformed as + above. + + Decoding from UTF-8 to UCS-4 proceeds as follows: + + 1) Initialize the 4 octets of the UCS-4 character with all bits set + to 0. + + 2) Determine which bits encode the character value from the number of + octets in the sequence and the second column of the table above + (the bits marked x). + + 3) Distribute the bits from the sequence to the UCS-4 character, + first the lower-order bits from the last octet of the sequence and + proceeding to the left until no x bits are left. + + If the UTF-8 sequence is no more than three octets long, decoding + can proceed directly to UCS-2. + + + +Yergeau Standards Track [Page 4] + +RFC 2279 UTF-8 January 1998 + + + NOTE -- actual implementations of the decoding algorithm above + should protect against decoding invalid sequences. For + instance, a naive implementation may (wrongly) decode the + invalid UTF-8 sequence C0 80 into the character U+0000, which + may have security consequences and/or cause other problems. See + the Security Considerations section below. + + A more detailed algorithm and formulae can be found in [FSS_UTF], + [UNICODE] or Annex R to [ISO-10646]. + +3. Versions of the standards + + ISO/IEC 10646 is updated from time to time by published amendments; + similarly, different versions of the Unicode standard exist: 1.0, 1.1 + and 2.0 as of this writing. Each new version obsoletes and replaces + the previous one, but implementations, and more significantly data, + are not updated instantly. + + In general, the changes amount to adding new characters, which does + not pose particular problems with old data. Amendment 5 to ISO/IEC + 10646, however, has moved and expanded the Korean Hangul block, + thereby making any previous data containing Hangul characters invalid + under the new version. Unicode 2.0 has the same difference from + Unicode 1.1. The official justification for allowing such an + incompatible change was that no implementations and no data + containing Hangul existed, a statement that is likely to be true but + remains unprovable. The incident has been dubbed the "Korean mess", + and the relevant committees have pledged to never, ever again make + such an incompatible change. + + New versions, and in particular any incompatible changes, have q + conseuences regarding MIME character encoding labels, to be discussed + in section 5. + +4. Examples + + The UCS-2 sequence "A." (0041, 2262, 0391, + 002E) may be encoded in UTF-8 as follows: + + 41 E2 89 A2 CE 91 2E + + The UCS-2 sequence representing the Hangul characters for the Korean + word "hangugo" (D55C, AD6D, C5B4) may be encoded as follows: + + ED 95 9C EA B5 AD EC 96 B4 + + + + + + +Yergeau Standards Track [Page 5] + +RFC 2279 UTF-8 January 1998 + + + The UCS-2 sequence representing the Han characters for the Japanese + word "nihongo" (65E5, 672C, 8A9E) may be encoded as follows: + + E6 97 A5 E6 9C AC E8 AA 9E + +5. MIME registration + + This memo is meant to serve as the basis for registration of a MIME + character set parameter (charset) [CHARSET-REG]. The proposed + charset parameter value is "UTF-8". This string labels media types + containing text consisting of characters from the repertoire of + ISO/IEC 10646 including all amendments at least up to amendment 5 + (Korean block), encoded to a sequence of octets using the encoding + scheme outlined above. UTF-8 is suitable for use in MIME content + types under the "text" top-level type. + + It is noteworthy that the label "UTF-8" does not contain a version + identification, referring generically to ISO/IEC 10646. This is + intentional, the rationale being as follows: + + A MIME charset label is designed to give just the information needed + to interpret a sequence of bytes received on the wire into a sequence + of characters, nothing more (see RFC 2045, section 2.2, in [MIME]). + As long as a character set standard does not change incompatibly, + version numbers serve no purpose, because one gains nothing by + learning from the tag that newly assigned characters may be received + that one doesn't know about. The tag itself doesn't teach anything + about the new characters, which are going to be received anyway. + + Hence, as long as the standards evolve compatibly, the apparent + advantage of having labels that identify the versions is only that, + apparent. But there is a disadvantage to such version-dependent + labels: when an older application receives data accompanied by a + newer, unknown label, it may fail to recognize the label and be + completely unable to deal with the data, whereas a generic, known + label would have triggered mostly correct processing of the data, + which may well not contain any new characters. + + Now the "Korean mess" (ISO/IEC 10646 amendment 5) is an incompatible + change, in principle contradicting the appropriateness of a version + independent MIME charset label as described above. But the + compatibility problem can only appear with data containing Korean + Hangul characters encoded according to Unicode 1.1 (or equivalently + ISO/IEC 10646 before amendment 5), and there is arguably no such data + to worry about, this being the very reason the incompatible change + was deemed acceptable. + + + + + +Yergeau Standards Track [Page 6] + +RFC 2279 UTF-8 January 1998 + + + In practice, then, a version-independent label is warranted, provided + the label is understood to refer to all versions after Amendment 5, + and provided no incompatible change actually occurs. Should + incompatible changes occur in a later version of ISO/IEC 10646, the + MIME charset label defined here will stay aligned with the previous + version until and unless the IETF specifically decides otherwise. + + It is also proposed to register the charset parameter value + "UNICODE-1-1-UTF-8", for the exclusive purpose of labelling text data + containing Hangul syllables encoded to UTF-8 without taking into + account Amendment 5 of ISO/IEC 10646 (i.e. using the pre-amendment 5 + code point assignments). Any other UTF-8 data SHOULD NOT use this + label, in particular data not containing any Hangul syllables, and it + is felt important to strongly recommend against creating any new + Hangul-containing data without taking Amendment 5 of ISO/IEC 10646 + into account. + +6. Security Considerations + + Implementors of UTF-8 need to consider the security aspects of how + they handle illegal UTF-8 sequences. It is conceivable that in some + circumstances an attacker would be able to exploit an incautious + UTF-8 parser by sending it an octet sequence that is not permitted by + the UTF-8 syntax. + + A particularly subtle form of this attack could be carried out + against a parser which performs security-critical validity checks + against the UTF-8 encoded form of its input, but interprets certain + illegal octet sequences as characters. For example, a parser might + prohibit the NUL character when encoded as the single-octet sequence + 00, but allow the illegal two-octet sequence C0 80 and interpret it + as a NUL character. Another example might be a parser which + prohibits the octet sequence 2F 2E 2E 2F ("/../"), yet permits the + illegal octet sequence 2F C0 AE 2E 2F. + +Acknowledgments + + The following have participated in the drafting and discussion of + this memo: + + James E. Agenbroad Andries Brouwer + Martin J. D|rst Ned Freed + David Goldsmith Edwin F. Hart + Kent Karlsson Markus Kuhn + Michael Kung Alain LaBonte + John Gardiner Myers Murray Sargent + Keld Simonsen Arnold Winkler + + + + +Yergeau Standards Track [Page 7] + +RFC 2279 UTF-8 January 1998 + + +Bibliography + + [CHARSET-REG] Freed, N., and J. Postel, "IANA Charset Registration + Procedures", BCP 19, RFC 2278, January 1998. + + [FSS_UTF] X/Open CAE Specification C501 ISBN 1-85912-082-2 28cm. + 22p. pbk. 172g. 4/95, X/Open Company Ltd., "File + System Safe UCS Transformation Format (FSS_UTF)", + X/Open Preleminary Specification, Document Number + P316. Also published in Unicode Technical Report #4. + + [ISO-10646] ISO/IEC 10646-1:1993. International Standard -- + Information technology -- Universal Multiple-Octet + Coded Character Set (UCS) -- Part 1: Architecture and + Basic Multilingual Plane. Five amendments and a + technical corrigendum have been published up to now. + UTF-8 is described in Annex R, published as Amendment + 2. UTF-16 is described in Annex Q, published as + Amendment 1. 17 other amendments are currently at + various stages of standardization. + + [MIME] Freed, N., and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", RFC 2045. N. Freed, N. Borenstein, + "Multipurpose Internet Mail Extensions (MIME) Part + Two: Media Types", RFC 2046. K. Moore, "MIME + (Multipurpose Internet Mail Extensions) Part Three: + Message Header Extensions for Non-ASCII Text", RFC + 2047. N. Freed, J. Klensin, J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: + Registration Procedures", RFC 2048. N. Freed, N. + Borenstein, " Multipurpose Internet Mail Extensions + (MIME) Part Five: Conformance Criteria and Examples", + RFC 2049. All November 1996. + + [RFC2152] Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe + Transformation Format of Unicode", RFC 1642, Taligent + inc., May 1997. (Obsoletes RFC1642) + + [UNICODE] The Unicode Consortium, "The Unicode Standard -- + Version 2.0", Addison-Wesley, 1996. + + [US-ASCII] Coded Character Set--7-bit American Standard Code for + Information Interchange, ANSI X3.4-1986. + + + + + + + +Yergeau Standards Track [Page 8] + +RFC 2279 UTF-8 January 1998 + + +Author's Address + + Francois Yergeau + Alis Technologies + 100, boul. Alexis-Nihon + Suite 600 + Montreal QC H4M 2P2 + Canada + + Phone: +1 (514) 747-2547 + Fax: +1 (514) 747-2561 + EMail: fyergeau@alis.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yergeau Standards Track [Page 9] + +RFC 2279 UTF-8 January 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). 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. + + + + + + + + + + + + + + + + + + + + + + + + +Yergeau Standards Track [Page 10] + diff --git a/doc/rfc2459.txt b/doc/protocol/rfc2459.txt similarity index 100% rename from doc/rfc2459.txt rename to doc/protocol/rfc2459.txt diff --git a/doc/rfc2818.txt b/doc/protocol/rfc2818.txt similarity index 100% rename from doc/rfc2818.txt rename to doc/protocol/rfc2818.txt diff --git a/doc/ssl-draft302.txt b/doc/protocol/ssl-draft302.txt similarity index 100% rename from doc/ssl-draft302.txt rename to doc/protocol/ssl-draft302.txt