[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SPKI signing keys only
> I believe someone might be able to construct protocols for secure channels
> using authentication/authorization provided by SPKI certs and that the
> (public-key ...) block should be able to describe an encryption key (or D-H
> key). Someone might even want to define a (tag ..) field which declares an
> encryption key. I would imagine that key (or its hash) to be in the (tag),
> not in the (subject), although I suppose that's open for discussion.
> However, if it's in the (subject) then we've opened up a political rathole,
> IMHO.
>
>
> - Carl
I can see the point you are making. This continues our private
discussion, in which I had pointed out that existing protocols have to
change if we are going to separate signature keys from data-encrypting
(key-transfer) keys. All of them that I know seek a certificate on a
name, and proceed to use the key found therein to encrypt a session
key. We cannot do that if any key that *can be used* (definition,
please?) for encryption, or is even likely to be used for encryption,
as in these protocols it will, must be recoverable. It's impossible in
some cases and unacceptable in all, if this same key is used for identity
purposes.
I had proposed a standard tag that means "the subject key is an encryption
key", to be signed by the only one with proper authority, namely the keyholder.
But this discussion suggests, and I think I agree, that it should be a tag
parameter. This is not because of any legal or political concerns, since
the Kerry bill only refers to registered CAs, and individual users don't need
to be registered CAs. Rather, it's a structural problem, because the subject
key no longer identifies an entity, though I'm not sure that matters; by the
time this certificate is sought, the verifier has satisfied itself as to the
authorization requested. Also, this cert will not be sought as an exact
match, but only on the tag type, not its contents, which is the information
needed to set up a private session.
Any other discussion?
brian
Brian Thomas, CISSP - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@primary.net
One Bell Center, Room 34G3 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 235 0162
Follow-Ups: