RE: DOMSEC and S/MIME Gateway Protocol comparison

["Housley, Russ" <[e-mail]>]

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.

Russ

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.
>
>Bill.
>
>____________________________________________________
>  William Ottaway BSc Hons CEng MBCS,
>  Woodward B009,
>  QinetiQ                      Tel: [phone]
>  Malvern Technology Centre,   Fax: [phone]
>  St. Andrews Road,            email: [e-mail]
>  Malvern,
>  Worcs,
>  WR14 3PS
>
>  All opinions are my own.
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Blake Ramsdell
> > Sent: 04 October 2001 21:00
> > To: 'William Ottaway'; [e-mail]
> > 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 [mailto:[e-mail]]
> > Sent: Friday, September 21, 2001 6:42 AM
> > To: [e-mail]
> > 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@domain. DOMSEC defines
> > domain-confidentiality-authority@domain.
> >
> > 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: [phone]
> >  Malvern Technology Centre,   Fax: [phone]
> >  St. Andrews Road,            email: [e-mail]
> >  Malvern,
> >  Worcs,
> >  WR14 3PS
> >
> >  All opinions are my own.
> >
> >
> >