2 Implementation Details

2.1 SEEMAIL Business Rules

Core S.E.E. Mail functionality enables secure e-mail to be exchanged between Participating Agencies. This type of email is termed "SEEMAIL".

The Gateways of Eligible Agencies using SEEMAIL are certified, to ensure secure e-mail is handled consistently. The list of site certified Agencies will be made available in an LDAP 3.0 directory, indexed by DN and e-mail address. This will be the 'official' SEEMAIL list.

2.1.1 br The trigger word WILL be [S**MAIL].

2.1.2 br The trigger word [S**MAIL] MUST be recognised in any combination of UPPER or lower case e.g. [S**mAiL].

2.1.3 br Any combination of left-hand, right-hand square "[" or squiggly "{" brackets, including non-matching brackets MUST be recognised e.g. "{S**mail]".

2.1.4 br Mail tagged [S**MAIL] must ONLY be delivered to a Participating Agency, as defined in the SEEMAIL list.

2.1.5 br Gateways MUST handle a [S**MAIL] tagged message consistently.

2.2 XSEEMAIL Business Rules

S.E.E. Mail functionality is extended, so that secure e-mail can be exchanged with External Agencies who are not site certified and with Individuals . This type of e-mail will be termed "XSEEMAIL".

Agencies using XSEEMAIL accept the risk that sensitive e-mail messages could be handled in an insecure manner by the receiving agency e.g. a staff member auto-forwards it to a Hotmail account.

Any Agency using XSEEMAIL makes their own business decision about who to exchange keys with.

XSEEMAIL can be sent between two Gateways as follows:

· a Participating Agency and an External Agency

· two External Agencies

· two Participating Agencies (it will be treated as SEEMAIL)

XSEEMAIL can be sent between a Participating Agency and an Individual.

2.2.1 br The trigger word WILL be [XS**MAIL].

2.2.2 br The trigger word [XS**MAIL] MUST be recognised in any combination of UPPER or lower case e.g. [XS**mAiL].

2.2.3 br Any combination of left-hand, right-hand square "[" or squiggly "{" brackets, including non-matching brackets MUST be recognised e.g. "{xS**mail]".

2.2.4 br Mail tagged [XS**MAIL] must ONLY be delivered to a Participating Agency, as defined in a S.E.E. Manager approved list (SEEMAIL list) OR an External Agency/Individual as defined in an Administrator approved list (XSEEMAIL list).

2.2.5 br A Participating Agency MUST handle a [XS**MAIL] tagged message the same as a [S**MAIL] tagged message.

2.3 Link Setup

2.3.1 br The Gateway MUST allow asynchronous setup and maintenance of SEEMAIL and XSEEMAIL links.

2.4 Operational Requirements

2.4.1 br A Participating Agency MUST comply with the S.E.E. PKI Certificate Policy v1.91 Operational Requirements, as detailed in Section 4.7 - Key Changeover:

· Certificates must have an expiry date of no longer than THIRTEEN months after the issue date.

· A new key pair must be generated for the replacement certificate if the existing key pair has been in use for FOUR years or more (i.e. key lifetime period must be no more than FIVE years).

2.5 Security Requirements

2.5.1 sec A Participating Agency MUST place their Gateway inside a tightly configured firewall certified to EAL4 or better, or E3 or better on the UK ITSEC scale, and configured to allow only the protocols and commands required for the operation of the required service(s).

2.5.2 sec A Participating Agency MUST protect Gateway private keys at all times, from any unauthorised access, disclosure or tampering.

2.5.3 sec A Participating Agency MUST ensure all media used for the storage of Gateway private keys is sanitised by overwriting or degaussing as described in NZSIT207: Declassification of Storage Media, or destroyed before it is released from the Participating Agency's control.

2.5.4 sec Agencies SHOULD request a public key pair created with a hardware key pair or seed generator.

2.5.5 br Gateways MUST check the authenticity of any message before relying on it.

2.5.6 sec Gateways MUST only send messages using an approved algorithm.

2.5.7 sec Gateways MUST support the following approved algorithms: Triple-DES, RSA-1024/2048 and SHA-1.

2.5.8 sec Gateways SHOULD support the following approved algorithm: Advanced Encryption Standard (AES) with 128, 192 and 256-bit key lengths.

2.5.9 sec Gateways MUST always use the highest approved encryption algorithm supported by both Gateways.

2.5.10 sec Gateway crypto modules MUST be FIPS140 evaluated.

2.5.11 sec Gateways SHOULD be Common Criteria evaluated to an Evaluation Assurance Level (EAL) of 3 or higher, by the Australasian Information Security Evaluation Programme (AISEP) or equivalent.

2.6 Self-signed Certificates

As per RFC2632, Section 2.3, (Self-signed certs need other mechanisms to establish trust. This is not scalable)

Agents MAY send CA certificates, that is, certificates that are self-signed and can be considered the "root" of other chains. Note that receiving agents SHOULD NOT simply trust any self-signed certificates as valid CAs, but SHOULD use some other mechanism to determine if this is a CA that should be trusted. Also note that in the case of DSA certificates the parameters may be located in the root certificate. This would require that the recipient possess the root certificate in order to perform a signature verification, and is a valid example of a case where transmitting the root certificate may be required.

2.6.1 rfc Agencies MUST use a Certificate Authority (CA) issued certificate. Agencies MUST NOT use a self-signed certificate for S.E.E. Mail.

2.7 Certificate Naming Conventions

As per RFC3183, Section 3.1.1 -

The following naming conventions are specified for agents generating signatures specified in this document:

- For a domain signature, an agent generating this signature MUST be named 'domain-signing-authority'

- ...

- This name shall appear as the 'common name (CN)' component of the subject field in the X.509 certificate. There MUST be only one CN component present. Additionally, if the certificate contains an RFC 822 address, this name shall appear in the end entity component of the address - on the left-hand side of the '@' symbol.

2.7.1 rfc Gateways MUST comply with RFC3183, Section 3.1.1 Naming Conventions.

As per RFC3183, Section 4.1, Domain Confidentiality Naming Conventions -

A DCA MUST be named 'domain-confidentiality-authority'. This name MUST appear in the 'common name (CN)' component of the subject field in the X.509 certificate. Additionally, if the certificate contains an RFC 822 address, this name MUST appear in the end entity part of the address, i.e., on the left-hand side of the '@' symbol.

Along with this naming convention, an additional naming rule is defined: the 'name mapping rule'. The name mapping rule states that for a DCA, the domain part of its name MUST be the same as, or an ascendant of (as defined in section 3.1.1), the domain name of the set of entities that it represents.

2.7.2 rfc Gateways MUST comply with RFC3183, Section 4.1 Domain Confidentiality Naming Conventions.

2.7.3 rfc Gateways MUST ensure that the domain part of an e-mail MUST be the same as or an ascendant of, either the SubjectAltName.rfc822Name or PKCS#9 emailAddress in the signer's certificate.

2.7.4 Gateways MUST generate a warning, if the addresses do not match or the certificate does not contain any email address.

As per RFC2632, Section 3, Using Distinguished Names for Internet Mail -

End-entity certificates MAY contain an Internet mail address as described in [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of that specification. The email address SHOULD be in the subjectAltName extension, and SHOULD NOT be in the subject distinguished name.

Receiving agents MUST recognize email addresses in the subjectAltName field. Receiving agents MUST recognize email addresses in the Distinguished Name field in the PKCS #9 emailAddress attribute.

As per RFC2632, Section 4.4.3, Subject Alternative Name Extension -

The subject alternative name extension is used in S/MIME as the preferred means to convey the RFC-822 email address(es) that correspond to the entity for this certificate. Any RFC-822 email addresses present MUST be encoded using the rfc822Name CHOICE of the GeneralName type. Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple RFC-822 email addresses MAY be present.

2.7.5 rfc Agencies MUST use either:

a) one DCA certificate (for encryption and signing) OR

b) one or more DCA certificate(s) (for encryption and signing) with multiple RFC822 DCA e-mail addresses for every unique domain in the Subject Alternative Name Extension of the certificate

2.8 CRL Distribution Points

As per RFC2459, Section 4.2.1.14, CRL Distribution Points -

The CRL distribution points extension identifies how CRL information is obtained. The extension SHOULD be non-critical, but this profile recommends support for this extension by CAs and applications.

2.8.1 rfc The certificate MUST contain a CRL distribution point to enable the Gateway to verify whether it has been revoked or not.

2.8.2 br Participating Agencies MUST maintain a S.E.E. Manager list of trusted CA root-keys. Agencies MAY add other CA root-keys if they require.

2.8.3 br Participating Agencies MUST implement S.E.E. Key server certificates, when they become available, on the next renewal of their key.

2.9 Certificate Processing

Principles:

· Fail safe

· Allow for faulty implementations

· Allow for transition issues (e.g. certificate expires while message is in transit)

· Allow for the use of certificates from outside of S.E.E. Mail

As per RFC2632, Section 5 -

Some of the many places where signature and certificate checking might fail include:

- no Internet mail addresses in a certificate match the sender of a message

- no certificate chain leads to a trusted CA

- no ability to check the CRL for a certificate

- an invalid CRL was received

- the CRL being checked is expired

- the certificate is expired

- the certificate has been revoked

- the certificate has not yet been issued (system date is earlier than issue date)

There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails.

2.9.1 rfc Gateways MUST always verify whether the certificate is valid, and must verify whether any of the failures listed in 2.9 have occurred.

2.9.2 rfc Gateways MUST provide a meaningful notification capability for invalid instances, and use the S.E.E. Mail Messages (as defined in S.E.E. Mail Tests).

2.9.3 br Gateways SHOULD handle certificates in a consistent manner, as follows:

Result abbreviations: S = Sender, R = Recipient, RA = Recipient Administrator, SA = Sender Administrator

Refer to Administrator Notification section for other relevant information.

At this stage, digital time stamping is NOT required, i.e. we are not dealing with possibilities such as the malicious back-dating of messages to match an expired key that was obtained somehow.

As per RFC2459, Section 4.2.1.14, CRL Distribution Points -

The CRL distribution points extension identifies how CRL information is obtained. The extension SHOULD be non-critical, but this profile recommends support for this extension by CAs and applications.

2.9.4 rfc Gateways MUST be able to retrieve CRLs automatically from a CRL distribution point extension in the relevant certificate.

As per RFC2633, Section 4, 4. Certificate Processing -

A receiving agent MUST provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. This memo does not cover how S/MIME agents handle certificates; only what they do after a certificate has been validated or rejected. S/MIME certification issues are covered in [CERT3].

At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval.

As per RFC2632, Section 4 -

Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval. In many environments, it may be desirable to link the certificate retrieval/storage mechanisms together in some sort of certificate database. In its simplest form, a certificate database would be local to a particular user and would function in a similar way as a "address book" that stores a user's frequent correspondents. In this way, the certificate retrieval mechanism would be limited to the certificates that a user has stored (presumably from incoming messages). A comprehensive certificate retrieval/storage solution may combine two or more mechanisms to allow the greatest flexibility and utility to the user.

For instance, a secure Internet mail agent may resort to checking a centralised certificate retrieval mechanism for a certificate if it cannot be found in a user's local certificate storage/retrieval database.

2.9.5 rfc Gateways MUST provide a way to store and retrieve certificates it knows about, and hold them for later use.

2.9.6 rfc Gateways SHOULD add or update their certificate stores by detecting previously unknown but currently trusted domain certificates in e-mail received.

2.9.7 rfc Gateways MUST be capable of an automatic process for retrieving and using the appropriate certificate, for the following purposes:

(a) When it wishes to send another Gateway an encrypted message and does not have a current certificate for that Gateway.

(b) When it needs a new valid public key certificate from its CA

2.9.8 rfc An LDAP query to be the primary mechanism, as this is a standard, scaleable approach. The query SHOULD retrieve the certificate by setting a 'search base' to "C=NZ", filtering on the unique gateway e-mail address, domain-confidentiality-authority@agency.govt.nz and requesting the 'usercertificate' attribute to the entry that is found.

2.9.9 rfc A signed e-mail request is a mandatory fallback mechanism if an LDAP directory is unavailable. The request MUST be sent to a special e-mail address i.e. domain-certificate-request@youragency.govt.nz. The subject line MUST be the e-mail address of the target certificate. The certificate MUST be returned as a commonly used binary encoded certificate attachment e.g. *.cer or *.crt OR a PKCS#7 container e.g. *.p7b or *.p7c.

2.9.10 rfc The administrator MUST be able to EITHER fully automate XSEEMAIL key discovery OR require a manual approval step, dependant upon their preference.

2.9.11 rfc The administrator MUST be able to EITHER fully automate SEEMAIL key discovery if the Gateway can verify against the SEEMAIL List, OR require a manual approval step, dependant upon their preference.

As per RFC2632, Section 4.4.3, Subject Alternative Name Extension -

The subject alternative name extension is used in S/MIME as the preferred means to convey the RFC-822 email address(es) that correspond to the entity for this certificate. Any RFC-822 e-mail addresses present MUST be encoded using the rfc822Name CHOICE of the GeneralName type. Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple RFC-822 email addresses MAY be present.

2.9.12 rfc The Gateway MUST be able to load and utilise multiple RFC-822 e-mail addresses defined in a certificate.

As per RFC3183, Section 4.2 - Key Management for DCA Encryption

Gateways SHOULD support LDAP v3.0.

2.9.13 rfc Gateways MUST support LDAP v3.0.

2.9.14 br Gateways MUST be able to queue failed messages and send a warning message, to enable the administrator to manually repair the problem and release the queued messages, dependant upon the administrator's preference. Senders SHOULD be notified when an e-mail can not be delivered in a consistent manner to non S.E.E. delivery failures. e.g. Remote mail server is down, will keep trying for another 67 hours

2.9.15 Gateways SHOULD be able to store LDAP specifications for automatic certificate retrieval (corollary 2.9.7(b)) e.g.

· The Gateway would store an LDAP specification for each trusted CA directory.

· When the Gateway needs to use a certificate that is Expired, Revoked or Suspended it should use these LDAP specifications to attempt to auto-discover a renewed or re-issued certificate.

· This procedure MAY also be used to discover non SEEMAIL domain security gateways, e.g. discovering a certificate for encryption as in 2.10.7

2.10 Sending

2.10.1 br Gateways MUST sign / encrypt all messages to an Agency, with no exceptions e.g. non-delivery response receipts, delivery receipts, etc.

As per RFC2632, Section 1, Overview -

...Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid.

2.10.2 rfc Gateways MUST check that a public key is valid before using it to provide security services.

As per RFC2632, Section 4.2, Certificate Chain Validation -

In creating a user agent for secure messaging, certificate, CRL, and certificate chain validation SHOULD be highly automated while still acting in the best interests of the user. Certificate, CRL, and chain validation MUST be performed as per [KEYM] when validating a correspondent's public key. This is necessary before using a public key to provide security services such as: verifying a signature; encrypting a content-encryption key (ex: RSA); or forming a pairwise symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a content-encryption key.

2.10.3 rfc Gateways MUST use a valid certificate to sign messages.

2.10.4 rfc Gateways MUST use a valid certificate to encrypt messages.

As per RFC2632, Section 2.3, CertificateSet -

Sending agents SHOULD include any certificates for the user's public key(s) and associated issuer certificates. This increases the likelihood that the intended recipient can establish trust in the originator's public key(s). This is especially important when sending a message to recipients that may not have access to the sender's public key through any other means or when sending a signed message to a new recipient. The inclusion of certificates in outgoing messages can be omitted if S/MIME objects are sent within a group of correspondents that has established access to each other's certificates by some other means such as a shared directory or manual certificate distribution.

2.10.5 rfc Gateways MUST send a valid public key certificate with every signed message.

2.10.6 rfc Gateways MUST include the S/MIME capability attribute with every signed message.

2.10.7 rfc Gateways MUST be able to sign and/or encrypt e-mail to a non SEEMAIL entity if its certificate store contains a valid domain certificate for the recipient.

2.11 Receiving

2.11.1 As per RFC2632, Section 2.3, CertificateSet -

2.11.2 Receiving agents MUST be able to handle an arbitrary number of certificates of arbitrary relationship to the message sender and to each other in arbitrary order. In many cases, the certificates included in a signed message may represent a chain of certification from the sender to a particular root. There may be, however, situations where the certificates in a signed message may be unrelated and included for convenience.

2.11.3 rfc Gateways MUST use the public key certificate sent with a signed message to verify the signature on that message.

As per RFC2632, Section 2.3, CertificateSet -

Receiving S/MIME agents SHOULD be able to handle messages without certificates using a database or directory lookup scheme.

2.11.4 rfc Receiving S/MIME gateways SHOULD be able to handle messages without certificates by retrieving the relevant certificates using a database or directory lookup scheme

As per RFC2633, Section 4.2, Incoming -

...certificates and CRLs SHOULD be cached for use in chain validation and optionally stored for later use...

2.11.5 rfc Gateways SHOULD determine if the public key certificate with a signed message, for a domain, is different from that in the key store, and update the local store.

As per RFC2633, Section 2.7.1 -

The list of capabilities SHOULD be stored for future use in creating messages...

2.11.6 rfc Gateways SHOULD cache S/MIME capabilities from received messages for future use.

2.11.7 br Gateways SHOULD automatically determine the highest available encryption algorithm and key length from a received e-mail using the S/MIME capability attribute.

2.11.8 br Gateways MUST handle messages encrypted or signed with expired or revoked key pairs.

2.11.9 br Gateways MUST accept messages (including unsigned messages), encrypted with its DCA-public key, from an unknown source.

2.11.10 br Gateways MUST be able to strip DSA certificates from incoming e-mail where CN=domain-signing-authority.

2.11.11 br Gateways MUST be able to strip DCA certificates from incoming e-mail where CN=domain-confidentiality-authority.

2.12 Trusted Server Functionality

2.12.1 br A Participating Agency MAY establish a "Trusted Listserve" ruleset, and use this as the basis to downgrade Warning 2B (unverified sender) from a HARD warning, to a SOFT warning.

2.12.2 br A Participating Agency MAY establish a "Trusted Server" ruleset, and use this as the basis to downgrade Warning 2B (unverified sender) from a HARD warning, to a SOFT warning. (This ruleset is typically used for agencies with external servers, wishing to receive e-mail status reports).

2.12.3 It is recommended that Participating Agencies reliably identify servers on their "Trusted e.g. by IP address rather than e-mail address alone.

2.13 Administrator Notification

Principles:

· Implement notifications in such a way as to minimize the impact on service / performance e.g. don't send an error e-mail notification for every failed message

· Implement notifications in such a way as to avoid loops e.g. don't send an error message to a sender administrator, if the message will create additional incorrect messages back to you.

2.13.1 br Each Participating Agency MUST have a valid "postmaster@youragency.govt.nz " account, to send exception messages and accept notifications.

2.13.2 br The Gateway MUST ensure exception / notification messages are addressed "from" a valid "postmaster@youragency.govt.nz" account.

2.13.3 br The Gateway MUST ensure a rule for inbound messages, where the message is "from" postmaster, does not send an exception message (to avoid loops).

2.13.4 br The Gateway SHOULD allow the administrator to specify audit log and/or e-mail notifications, and their frequency, as some failures could cause a log/mail notification storm.

2.13.5 br The Gateway MUST ensure rules for inbound messages do not send exception messages to postmaster of the sending agency

2.14 Documentation and Training Rules:

2.14.1 br New Participating Agencies SHOULD provide user education material and publicise S.E.E. Mail when their agency joins.

2.14.2 br Participating Agencies SHOULD instruct new staff on the appropriate use of the SEEMAIL tags within 14 days of activating an e-mail account for them.

2.14.3 br Desired outcomes: Staff SHOULD know that:

- All e-mail between their Agency and a Participating Agency is signed and encrypted, and where to view the list of Participating Agencies;

- A Participating Agency has been site certified, which means the handling of e-mail under different conditions has been tested and verified to work correctly;

- All e-mail between their Agency and an External Agency is signed and encrypted, and where to view the list of External Agencies;

- An External Agency has NOT been site certified, there is NO assurance as to the handling of e-mail once it has been received.

- Any e-mail with a SEEMAIL tag will not be sent, if it cannot be delivered signed and encrypted

2.14.4 br A Participating Agency SHOULD update any applicable documentation and inform staff, when they create a secure relationship with a new Participating Agency or External Agency.

2.15 Diagnostics

2.15.1 br Each Participating Agency, Supplier and Candidate MUST establish a "seemail-ping" automated e-mail responder for diagnostic purposes.

2.15.2 br Seemail-ping MUST operate before any other SEEMAIL business rules and not invoke them.

2.15.3 br The seemail-ping MUST auto-respond with a signed/encrypted reply to a message that is signed (and/or encrypted) using a domain certificate issued by a trusted CA.

2.15.4 br Seemail-ping MUST respond with the SEEMAIL version number, gateway software name/version number and SHOULD respond with the list of SEEMAIL agencies it knows about

2.16 Testing

2.16.1 br Each Participating Agency, Supplier and Candidate MUST establish a "seemail-test" account for testing purposes.

2.16.2 br All incoming messages to "seemail-test" MUST be automatically copied to "seemail-test-log@see.govt.nz", included as part of the body of the message (not an attachment)

2.17 LDAP Server Functionality

2.17.1 br Each Participating Agency, Supplier and Candidate MUST provide and maintain a current certificate or certificate URL to the LDAP server.

2.17.2 br The LDAP server WILL have a list of agencies as *@domain

2.17.3 br The LDAP server WILL have two lists: SEEMAIL and VENDOR

2.17.4 br If a Participating Agency, Supplier and Candidate turns off or otherwise removes domain level e-mail security, they MUST be removed from the SEEMAIL LIST or VENDOR list and their certificate MUST be suspended or revoked by their CA.

[ Previous | Next ]