S/MIME Mail Security (smime)

Jim Schaad (Exchange | 2 Jan 1998 22:45

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)

headers

Phillip Hallam-Baker | 5 Jan 1998 17:47

Re: CMS Critical flag for signed attributes?

Jim Schaad (Exchange) wrote:

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

The problem with this approach is that it means a person must have
a different certificate for each privillege level they have.

I am anticipating disclaimers of the form 'the value of any contract
agreement entered into under this message is less than $1000'. I 
would expect an automated 'contract box' to accept input in the
form of signed S/MIME messages, consult some corporate database of
project budgets and possibly authorize some small value contracts
automatically. Doing this requires either that we solve the AI
problem and parse the contract or we find some other method of
limiting the exposure due to such a device.

Also consider the alternative scheme in which the contracts would
be vetted in some way. There is obviously a need to ensure that 
those vetting the contracts do not exceed their authority (e.g.
they are in collusion with some fraud and making authorizations
beyond their authority).

The other problem is that it does not address the four corners issue.
The reason certificate policies were largely abandoned as a means of

(Continue reading)

headers

Phillip Hallam-Baker | 5 Jan 1998 20:52

Re: CMS Critical flag for signed attributes?

> The other problem is that it does not address the four corners issue.
> The reason certificate policies were largely abandoned as a means of
> specifying the criteria for issuing a certificate was that they
> might not be binding in court. As Michael Baum points out, a court
> might decide that they are not even admissible. Courts are likely
> to decide to restrict their debate to the 'four corners' of the
> document in dispute.

As Warwick Ford just pointed out to me. The 'certificate policies'
I am referring to here are the old style PEM/RFC 1442 scheme of
Policy Certificates. This is not the same as X.509v3 Certificate
Policies which *are* a good idea but unfortunately happen to have
a confusingly similar name 

		Phill

Attachment (smime.p7s): application/x-pkcs7-signature, 1755 bytes