[Top] [All Lists]

RE: DOMSEC and S/MIME Gateway Protocol comparison

2001-10-12 09:56:06

Bill & Blake:

I would prefer that a encrypt-only-DOMSEC implementation preserve any signature that is already in place, but not add an empty signature wrapper.

I look forward to the harmonized draft. Blake, when the draft is ready, please post it as draft-ietf-smime-enc-only-domsec-00.txt.


At 03:36 PM 10/12/2001 +0100, William Ottaway wrote:

Hi Blake,

The DOMSEC draft does not require triple-wrapping it only states that it is
supported. A message that only follows the DOMSEC encryption rules, i.e. no
added signature, would be DOMSEC compliant.

The empty signature is only a requirement when you are applying a DOMSEC
signature to a message that does not already have a signature. This rule was
added for backward compatibility. Since you are only encrypting this is not
an issue for you. If you were to support signatures then your system may
enforce that a signature is always present before a DOMSEC signature is
applied or you could have a profile of DOMSEC that ignores the empty
signature rule, assuming backwards compatibility is not an issue.


 William Ottaway BSc Hons CEng MBCS,
 Woodward B009,
 QinetiQ                      Tel: +44 (0) 1684 894079
 Malvern Technology Centre,   Fax: +44 (0) 1684 896660
 St. Andrews Road,            email: 
 WR14 3PS

 All opinions are my own.

> -----Original Message-----
> From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
> [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Blake 
> Sent: 04 October 2001 21:00
> To: 'William Ottaway'; ietf-smime(_at_)imc(_dot_)org
> Subject: RE: DOMSEC and S/MIME Gateway Protocol comparison
> 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
> changes:
> 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
> profile)
> 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.
> Blake
> -----Original Message-----
> From: William Ottaway 
> Sent: Friday, September 21, 2001 6:42 AM
> To: ietf-smime(_at_)imc(_dot_)org
> 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
> to DOMSEC.
> 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
> agents.
> 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
> domain-confidentiality-authority(_at_)domain(_dot_)
> 4) Introduces a mechanism for identifying multiple domains handled by the
> gateway. They can be listed in a single certificate or in multiple
> certificates.
> 5) Introduces a rule for deciding which recipient domain
> certificate must be
> used.
> 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,
> etc.
> 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.
> Bill
> ____________________________________________________
>  William Ottaway BSc Hons CEng MBCS,
>  Woodward B009,
>  QinetiQ                      Tel: +44 (0) 1684 894079
>  Malvern Technology Centre,   Fax: +44 (0) 1684 896660
>  St. Andrews Road,            email: wjottaway(_at_)QinetiQ(_dot_)com
>  Malvern,
>  Worcs,
>  WR14 3PS
>  All opinions are my own.

<Prev in Thread] Current Thread [Next in Thread>