Bill, thanks very much for doing this summary.
One thing that we were initially concerned about was that there was a
requirement for triple-wrapping and/or an empty signature layer (SignedData
with no SignerInfos). If this requirement is gone, then I believe we can
simply make our document an "encrypting-only" profile for DOMSEC.
I propose that our current document continue to live, but with the following
1. Refer to DOMSEC in the relevant places in our draft
2. Remove the language about the email address in the certificate, and refer
to DOMSEC for this
3. Clarify that the additions that we have specified for handling
subdomains, etc. are in addition to DOMSEC (and thus the meat of this
The only impact for any existing implementations of our specification would
therefore be the recognition of the DOMSEC-specified email address
(domain-confidentiality-authority) as opposed to the smg_encryptor email
address that we originally specified in our draft.
From: William Ottaway
Sent: Friday, September 21, 2001 6:42 AM
Cc: Blake Ramsdell
Subject: DOMSEC and S/MIME Gateway Protocol comparison
At the S/MIME WG meeting in London I was tasked to provide a comparison
between DOMSEC and the S/MIME Gateway Protocol
(draft-ramsdell-enc-smime-gateway-00.txt) in order to start a discussion on
whether the gateway draft should be progressed and if so how would it relate
DOMSEC Summary: -
1) Encryption/Decryption and signing.
2) Defines naming conventions.
3) Defines signature types.
4) Defines membership of a domain.
5) Defines rules for domain signature generation and verification.
6) States how domain encryption/decryption is achieved.
7) Defines domain signature application rules when sending to mail list
Gateway Summary: -
1) Encryption/Decryption only.
2) Uses same notation of domain "membership" as DOMSEC.
3) Introduces its own naming convention for the encrypting entities domain
certificate, smg_encryptor(_at_)domain(_dot_) DOMSEC defines
4) Introduces a mechanism for identifying multiple domains handled by the
gateway. They can be listed in a single certificate or in multiple
5) Introduces a rule for deciding which recipient domain certificate must be
6) Introduces a rule on how the gateway recognises that a message requires
encryption (encrypt if have a certificate for the recipients domain).
7) Introduces a rule on when the gateway should decrypt a message (when the
gateways public key has been used to encrypt)
My view: -
DOMSEC defines mechanisms for domain signing and encrypting with out
specifying mechanisms or rules that are deemed local to the installation. It
is hoped that domain signing and encryption implementations will be
compliant with DOMSEC. It is expected that individual installations will
provide extra local mechanisms and rules in support of DOMSEC, for example
how to decide on which certificate to use, how to decide on whether
encryption is required, how certificates are retrieved, whether a domain
signature is stripped off before forwarding to the local recipient, whether
encryption between the domain boundary and the local recipient is required,
The Gateway draft defines mechanisms that are already defined in DOMSEC,
such as encryption and naming notation. It also defines mechanisms that may
differ between implementations, such as domains that are handled by the
gateway may be listed in a single or multiple certificate and rules on which
recipient certificate to use when encrypting.
I propose that the Gateway draft should be a profile of DOMSEC. Therefore,
it should support encryption/decryption as specified in DOMSEC and the
DOMSEC naming convention. The Gateway draft would contain those features
local to this implementation such as points 4 - 7 in the gateway summary.
William Ottaway BSc Hons CEng MBCS,
QinetiQ Tel: +44 (0) 1684 894079
Malvern Technology Centre, Fax: +44 (0) 1684 896660
St. Andrews Road, email: wjottaway(_at_)QinetiQ(_dot_)com
All opinions are my own.