Issue: Placement of KEYINFO data

Dave writes:

> While I think we could do it either way, my preference is to have it
> outside the sigInfo.  If an application wants to bind the certificate
> (or other keyInfo) selected under the signature, then it can add a
> signedAttribute (ala CMS); however if you move the keyInfo into sigInfo,
> and an application doesn't want the binding, there isn't an option. 
> Moving it into sigInfo implies to me an expectation that base validation
> rules would do something with it, and I think we've ruled that out.

I think this is the better approach but for slightly different
reasons.

It is always the recipient which has to decide whether the trust
chain has the desired quality. Ultimately it is access to the private
key which is the only property which provides for identity binding.

I hope that nobody would suggest that the sender attempt to
enforce the choice of trust chain for verification on the recipient.
The same message may be sent to multiple recipients which would need
to verify the message according to different trust axioms. Cross
[, extreemly cross and downright incandescent with rage] certificicates
may well be involved at this point.

Even if one is working within a nicely structured hierarchy with none
of the chain discovery problems refered to, the private key used to
certify a document may be re-certified for a variety of reasons.
Perhaps the original cert has simply expired. Even if it is no
longer intended to use the cert to sign new documents it might
be desirable to re-issue a cert to advertise that the key is
still trustworthy.


Not including the keyinfo in the signature envelope has one very
important consequence which some may see as a bug, others as a
feature. If the document is signed using a key which is certified
more than once and the two trust chains have different extensions
the recipient can effectively choose between the extensions.

This may well be desirable, consider the case where certificate
A has a liability cap of $100 and cert B has a liability cap
of $1,000,000 and no fault insurance but contains a CRITICAL
OID requiring the recipient to perform an OCSP validation.

As a consequence, the certificate chain can only communicate
information about the decision to trust the key. It is not
sensible to use extensions in the cert chain to refer to 
issues affecting the semantics of the document signature.
This strikes me as a very good separation of concerns to
insist on.

Desirable or not, we need to be aware of the consequences of this
design choice and we should have an explanatory note in the
Security Issues section.


		Phill

Received on Thursday, 12 August 1999 11:38:24 UTC