Ed Gerck | 1 Jan 01:22 1998
Picon

Re: Weakening the rigid heirarchical trust model

On 31 Dec 1997, EKR wrote:

-> [snip, already requoted]
-> That doesn't mean that S/MIME can't be used for high security
-> purposes. It merely means that it can be used in situations where
-> those requirements aren't met as well. On the other hand, if you
-> want to meet requirements like that, you can do so using S/MIME.

While it is true that the laissez-faire philosophy can be very disastrous
when applied to security protocols and indeed S/MIME is managing to steer
away from open statements, we must also not interpolate lines when we read
the protocol specs -- especially when I understand by the above that you
intend to say to non-cryptographers (ie, the public at large) that the
protocol can be used for high security purposes (such as for banking or
company-critical messages). I prefer Paul's assesment, when he wrote about
S/MIME: "This is a mail spec, not a banking spec.", in this thread.

By allowing low-security procedures to be 100% S/MIME compliant, you must
agree that an application that is 100% S/MIME compliant does not say more
than guaranteeing that low-security level -- which defines its security
level for the public. A member of a class must be defined by the class's
properties, no?

On the other hand, if you still want to imagine a situation where two
applications are equally 100% S/MIME compliant while one offers a higher
security level, then you must also agree that these two applications are
incompatible in that high-security level -- though both are S/MIME
compliant, which would be a contradiction by itself *if* S/MIME would be a
high-security protocol. After all, the primary purpose of a standard is to
guarantee interoperability -- which would be utterly destroyed in your
(Continue reading)

EKR | 1 Jan 04:19 1998

Re: Weakening the rigid heirarchical trust model

Ed Gerck <egerck <at> laser.cps.softex.br> writes:
> The bottom line is that S/MIME aims at a security level which is not
> critical, while it can be perfectly operational for the bulk use of the
> Internet today. A honest and correct appraisal of this fact must be more
> useful than snake-oil, here too. 
I absolutely agree. I was simply observing that it's quite possible
to create a profile of S/MIME that is usable in a high security
environment.

> -> 
> -> > ->S/MIME the protocol is perfectly usable in 
> -> > -> high security situations. As always, the implementation has to
> -> > -> be secure. (Incidentally, all the security holes you mention with
> -> > -> the exception of self-signed certs are easily solved by using a 
> -> > -> secure hardware token for one's own private keying material.)
> -> > 
> -> > I must again disagree. It is a common misconception that a third-party
> -> > manufactured hardware token would magically infuse trust into the final
> -> > result of a cryptographic calculation. As we know, trapdoors can be easily
> -> > inserted into the calculation of keys or signatures, arguably more
> -> > stealthly in a hardware token with concealed and secret source code.
> ->
> -> This misses the point entirely. I'm not suggesting that a hardware
> -> is a magic bullet. I'm merely observing that suitably designed
> -> hardware tokens (of which several are available) can solve the
> -> implementation problems you were complaining about. In fact, 
> -> hardware is quite a common requirement in certain environments
> -> for precisely that reason.
> ->
> 
(Continue reading)

Ed Gerck | 1 Jan 23:45 1998
Picon

Re: Weakening the rigid heirarchical trust model

On 31 Dec 1997, EKR wrote:

-> Ed Gerck <egerck <at> laser.cps.softex.br> writes:
-> > The bottom line is that S/MIME aims at a security level which is not
-> > critical, while it can be perfectly operational for the bulk use of the
-> > Internet today. A honest and correct appraisal of this fact must be more
-> > useful than snake-oil, here too. 
-> I absolutely agree. I was simply observing that it's quite possible
-> to create a profile of S/MIME that is usable in a high security
-> environment.
-> 

First of all, a Happy New Year!

Ok, agreed. But that environment (and protocol) would not be S/MIME any
longer -- otherwise, the non-interoperability specter would appear again.

-> >[snip, already requoted] 
-> > My point was that a protocol weakness cannot be solved by hardware, no
-> > matter how controlled.
-> Yes, but a lot of the things you were complaining about (e.g.
-> bad randomness for key generation,  programs which are willing
-> to give up the key, etc.) are (1) not protocol bugs but
-> implementation bugs and (2) can be fixed by trusted hardware.
-> 

We seem to be moving in circles here because this is NOT what I had in
mind. The difference in understanding may have been caused by myself, when
I poorly explained my objection (out of a desire to be concise). My
objection was NOT to point out that S/MIME has protocol bugs, but I seeked
(Continue reading)

EKR | 2 Jan 00:31 1998

Re: Weakening the rigid heirarchical trust model

Ed Gerck <egerck <at> laser.cps.softex.br> writes:
> On 31 Dec 1997, EKR wrote:
> 
> -> Ed Gerck <egerck <at> laser.cps.softex.br> writes:
> -> > The bottom line is that S/MIME aims at a security level which is not
> -> > critical, while it can be perfectly operational for the bulk use of the
> -> > Internet today. A honest and correct appraisal of this fact must be more
> -> > useful than snake-oil, here too. 
> -> I absolutely agree. I was simply observing that it's quite possible
> -> to create a profile of S/MIME that is usable in a high security
> -> environment.
> -> 
> 
> First of all, a Happy New Year!
Indeed.

> Ok, agreed. But that environment (and protocol) would not be S/MIME any
> longer -- otherwise, the non-interoperability specter would appear again.
I agree with the second part of this statement but not the first.
If you desire to have a secure environment, you can't place trust
in entities which don't take similar security measures. So, true,
high security S/MIME users won't interoperate with low security
S/MIME users -- in the sense that the high security users (by policy)
don't trust the low security users. That doesn't mean that they're
not both speaking S/MIME any more than the fact that the NSA won't
tell me classified information means we don't both speak English.

I'd observe that S/MIME already has the capability to produce 
noninteroperability because of different security requirements,
simply because different users may choose to have different
(Continue reading)

Internet-Drafts | 2 Jan 15:28 1998
Picon

I-D ACTION:draft-ietf-smime-cms-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-02.txt
	Pages		: 29
	Date		: 31-Dec-97
	
   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, or encrypt arbitrary
   messages.

   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5.
   Wherever possible, backward compatibility is preserved; however,
   changes were necessary to accommodate attribute certificate transfer
   and key agreement techniques for key management.

   This draft is being discussed on the ''ietf-smime'' mailing list. To
   subscribe, send a message to:
        ietf-smime-request <at> imc.org
   with the single ''subscribe'' word in the body of the message. Also,
   there is a Web site for the mailing list at:
        <http://www.imc.org/ietf-smime/>.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cms-02.txt".
A URL for the Internet-Draft is:
(Continue reading)

Ed Gerck | 2 Jan 16:16 1998
Picon

Re: Weakening the rigid heirarchical trust model

On 1 Jan 1998, EKR wrote:

-> [snip, requoted]
-> If you desire to have a secure environment, you can't place trust
-> in entities which don't take similar security measures. So, true,
-> high security S/MIME users won't interoperate with low security
-> S/MIME users -- in the sense that the high security users (by policy)
-> don't trust the low security users. That doesn't mean that they're
-> not both speaking S/MIME any more than the fact that the NSA won't
-> tell me classified information means we don't both speak English.
-> 

If the high-security users decide not to depend on unsafe X.509 CRLs in
order to decide if a cert is valid (eg, supose they would use a type of
Kerberos tickets) or if the high-security users decide to use PGP and
X.509 then they would already be non-S/MIME for all practical purposes,
even though they could be both talking MIME.

Thus, what I was calling interoperability is not a MIME-interoperability,
but a S/MIME interoperability. In other words, high-security users will in
general differ from low-security users in more predicates than just
different policies or different root-keys for each user, but in the
protocols for each user. What you mentioned is not that, but a case in
which the protocol is still S/MIME for both users (thus, compatible)  but
the reference frames are incompatible with each other. This case I would
consider not a case of lack of interoperation but simply to be out of
tune. Please note that what I had in mind was a true protocol difference
which cannot be solved by any possible change (or tuning) of parameters.

-> I'd observe that S/MIME already has the capability to produce 
(Continue reading)

Phillip Hallam-Baker | 2 Jan 18:33 1998
Picon

Re: CMS Critical flag for signed attributes?

Paul Hoffman / IMC wrote:
> 
> At 03:25 PM 12/31/97 -0500, Phillip Hallam-Baker wrote:
> >It seems to me we may just need a critical flag just like there is in
> >the X.509v3 certificate. If the critical bit is set and the client does
> >not understand the semantics of the attribute a client is required to
> >inform the user of the fact.
> 
> This sounds alright to me, but not the differences in action between PKIX
> and S/MIME. In PKIX, you MUST not process a cert that has a critical
> attribute you don't understand. In S/MIME, you propose that we "inform the
> user", which is the handwaving we're forced to do when a signature check
> fails.
> 
> If we go with this idea, the handwaving wording for what happens for failed
> criticality should be identical as the handwaving wording we use for failed
> signature validation. In fact, I'd like to see that wording appear only
> once as the same outcome to two different bad events.

I agree, but I want to make sure that the resulting wording makes a
critical attribute something that can be raised in court as something
a recipient should have made themselves aware of before relying on the
document as an agreement.

The concern I have in the back of my mind is Mr Mop, the janitor who 
sends  a signed message the recipient then claims in court is a binding
contract on behalf of his employer. MIT students are now required
to get an X.509 cert during registration. I'm pretty sure that MIT
does not intend them to be signing contracts binding on the 
corporation:-)
(Continue reading)

Paul Hoffman / IMC | 2 Jan 18:46 1998
Picon

Re: CMS Critical flag for signed attributes?

At 12:33 PM 1/2/98 -0500, Phillip Hallam-Baker wrote:
>I agree, but I want to make sure that the resulting wording makes a
>critical attribute something that can be raised in court as something
>a recipient should have made themselves aware of before relying on the
>document as an agreement.

Boy, I'd like to see some suggested wording for this. This doesn't sound
like typical wording for IETF specifications, does it? :-)

--Paul Hoffman, Director
--Internet Mail Consortium

Jim Schaad (Exchange | 2 Jan 22:45 1998
Picon

RE: CMS Critical flag for signed attributes?

I would strongly disagree that the place to put this is in the CMS or
S/MIME specifications.  This is the type of statement which belongs in
the Certificate Policy statment for the certificate itself and not on
individual signatures.  I don't see a case where you would have some
signatures from a person being binding and some not binding.  (What
happens if the signer forgets to set the bit, does it then become
binding on the corperation?) 

This is a Certificate Extension issue (and can be critical there) and
not a signature issue.

-----Original Message-----
From: Paul Hoffman / IMC [mailto:phoffman <at> imc.org]
Sent: Friday, January 02, 1998 9:47 AM
To: ietf-smime
Subject: Re: CMS Critical flag for signed attributes?

At 12:33 PM 1/2/98 -0500, Phillip Hallam-Baker wrote:
>I agree, but I want to make sure that the resulting wording makes a
>critical attribute something that can be raised in court as something
>a recipient should have made themselves aware of before relying on the
>document as an agreement.

Boy, I'd like to see some suggested wording for this. This doesn't sound
like typical wording for IETF specifications, does it? :-)

--Paul Hoffman, Director
--Internet Mail Consortium

(Continue reading)

Jim Schaad (Exchange | 5 Jan 04:03 1998
Picon

RE: Incorporate some PKCS#7 V2.0 items into CMS

It turns out that I was not fully functional when I wrote the list of
reasons below, and I left out what was to me the most important one.
What I want to do with the MAC modified signedData object is to run CMR
messages via it.  This requires the ability to have authenticated
attributes travel with the message.  This is a feature which is not
provided by the use of the AuthendicatedData structure, and thus the
reason that I put it into the signedData object.   Notice that I was
very careful NOT to duplicate the same set of functionality as is
provided by Authenticated data, that is I am signing the Authenticated
attrubutes and not the data with the MAC algorithm.

That being said, I can live with the lack of support for this and
provide the introduction mechanism in a different way.  This proposal
however does add a new level of ability that was not present in the PKCS
#7 1.5 specifications.

jim schaad

-----Original Message-----
From: jsp <at> jgvandyke.com [mailto:jsp <at> jgvandyke.com]
Sent: Wednesday, December 31, 1997 6:22 AM
To: Jim Schaad (Exchange); 'Rich Ankney'; ietf-smime <at> imc.org
Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS

All,

I am not a MAC expert, but I have a few comments anyway.  It seems that
the
security processing requirements for MAC objects are significantly
different
(Continue reading)


Gmane