ietf-smime
[Top] [All Lists]

Re: CMS Critical flag for signed attributes?

1998-01-05 10:49:29
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 67

From: Phillip Hallam-Baker <pbaker@verisign.com>

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.

If we accept that the AI problem of general message parsing has not
been solved (and I believe we all do), then you are correct: we must
use some other method of representing such disclaimers in a structured,
machine-parsable format.

One possible "other method" is for S/MIME (CMS) to define it's own
structure for sender-signed attributes.

Another "other method" is to reuse a signed attribute structure which has
already been designed, debated, and standardized within X.509.

I agree with Jim that we should be pursuing the second approach, rather
than the first.  Using the existing X.509 signed attribute structure
has the following significant advantages over the modify-CMS proposal:

 a) it is not S/MIME-specific, and
 b) it is not limited to sender-generated disclaimers of the form:
     "I authorize myself to obligate the company for up to $1000".

Using a CMS signed attribute in conjunction with a corporate database
of project budgets is one possible scenario, but why choose a mechanism
limits you to just that one usage model.  Using X.509 signed attributes
does not preclude the use of online authorization databases, but it
also allows the same mechanism to be used for public-key-based
(offline) authorization.

The design rule should be: don't create a protocol-specific and
usage-model-specific mechanism when a non-protocol-specific, general
purpose, standardized mechanism already exists.



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

The reason I deliberately used the phrase "X.509 signed attribute"
instead of "attribute certificate" is to get around this notion that
"certificates" are somehow a scarce commodity.  They aren't.  For the
sender-generated $1000 disclaimer example, they can be generated on the
fly just as CMS-signed-attributes would be.

Regards,
Dave K.
----------
X-Sun-Data-Type: x-pkcs7-signature
X-Sun-Data-Name: S/MIME Cryptographic Signature
X-Sun-Encoding-Info: base64
Content-Disposition: attachment; filename="smime.p7s"
X-Sun-Content-Lines: 33

MIIG1wYJKoZIhvcNAQcCoIIGyDCCBsQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BTIwggL2MIICX6ADAgECAhB2vHDuklT7Ed9kpHNC7Et4MA0GCSqGSIb3DQEBBAUAMDcxHDAa
BgNVBAoTE1ZTRSBUZWNobmljYWwgR3JvdXAxFzAVBgNVBAsTDkltcGxlbWVudGF0aW9uMB4X
DTk3MTIwNTAwMDAwMFoXDTk4MTIwNTIzNTk1OVowggEFMRswGQYDVQQKFBJWU0UgVGVjbmlj
YWwgR3JvdXAxFzAVBgNVBAsUDkltcGxlbWVudGF0aW9uMUYwRAYDVQQLEz13d3cudmVyaXNp
Z24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MSEw
HwYDVQQLExhGYXZvcml0ZSBDb2xvciAtIEdvcmlsbGExHTAbBgNVBAwTFFByaW5jaXBhbCBD
b25zdWx0YW50MR8wHQYDVQQDExZQaGlsbGlwIE0gSGFsbGFtLUJha2VyMSIwIAYJKoZIhvcN
AQkBFhNwYmFrZXJAdmVyaXNpZ24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDW
JdaaSnvw/9XSWEi/6wEk1Wj8CpU2b/LT3rON7/IY3j/b0LWZFqi5CBJPpTRlRntnRSbYLfH1
vpNWlNnmQCuuVOebcbyv/jSubvrRSqabQ6g7CfdbX2Eynq9HFiSI6nU557QAxIimY9hxrASR
rp4CTcLUdFMwPQuR84QZIfll9wIDAQABozMwMTAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQE
AwIHgDARBgpghkgBhvhFAQYJBAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAiwr8urQcMO17NwSI
AxRw7kDBrFaTN5GJhvs8qewfnEBulb1jz2jY/5Lx+wXBtk86Anb/B0xFRMZce6ui9nAWTjci
w+thLq84V9orR0T8GAmmowKuiWHEtpsNrOO99Tctqx+5+rJ0EcawbFaJSN6Zn1m1nnSY+CA2
woFcu0tg3rIwggI0MIIBnaADAgECAhBErLRupz1gSQGeBEi23oaQMA0GCSqGSIb3DQEBBAUA
MDcxHDAaBgNVBAoTE1ZTRSBUZWNobmljYWwgR3JvdXAxFzAVBgNVBAsTDkltcGxlbWVudGF0
aW9uMB4XDTk3MTIwMzAwMDAwMFoXDTA3MTIwMzIzNTk1OVowNzEcMBoGA1UEChMTVlNFIFRl
Y2huaWNhbCBHcm91cDEXMBUGA1UECxMOSW1wbGVtZW50YXRpb24wgZ0wDQYJKoZIhvcNAQEB
BQADgYsAMIGHAoGBALFl1UihFO54AwKnVEcAY08lyslXWb4gJ1qo8ti0JOaZsyPe3o3k/Yw/
2FcB35xUP2xb2zULyRNVA9G/BOlG/1IfdvqtQZOCu23zRBhMivgre5hJusUOE9ReqHnzRZLI
WZqWAYBzOUuEm5zjUPrFEKhtSYMS5MfualeBpS9VbrTBAgEDo0MwQTAhBgNVHREEGjAYpBYw
FDESMBAGA1UEAxMJT25TaXRlMS04MA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0G
CSqGSIb3DQEBBAUAA4GBACjs7kndFNNKRib3FOsmYQfOOfPk7bbxkV6TUkikcVsemRD86U9y
LGiaOuxrkI7nevlLta1Q/o8R9v8IuihqK/jgYRpQIPmPQgkyLBFiHNIux9fOk6Vho5aXTvhI
XN/8gCRIgUS3XO0G0TdUIRVhDm4+ykfONxegKbniY6JqlPkhMYIBbTCCAWkCAQEwSzA3MRww
GgYDVQQKExNWU0UgVGVjaG5pY2FsIEdyb3VwMRcwFQYDVQQLEw5JbXBsZW1lbnRhdGlvbgIQ
drxw7pJU+xHfZKRzQuxLeDAJBgUrDgMCGgUAoHowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAbBgkqhkiG9w0BCQ8xDjAMMAoGCCqGSIb3DQMHMBwGCSqGSIb3DQEJBTEPFw05ODAxMDUx
NjQ3MDhaMCMGCSqGSIb3DQEJBDEWBBTwyudehrd7fQt6YrFtu8C4PLJULTANBgkqhkiG9w0B
AQEFAASBgCoP7vNYdFNWABE/UzBLRhC0KBcYm47vnLIeOyGmoemtEM4RlOy9bna9FL9KTBAs
3vABkZFh2kXLmUP5MAvjsHo8IEaRvxzI5VFu5p0SgUfAwMqT6vwCR+34LD+H9diuPDHlSjdY
IdR6dDLA/nxCq31qnjfNxWXTH8jarKkr/MII