ietf-smime
[Top] [All Lists]

Re: Domain-to-point security services & DOMSEC

2000-04-17 07:45:57
Bill,

DOMSEC covers partially the requirements I described. Below, I explain
why and at the end I list where DOMSEC should be updated to fully
address all requirements.

DOMSEC addresses the case when an individual encrypts for a recipient's
domain and the DCA decrypts. I call this case point2domain requirement.
What I think is missing is the domain2point requirement. In this case
the domain Company.Com needs to send secure mail to one of its members
A(_at_)Company(_dot_)Com, who is on the Internet reachable as 
A(_at_)ISP(_dot_)Com(_dot_) Note that
ISP.Com is considered an unstrusted domain from the Company's
perspective.

The DOMSEC draft has a very generic phrase "Messages may be encrypted
for decryption by the final recipient and/or by a DCA in the recipient's
domain". This seems to cover both point2domain and domain2point, but it
actually handles in detail only point2domain.

What I would like to see an explicit domain2point requirement, with a
more clear description how this is achieved. What I'm aiming at is that
the email from an intranet user sender(_at_)Company(_dot_)Com would be 
encrypted by
the DCA for a recipient A(_at_)Company(_dot_)Com on behalf of the sender *using 
the
recipient's A(_at_)Company(_dot_)Com cert*. Optionally the DCA would put a 
domain
signature. The resulting SMIME object would then be sent to 
A(_at_)ISP(_dot_)Com(_dot_) A
mismatch between A(_at_)ISP(_dot_)Com and A(_at_)Company(_dot_)Com has to be 
solved.

The following sections should be extended:

o Abstract
 - focuses on domain interoperation. Should consider domain2point.

1. Introduction
 - there are 4 issues named and the 3rd one is about PKI deployment
issues for certification paths between organizations. The domain2point
requirement is not named. The issue here is that the sender on the
Intranet can't PKI/SMIME or there is a security policy restricting it.

2.4 Domain Encryption and Decryption
  - The definition of domain encryption excludes the domain2point case,
because it assumes a domain2domain or point2domain scenario. Domain
encryption should be defined to also include the case of encryption on
behalf of a sender *using the recipient's cert*.

4. Encryption and Decryption
  - still focused on point2domain. Should consider domain2point.

4.2 Key Management for Domain Encryption
  - The key used here is a domain key which is ok for point2domain. This
section should also consider domain2point where the encryption key is
the recipient's key.

4.3. Key Management for Domain Decryption
  - This section has been written to complete 4.2. A small caveat should
probably be needed to say that no domain decryption applies for
domain2point.

--------
Luis Barriga
Ericsson Reseach
         
William Ottaway wrote:

Hi Luis,

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
DOMSEC ID.

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
describe:

-- 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 [5]; 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
returned.

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
confidentiality.

Having located the correct certificate, the encryption process is then
performed. A recipientInfo for the DCA is then generated, as described in
CMS [5]."

-- 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?

Bill.

-----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 Luis 
Barriga
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
as follows:

A user A(_at_)ISP(_dot_)com wishes to communicate *securely* with a another 
user
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 
companies
start migrating to PKI and:

(1) A(_at_)ISP(_dot_)com is actually a user A(_at_)Company(_dot_)com, who 
has temporarily left
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 
Company's PKI.

To solve this, the Company can deploy a domain securiy service, sort of
S/MIME proxy with public cert associated with 
Smime-proxy(_at_)Company(_dot_)com(_dot_)
The user A(_at_)ISP(_dot_)com (the point) could then send S/MIME to this 
proxy (the
domain) with request to forward the email to the end user 
B(_at_)Company(_dot_)com(_dot_)
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?

------
Luis Barriga
Ericsson Research


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