I believe the scenario you describe is handled in a DOMSEC environment. In
fact this is exactly the type of scenario that drove us to produce the
Section 4 of DOMSEC describes a domain and/or an individual being able to
encrypt for a recipient or the recipient's domain (DCA - Domain
Confidentiality Authority): -
"Messages may be encrypted for decryption by the final recipient and/or by a
DCA in the recipient's domain."
In your scenario the originator would send a message to the intended
recipient as usual but the originator or the originator's domain encrypts
the message so that the recipients domain (DCA) can decrypt it. We think
this is covered by section 4:
* Section 4.1 describes a naming convention that must be followed so that
the certificate for the recipient's domain can be identified.
* Section 4.3 describes how a DCA decrypts a message that has been encrypted
by an originator and/or an originator's domain.
After re-reading this section we have changed it slightly to aid clarity,
and (hopefully!) to make it more clear that we are covering the scenario you
-- Begin new section 4.3
"4.3 Key Management for Domain Decryption
Domain decryption uses a domain-wide decryption key from the recipient's
domain. This key is owned by the DCA for the recipient domain. In order for
an encrypting process to locate the correct key, the certificate
corresponding to the DCA in the recipient's domain must be located. This is
achieved using the naming conventions specified in 4.1. It is vital that
these conventions are adhered to, in order to maintain confidentiality.
It should be noted that domain decryption can be performed on messages
encrypted by the originator and/or by a DCA in the originator's domain.
In the first case, the encryption process is described in CMS ; in the
second case, the encryption process is described in 4.2.
No specific method for locating this certificate is mandated in this
document. An implementation may choose to access a local certificate store
to locate the correct certificate. Alternatively, a directory may be used in
one of the following ways:
1. The directory may store the DCA certificate in the recipient's directory
entry. When the user certificate attribute is requested, this certificate is
2. The encrypting agent maps the recipient's name to the DCA name in the
manner specified in 4.1. The user certificate attribute associated with this
directory entry is then obtained.
This document does not mandate either of these processes. Whichever one is
used, the name mapping conventions must be adhered to, in order to maintain
Having located the correct certificate, the encryption process is then
performed. A recipientInfo for the DCA is then generated, as described in
-- End new section 4.3
We see DOMSEC as a means of describing the building blocks required to
provide secure messaging between individuals and domains using S/MIME. How
these blocks are integrated into real systems is very much a policy matter
and consequently we do not go into this realm within DOMSEC.
To summarise, we believe your scenario is covered by DOMSEC. Do you agree?
Is further clarification needed? If so where?
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Luis
Sent: 11 April 2000 15:16
To: IETF SMIME List
Subject: Domain-to-point security services & DOMSEC
I have a common scenario that I believe should be addressed within this
group. I'll refer to it as domain-to-point secure messaging and it looks
A user A(_at_)ISP(_dot_)com wishes to communicate *securely* with a another
B(_at_)Company(_dot_)com(_dot_) The user B(_at_)Company(_dot_)com doesn't
have a cert (or if he does
A(_at_)ISP(_dot_)com doesn't know it). I see this as a common case, when
start migrating to PKI and:
(1) A(_at_)ISP(_dot_)com is actually a user A(_at_)Company(_dot_)com, who has
his corporate premises and has a public email account at an POP/IMAP
service provider. A wants to exchange email securely with colleagues at
the Company, but not all of them have certs.
(2) A(_at_)ISP(_dot_)com is an external user with no association with
Corporate.Com, but who wants to send important secure email to
B(_at_)Company(_dot_)com(_dot_) A(_at_)ISP(_dot_)com can't access the
To solve this, the Company can deploy a domain securiy service, sort of
S/MIME proxy with public cert associated with
The user A(_at_)ISP(_dot_)com (the point) could then send S/MIME to this
domain) with request to forward the email to the end user
If A also has a cert, then B can reply securely directly or via the
S/MIME proxy, provided that the proxy has access to the A's PKI
(Company.Com or ISP.com).
BTW, this scheme also allows users to store corporate email on
unstrusted public POP/IMAP services providers. It can also be used for
secure mailing lists and cert distribution.
My question to You folks is:
1. Is there enough interest out there to work towards a draft?
2. It seems that this falls within the DOMSEC draft, but the scenario
above is not explicitly addressed. Any opinion on this?
3. Anybody else done something similar?