draft-ietf-smime-domsec-00.txt   draft-ietf-smime-domsec-01.txt 
Internet Draft T Dean Internet Draft T Dean
draft-ietf-smime-domsec-00.txt W Ottaway draft-ietf-smime-domsec-01.txt W Ottaway
July 15, 1998 DERA November 17, 1998 DERA
Expires in six months Expires in six months
Domain Security Services using S/MIME Domain Security Services using S/MIME
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at line 51 skipping to change at line 51
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
in the body of the message. There is a Web site for the mailing list at in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>. <http://www.imc.org/ietf-smime/>.
Acknowledgements Acknowledgements
Significant comments were made by Trevor Freeman, Russ Housley, Dave Kemp Significant comments were made by Trevor Freeman, Russ Housley, Dave
and Jim Schaad. Kemp and Jim Schaad.
1. Introduction 1. Introduction
The S/MIME [1] series of standards define a data encapsulation format The S/MIME [1] series of standards define a data encapsulation format
for the provision of a number of security services including data for the provision of a number of security services including data
integrity, confidentiality, and authentication. S/MIME is designed for integrity, confidentiality, and authentication. S/MIME is designed for
use by messaging clients to deliver security services to distributed use by messaging clients to deliver security services to distributed
messaging applications. messaging applications.
There are many circumstances when it is not feasible or practical to There are many circumstances when it is not feasible or practical to
provide end-to-end (ædesktop-to-desktopÆ) security services, provide end-to-end ('desktop-to-desktop') security services,
particularly between different security domains. An organisation which particularly between different security domains. An organisation which
is considering providing end-to-end security services will typically is considering providing end-to-end security services will typically
have to deal with some if not all of the following issues: have to deal with some if not all of the following issues:
1) Heterogeneous Message Access Methods: users are accessing mail using 1) Heterogeneous Message Access Methods: users are accessing mail using
mechanisms which re-format messages, such as using Web browsers. mechanisms which re-format messages, such as using Web browsers.
Message reformatting in the Message Store makes end-to-end encryption Message reformatting in the Message Store makes end-to-end encryption
and signature validation impossible. and signature validation impossible.
2) Message screening and audit: server-based mechanisms such as 2) Message screening and audit: server-based mechanisms such as
skipping to change at line 93 skipping to change at line 93
4) Heterogeneous Message transports: one organisation using X.400 wishes 4) Heterogeneous Message transports: one organisation using X.400 wishes
to communicate with another using SMTP. Message reformatting at to communicate with another using SMTP. Message reformatting at
gateways makes end-to-end encryption and signature validation gateways makes end-to-end encryption and signature validation
impossible. impossible.
5) Cost: providing the necessary key management infrastructure and other 5) Cost: providing the necessary key management infrastructure and other
items such as hardware tokens for all users may be too expensive. items such as hardware tokens for all users may be too expensive.
One solution to these problems is to provide message security services One solution to these problems is to provide message security services
at the level of a domain or an organisation. This document specifies how at the level of a domain or an organisation. This document specifies how
these ædomain security servicesÆ can be provided using the S/MIME these 'domain security services' can be provided using the S/MIME
protocol. Domain security services may replace or complement mechanisms protocol. Domain security services may replace or complement mechanisms
at the desktop. For example, a domain may decide to provide desktop-to- at the desktop. For example, a domain may decide to provide desktop-to-
desktop signatures but domain-to-domain encryption services. Or it may desktop signatures but domain-to-domain encryption services. Or it may
allow desktop-to-desktop services for intra-domain use, but enforce allow desktop-to-desktop services for intra-domain use, but enforce
domain-based services for communication with other domains. domain-based services for communication with other domains.
Messages can be processed and generated by a number of components of a Messages can be processed and generated by a number of components of a
messaging system, such as message transfer agents, guards and gateways. messaging system, such as message transfer agents, guards and gateways.
Any of these agents may provide domain security services. Any of these agents may provide domain security services.
The term 'Third Party' as used in this document means any entity in a The term 'Third Party' as used in this document means any entity in a
messaging system other than the originator and final recipient(s) that messaging system other than the originator and final recipient(s) that
processes messages. This includes Message Transfer Agents (MTAs), processes messages. This includes Message Transfer Agents (MTAs),
domain mail servers, guards and firewalls operating at security domain mail servers, guards and firewalls operating at security
boundaries, and gateways that translate between different protocol boundaries, and gateways that translate between different protocol
formats. A third party may sign, encrypt, decrypt, and check signatures formats. A third party may sign, encrypt, decrypt, and check signatures
on a message. on a message.
Throughout this draft the terms MUST, MUST NOT and SHOULD NOT are used Throughout this draft the terms MAY, MUST, MUST NOT and SHOULD NOT are
in capital letters. This conforms to the definitions in [2]. used in capital letters. This conforms to the definitions in [2].
2. Overview of Domain Security Services 2. Overview of Domain Security Services
In a distributed system, a message is sent from an originator to a set In a distributed system, a message is sent from an originator to a set
of recipients that may be in the same or different security domains. of recipients that may be in the same or different security domains.
This section first defines what is meant by a security domain. It then This section first defines what is meant by a security domain. It then
gives an informal overview of the security services that are provided by gives an informal overview of the security services that are provided by
S/MIME between different security domains. These services are provided S/MIME between different security domains. These services are provided
by a combination of mechanisms in the sender's and recipient's domains. by a combination of mechanisms in the sender's and recipient's domains.
Later sections describe definitively how these services map onto Later sections describe definitively how these services map onto
skipping to change at line 138 skipping to change at line 138
A 'security domain' is defined as a collection of hardware and personnel A 'security domain' is defined as a collection of hardware and personnel
operating under a single security authority and performing a common operating under a single security authority and performing a common
business function. Members of a security domain will of necessity share business function. Members of a security domain will of necessity share
a high degree of mutual trust, due to their shared aims and objectives. a high degree of mutual trust, due to their shared aims and objectives.
A security domain is typically protected from direct outside attack by A security domain is typically protected from direct outside attack by
physical measures and from indirect (electronic) attack by a combination physical measures and from indirect (electronic) attack by a combination
of firewalls and guards at network boundaries. The interface between two of firewalls and guards at network boundaries. The interface between two
security domains is termed a 'security boundary'. One example of a security domains is termed a 'security boundary'. One example of a
security domain is an organisational network ('Intranet'). security domain is an organisational network ('Intranet').
2.2 Domain Signature 2.2 Signing by a third party
A domain signature is a S/MIME SignerInfo [3] created on behalf of a
collection of users in a domain. A domain signature can be used when
end users do not have signing capabilities at the desktop. It can also
be used to bridge between two domains that have incompatible or
disconnected signature systems, such as when there are no cross-
certificate links between their Public Key Infrastructures (PKIs). In
this case a process which creates a Domain Signature first checks the
originator's signature using the source Domain's PKI. It then re-signs
the message using its key and certificate from the destination Domain's
PKI, which can then be verified by the recipient(s).
A domain signature can also be used in situations when messages need to
be reformatted inside the message transfer system. Message reformatting
is needed at gateways between X.400 and SMTP-MIME domains, or on
conversion between HTTP-MIME and SMTP-MIME message representations. In
both cases the recipient is unable to verify the originator's signature.
Therefore, a Domain Signature is generated at the reformatting point to
indicate that the originator's signature has been authenticated.
2.3 Domain Encryption A third-party may sign messages for one or more of the following reasons:
Domain encryption is S/MIME encryption performed on behalf of a 1. When messages need to be reformatted inside the message transfer
collection of users in a domain. Domain encryption can be used to system. Message reformatting is needed at gateways between X.400 and
protect information between domains, for example, when two 'Intranets' SMTP-MIME domains, or on conversion between HTTP-MIME and SMTP-MIME
are connected using the Internet. It can also be used when end users do message representations. The third party signature is needed because
not have encryption capabilities at the desktop, or when two domains the reformatting process renders the originator's signature
employ incompatible encryption schemes. In the latter case messages unverifiable by the recipient(s).
from the originator's domain are re-encrypted using an algorithm, key,
and certificate which can be decrypted by the recipient(s).
2.4 Additional Attributes 2. To bridge between two domains that have incompatible or disconnected
signature systems, such as when there are no cross-certificate links
between their Public Key Infrastructures (PKIs). The third party
signature is needed because the originator's signature is not
directly verifiable by the recipient(s). It is typically created at
the boundary between the domains.
A third party in a domain may attach additional signed attributes to a 3. When end users do not have signing capabilities at the desktop.
message. This is for one of the following reasons:
1) To add domain-wide attributes such as a domain security label of a A third party may wish to convey the signature semantics to the
'system-high' domain. recipient(s) when creating its digital signature. This document
specifies three signature types to convey these semantics, as follows.
2) To add mapped attributes, for processing by recipients in a domain A third party may sign a message, and optionally add additional
different from that of the originator. An example is the addition of attributes to it. An example is the addition of the 'Equivalent Label'
the 'Equivalent Label' attribute defined in ESS [4]. attribute defined in ESS [4]. In this case the 'additional attributes'
signature is used.
2.5 Message Review and Release A third party may wish to declare that it is acting as a proxy on
behalf of an originator in a domain. In this case the 'Domain'
Signature is used.
A third party may review messages before they are released from a A third party may review messages before they are released from a
domain. This is used when organisational policy or good security domain. This is used when organisational policy or good security
practice require that messages be reviewed before they are released to practice require that messages be reviewed before they are released to
external recipients. Having reviewed a message, a review and release external recipients. Having reviewed a message, a 'review and release'
signature is added to it. The review and release signature may be signature is added to it. The review and release signature may be
checked by a firewall at the domain boundary, to ensure that only checked by a firewall at the domain boundary, to ensure that only
reviewed messages are released. reviewed messages are released.
Details of the review process are outside the scope of this document, 2.3 Domain Encryption
but may involve scanning message contents for viruses or other malicious
code, searching for prohibited words or other content, or checking for Domain encryption is S/MIME encryption performed on behalf of a
the presence or absence of certain security labels. Review and release collection of users in a domain. Domain encryption can be used to
may be performed by a human reviewer or an automated process. protect information between domains, for example, when two 'Intranets'
are connected using the Internet. It can also be used when end users do
not have encryption capabilities at the desktop, or when two domains
employ incompatible encryption schemes. In the latter case messages
from the originator's domain are re-encrypted using an algorithm, key,
and certificate which can be decrypted by the recipient(s).
3. Mapping of Domain Security Services to the S/MIME Protocol 3. Mapping of Domain Security Services to the S/MIME Protocol
This section describes the S/MIME Protocol elements that are used to This section describes the S/MIME Protocol elements that are used to
provide the security services described above. ESS [4] introduces the provide the security services described above. ESS [4] introduces the
concept of triple-wrapped messages that are first signed, then concept of triple-wrapped messages that are first signed, then
encrypted, then signed again. This document also uses this concept of encrypted, then signed again. This document also uses this concept of
triple-wrapping. In addition, this document also uses the concept of triple-wrapping. In addition, this document also uses the concept of
'signature encapsulation'. 'Signature encapsulation' denotes a complete 'signature encapsulation'. 'Signature encapsulation' denotes a complete
signed message that is wrapped in a second signature, the second signed message that is wrapped in a second signature, the second
skipping to change at line 225 skipping to change at line 217
An authenticated attribute is used to indicate the type of signature. An authenticated attribute is used to indicate the type of signature.
The ASN.1 [5] notation of this attribute is:- The ASN.1 [5] notation of this attribute is:-
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2)
us (840) rsadsi (113549) <TBD> } us (840) rsadsi (113549) <TBD> }
If present, the SignatureType attribute MUST be an authenticated If present, the SignatureType attribute MUST be an authenticated
attribute, as defined in CMS [3]; it MUST NOT be an unauthenticated attribute, as defined in [3]. If the SignatureType attribute is absent
attribute. If the SignatureType attribute is absent the recipient the recipient SHOULD NOT make any assumptions about the type of
SHOULD NOT make any assumptions about the type of signature. signature.
A SignerInfo MUST NOT include multiple instances of SignatureType. An
authenticated attribute representing a SignatureType MUST only include
a single instance of SignatureType as an AttributeValue of attrValues
[3].
This document specifies the following types of signature: This section specifies the following types of signature:
1) Originator Signature 1) Originator Signature
2) Domain Signature 2) Domain Signature
3) Additional Attributes Signature 3) Additional Attributes Signature
4) Review and Release Signature 4) Review and Release Signature
Each of these signature types is generated and processed exactly as Each of these signature types is generated and processed exactly as
described in CMS [3]. They are distinguished by the presence of the described in [3]. They are distinguished by the presence of the
following values in the SignatureType authenticated attribute: following values in the SignatureType authenticated attribute:
id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1} id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1}
id-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-signatureType 2 } id-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-signatureType 2 }
id-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-signatureType 3} id-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-signatureType 3}
id-sigtype-review-release-sig OBJECT IDENTIFIER ::= { id-signatureType id-sigtype-review-release-sig OBJECT IDENTIFIER ::= { id-signatureType
4} 4}
Any of these signature types may encapsulate another signature of the These signature types may encapsulate other signatures, or any other
same or a different type, or any other type of content, as documented in type of content, or may be added in parallel to other signatures as
CMS [3]. The following sections describe the conditions under which documented in [3].
each of these types of signature may be generated, and how they are
processed. A SignerInfo MUST NOT include multiple instances of SignatureType. An
authenticated attribute representing a SignatureType MAY include
multiple instances of different SignatureType values as an
AttributeValue of attrValues [3], as long as the SignatureType
'additional attributes' is not present.
The following sections describe the conditions under which each of
these types of signature may be generated, and how they are processed.
3.1.1 Originator Signature 3.1.1 Originator Signature
The 'originator signature' is used to indicate that the signer is the The 'originator signature' is used to indicate that the signer is the
originator of the message and its contents. The 'originator signature' originator of the message and its contents. The 'originator signature'
is indicated by the presence of the value id-sigtype-originator-sig in is indicated by the presence of the value id-sigtype-originator-sig in
the 'signature type' authenticated attribute. No other Object the 'signature type' authenticated attribute. There MUST be only one
Identifiers may be included in the sequence of OIDs if this value is 'originator signature' signature present in a S/MIME encoding.
present.
3.1.2 Domain Signature 3.1.2 Domain Signature
A 'domain signature' is generated on behalf of a collection of users in A 'domain signature' is a proxy signature generated on a user's behalf in
a domain. A 'domain signature' on a message authenticates the fact that a domain. A 'domain signature' on a message authenticates the fact that
the message has originated in that domain. Before signing, a process the message has originated in that domain. Before signing, a process
generating a 'domain signature' MUST first satisfy itself of the generating a 'domain signature' MUST first satisfy itself of the
authenticity of the message originator. This is achieved by one of two authenticity of the message originator. This is achieved by one of two
methods. Either the 'originator's signature' is checked, if S/MIME methods. Either the 'originator's signature' is checked, if S/MIME
signatures are used inside a domain. Or if not, some mechanism external signatures are used inside a domain. Or if not, some mechanism external
to S/MIME is used, such as the physical address of the originating to S/MIME is used, such as the physical address of the originating
client or an authenticated IP link. client or an authenticated IP link.
If the originator's authenticity is successfully verified by one of the If the originator's authenticity is successfully verified by one of the
above methods, a 'domain signature' may be added to a message in one of above methods and all other signatures present are valid, a 'domain
the following ways: signature' may be added to a message in one of the following ways:
1) An unsigned message is wrapped in a SignedData, and a SignerInfo is 1) An unsigned message is wrapped in a SignedData, and a SignerInfo is
attached containing the 'domain signature'. The originator's attached containing the 'domain signature'. The originator's
information is included as part of a header field in the encapsulated information is included as part of a header field in the encapsulated
message. message.
2) Signature Encapsulation is used to wrap the original signed message 2) Signature Encapsulation is used to wrap the original signed message
with a 'domain signature'. As stated above, the originator's with a 'domain signature'.
signature MUST first be checked by the domain signer.
3) The original signed message has a 'domain signature' added in
parallel.
When a 'domain signature' is applied the mlExpansionHistory and When a 'domain signature' is applied the mlExpansionHistory and
eSSSecurityLabel attributes MUST be copied from other signerInfos as eSSSecurityLabel attributes MUST be copied from other signerInfos as
stated in [4]. stated in [4].
If the originator's authenticity is not successfully verified, a 'domain If the originator's authenticity is not successfully verified, a 'domain
signature' MUST NOT be generated. signature' MUST NOT be generated.
On reception, the 'domain signature' may be used to verify the On reception, the 'domain signature' may be used to verify the
authenticity of a message. If it encapsulates a SignedData, the authenticity of a message. If there is a SignerInfo with the signature
certificate(s) of the inner SignerInfo should be used to identify the type 'originator', its certificate should be used to identify the
originator. This information can then be displayed to the recipient. A originator. This information can then be displayed to the recipient.
domain signer can be assumed to have verified any signatures that it Alternatively, if a 'domain signature' has encapsulated a complete
MIME-encoded message, the originator information (SMTP 'From' field)
contained within it denotes the originator of the message. If neither
of these cases is true no assumptions can be made about the originator.
A domain signer can be assumed to have verified any signatures that it
encapsulates. Therefore, it is not necessary to verify these signatures encapsulates. Therefore, it is not necessary to verify these signatures
before treating the message as authentic. However, this standard does before treating the message as authentic. However, this standard does
not preclude a recipient from attempting to verify any other signatures not preclude a recipient from attempting to verify any other signatures
that are present. that are present.
The 'domain signature' is indicated by the presence of the value Id-at- The 'domain signature' is indicated by the presence of the value Id-at-
sigtype-domain-sig in the 'signature type' authenticated attribute. No sigtype-domain-sig in the 'signature type' authenticated attribute.
other Object Identifiers may be included in the sequence of OIDs if this There MAY be multiple 'domain signature' signatures in a S/MIME encoding.
value is present.
3.1.3 Additional Attributes Signature 3.1.3 Additional Attributes Signature
The 'additional attributes' signature type indicates that the SignerInfo The 'additional attributes' signature type indicates that the SignerInfo
contains additional attributes that are associated with the message. contains additional attributes that are associated with the message.
All attributes in the applicable SignerInfo MUST be treated as All attributes in the applicable SignerInfo MUST be treated as
additional attributes. Successful verification of an 'additional additional attributes. Successful verification of an 'additional
attributes' signature means only that the attributes are authentically attributes' signature means only that the attributes are authentically
bound to the message. A recipient MUST NOT assume that its successful bound to the message. A recipient MUST NOT assume that its successful
verification also authenticates the message originator. The authenticity verification also authenticates the message originator. The authenticity
of the message originator should be verified by checking an encapsulated of the message originator should be verified by checking the signature of
signature of the appropriate type. the appropriate type, if present.
A signer may include any of the attributes listed in CMS [3] or ESS [4] A signer may include any of the attributes listed in [3] or this document
when generating an 'additional attributes' signature. The following when generating an 'additional attributes' signature. The following
attributes have a special meaning, when present in an 'additional attributes have a special meaning, when present in an 'additional
attributes' signature: attributes' signature:
1) Equivalent Label: label values in this attribute are to be treated as 1) Equivalent Label: label values in this attribute are to be treated as
equivalent to the security label contained in an encapsulated equivalent to the security label contained in an encapsulated
SignerInfo, if present. SignerInfo, if present.
2) Security Label: the label value indicates the aggregate sensitivity 2) Security Label: the label value indicates the aggregate sensitivity
of the inner message content plus any encapsulated signedData and of the inner message content plus any encapsulated signedData and
envelopedData containers. The label on the original data is indicated envelopedData containers. The label on the original data is indicated
by the value in the originator's signature, if present. by the value in the originator's signature, if present.
An 'additional attributes' signature is indicated by the presence of the An 'additional attributes' signature is indicated by the presence of the
value Id-at-sigtype-add-attrib-sig in the 'signature type' authenticated value Id-at-sigtype-add-attrib-sig in the 'signature type' authenticated
attribute. No other Object Identifiers may be included in the sequence attribute. No other Object Identifiers may be included in the sequence
of OIDs if this value is present. An 'additional attributes' signature of OIDs if this value is present. An 'additional attributes' signature
may be added in parallel with other signatures in a SET OF SignerInfos. may be added in parallel with other signatures in a SET OF SignerInfos.
There MAY be multiple 'additional attributes' signatures in a S/MIME
encoding.
3.1.4 Review and Release 3.1.4 Review and Release
The 'Review And Release' signature indicates that the signer has The 'review and release' signature indicates that the signer has
reviewed the message. Successful verification of a 'Review and Release' reviewed the message. Successful verification of a 'review and release'
signature means only that the signer has approved the message for signature means only that the signer has approved the message for
release from a domain. A device on a domain boundary such as a Mail release from a domain. A device on a domain boundary such as a Mail
Guard or firewall may be configured to check review and release Guard or firewall may be configured to check review and release
signatures. A recipient MUST NOT assume that its successful verification signatures. A recipient MUST NOT assume that its successful verification
also authenticates the message originator. The authenticity of the also authenticates the message originator. The authenticity of the
message originator should be verified by checking an encapsulated message originator should be verified by checking the signature
signature of the appropriate type. identified as the originators, if present.
A 'Review and Release' signature is indicated by the presence of the A 'review and release' signature is indicated by the presence of the
value Id-at-sigtype-review-release-sig in the 'signature type' value Id-at-sigtype-review-release-sig in the 'signature type'
authenticated attribute. No other Object Identifiers may be included in authenticated attribute. There MAY be multiple 'review and release'
the sequence of OIDs if this value is present. signatures in a S/MIME encoding.
3.2 Domain Encryption and Decryption 3.2 Domain Encryption and Decryption
Domain encryption is encryption performed by a third party on behalf of Domain encryption is encryption performed by a third party on behalf of
a set of originators in a domain. Domain decryption is decryption a set of originators in a domain. Domain decryption is decryption
performed by a third party on behalf of a set of recipients in a domain. performed by a third party on behalf of a set of recipients in a domain.
These processes may be performed in combination, as shown below. These processes may be performed in combination, as shown below.
-------------------------------------------------------------------- --------------------------------------------------------------------
| | Recipient Decryption | Domain Decryption | | | Recipient Decryption | Domain Decryption |
skipping to change at line 454 skipping to change at line 455
domain names are outside the scope of this standard. domain names are outside the scope of this standard.
2) All the members of the receiving domain are issued with certificates 2) All the members of the receiving domain are issued with certificates
containing a single key. The private component of that key is held containing a single key. The private component of that key is held
by an entity in the domain that performs the decryption process by an entity in the domain that performs the decryption process
on their behalf. By selecting the appropriate certificate, a sending on their behalf. By selecting the appropriate certificate, a sending
process will implicitly encrypt for decryption by the Domain process will implicitly encrypt for decryption by the Domain
Decryption process. Decryption process.
An implementation that conforms to this standard MUST support mechanism An implementation that conforms to this standard MUST support mechanism
(1). It may also support mechanism (2). This includes both a client and a (1). It may also support mechanism (2). This includes both a client and
third party implementation. a third party implementation.
4. Security Considerations 4. Security Considerations
Domain Security Services provide a method for digitally Domain Security Services provide a method for digitally
signing data, digesting data, encrypting data, and authenticating signing data, digesting data, encrypting data, and authenticating
data. data.
Implementations must protect the signer's private key. Compromise of Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade. the signer's private key permits masquerade.
skipping to change at line 516 skipping to change at line 517
William Ottaway William Ottaway
DERA Malvern DERA Malvern
St. Andrews Road St. Andrews Road
Malvern Malvern
Worcs Worcs
WR14 3PS WR14 3PS
Phone: +44 (0)1684 894079 Phone: +44 (0)1684 894079
Fax: +44 (0)1684 896113 Fax: +44 (0)1684 896113
Email: w.ottaway@eris.dera.gov.uk Email: w.ottaway@eris.dera.gov.uk
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/