Eric:
In a signed-only conversation the initial message would use "default". But
message could contain compression attribute in cert allowing subsequent messages
to be compressed. I agree that many other attributes associated with signing
make no sense to include for the reasons you suggest, and I think that's what
Jim was referring to in his original post.
However, the main thrust of my suggestion is to provide some guidance as to
which attributes should be in which certs (and Jim's: which attributes make
sense).
Cheers,
tony
-----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 Eric Norman
Sent: February 17, 2005 3:37 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: I-D ACTION:draft-ietf-smime-certcapa-02.txt
On Feb 17, 2005, at 1:35 PM, Tony Capel wrote:
The logic of putting the encryption capabilities in the encryption
public key
certificate (and NOT the signing public key certificate) - !I think! -
is
straightforward. My problem is with the capabilities that relate to
signing,
should they be in the signing public key certificate? And for
capabilities
relevant for both, should they be in both certs or only one - and
which one?
Maybe something like:
I'm having a problem with the notion of capabilities that relate to
signing.
These would be capabilities that I have and someone else needs to know about
before they can send me a signed message, right? How is the distribution
bootstrapped? I send them to him in a signed message? But what if he has the
same problem and needs to inform me about his capabilities before I can sign
that message?
Eric Norman
University of Wisconsin -- DoIT