Skip to content.
|Networking government in New Zealand.

1 High Level Requirements

Key to symbols used throughout this document:

br - Business requirement

rfc - RFC requirement (our interpretation)

sec - Government Security requirement (SIGD or GCSB)

1.1 Applicable RFCs

1.1.1 Gateways MUST be compliant with the following RFCs:

· RFC2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile, http://www.imc.org/rfc2459

· RFC2632 S/MIME Version 3 Certificate Handling, http://www.imc.org/rfc2632

· RFC2633 S/MIME Version 3 Message Specification, http://www.imc.org/rfc2633

1.1.2 Compliance with the following RFCs is encouraged and partial compliance is required to meet S.E.E. Business requirements:

· RFC2634 Enhanced Security Services for S/MIME, http://www.imc.org/rfc2634

· RFC3183 Domain Security Services using S/MIME, http://www.imc.org/rfc3183

1.1.3 Where Gateways fail to interoperate, then the S.E.E. Steering Group will make a final decision, using the following order of precedence is:

· S.E.E. Mail business requirements

· RFC compliance

· Product implementations

1.1.4 Wherever possible, Gateways SHOULD utilise the RFC specifications in the same manner as desktop clients.

1.1.5 Note that in certain circumstances, the S.E.E. Mail business requirements will be mandatory (MUST), even though the RFC only specifies an optional compliance (SHOULD).

1.2 Agency Requirements

1.2.1 The Gateway MUST NOT adversely impact on the functionality of existing systems, including virus checking and content filtering software. Specifically the Gateway MUST:

a) Permit transmission of existing non-secure e-mail;

b) Permit secure e-mails containing attachments;

c) Permit secure e-mails being transmitted to multiple user recipients;

d) Permit transmission of individual-to-individual S/MIME messages

1.2.2 Each SEEMAIL Agency must be confident that:

a) All SEEMAIL messages are secured;

b) SEEMAIL messages can only be sent to Participating Agencies;

c) XSEEMAIL messages can only be sent to Participating Agencies, External Agencies and Individuals;

d) All messages between SEEMAIL Agencies authenticate the sending agency;

e) Incoming and outgoing messages must be automatically suspended when the Gateway is not operational.

1.2.3 The Recipient in a SEEMAIL Agency must be confident that:

a) The message is from the sending SEEMAIL Agency as claimed;

b) No one outside the sending SEEMAIL Agency has read the message;

c) No one outside the sending SEEMAIL Agency has altered the message.

1.2.4 The Sender in a SEEMAIL Agency must be confident that:

a) The message can only be read by the receiving SEEMAIL Agency;

b) No one outside the receiving SEEMAIL Agency can read the message in transit;

c) No one outside the receiving SEEMAIL Agency can alter the message.

1.3 Implementation Requirements

1.3.1 The Gateway MUST require minimal implementation effort by existing SEEMAIL Agencies.

1.3.2 The Gateway MUST behave in a consistent and predictable manner.

1.3.3 The Gateway MUST notify relevant parties on exceptions.

1.4 Integration Requirements

1.4.1 The Gateway MUST require no client software customisation.

1.4.2 The Gateway MUST support common e-mail client software.

1.5 Integration Requirements

1.5.1 The Gateway MUST be able to utilise X.509 v3 certificates from any major certificate authority vendor.

1.5.2 The Gateway SHOULD operate on multiple platforms, such as Windows NT and Unix.

1.6 Listserve Requirements

1.6.1 The Gateway MUST permit the exchange of non-secure e-mail among list-serve groups of individuals; some of whom are members of Participating Agencies and some of whom are members of non-Participating Agencies.

1.6.2 The Gateway MUST allow the exchange of secure e-mail among list-serve groups of individuals; who are all members of Participating Agencies.

1.6.3 The Gateway MUST function with non-S.E.E. list-serves.

1.7 Interoperability Requirements

1.7.1 The Gateway MUST interoperate with all other Accredited Software in all Participating Agencies, in a manner that complies with these business requirements.

1.7.2 The Gateway MUST gracefully handle ALL functions indicated in this document as being potentially supported by a communicating gateway, whether mandatory (MUST) or optional (SHOULD), i.e. the Gateway must not cause a communicating Gateway to have to be configured with optional functions switched-off because the first Gateway cannot handle the optional functions without crashing or exhibiting some other undesirable behaviour.

1.8 Scalability Requirements

1.8.1 The Gateway MUST be scalable to interoperate with all Participating Agencies, up to the number of Eligible Agencies.

As per RFC822, Section 4.7.5, User-Defined-Fields:

Individual users of network mail are free to define and use additional header fields. Such fields must have names which are not already used in the current specification or in any definitions of extension-fields, and the overall syntax of these user-defined-fields must conform to this specification's rules for delimiting and folding fields. Due to the extension-field publishing process, the name of a user-defined-field may be pre-empted.

1.8.2 rfc The Gateway SHOULD be able to tag messages with an "X-SEEMAIL-Version" field, identifying the current SEEMAIL version e.g. "X-SEEMAIL-Version: 2.0".

1.9 Security Requirements

1.9.1 A Participating Agency MUST comply with the minimum security standards dictated by the Security In the Government Sector (SIGS) manual and New Zealand Security of Information Technology (NZSIT) publications .

1.9.2 A Participating Agency MUST

· Apply a structured risk management approach

· Conduct risk assessments

· Avoid default installations

· Test and install security patches

· Review audit logs

· Review applications' security coding

· Maintain security documentation

1.9.3 A Participating Agency MUST ensure at all times it is able to pass Site Certification tests.

1.9.4 A Participating Agency MUST be able to add a security classification label to messages.

1.9.5 A Participating Agency MUST be able to recover quickly from key compromise.

1.9.6 A Participating Agency MUST have real time access to the logging and analysis of faults, alerts and intrusions.

1.9.7 A Participating Agency SHOULD be aware when their Gateway fails and how this appears to Senders.


[ Previous | Next ]