A Certificate's Issuer binds a Subject and its Public Key with a specific
set of Claims (e.g. Account #, validity period, etc.). The same Public Key
might be bound in different Certificates (for the same or other Subject)
to different sets of Claims. So there may exist more than one valid
Certificate with the same Public Key. Including the Certificate with the
in the signature makes eliminates the possibility that the Certificate
might be replaced after signing.
Thanks,
Mike
w3c-ietf-xmldsig-request@w3.org wrote on 03/11/2004 01:49:36 PM:
>
>
> A novice question. Pardon me if it is obvious.
> What is the need for signing the X509 certificate.
> Since each certificate contains a signature of its
> contents, which is validated by the next level Cert,
> until a self signed Cert is met. And the root Cert
> (self signed) is not trusted unless the receiver has
> that certificate in his/her cert store already.
>
> Even if the Certs are signed, by a reference,
> its still not secure until a trusted Cert (present in
> Cert store) is present in the Cert chain, isnt it. As
> long Cert validation happens, the contents is not
> trustable isnt it. And Cert validation is a prerequisite,
> and independent of the authenticating of the message
> received, isnt it.
>
> thanks
> Joseph
>
> Rich Salz wrote:
>
> >
> >> Sorry for the stupid question but since X509Data and X509Certificate
> >> do not support "Id" attributes, would not KeyInfo would be a better
> >> candidate?
> >
> >
> > Not a stupid question -- it shows you've read the spec more carefully
> > than I have, or that I've forgotten too much.
> >
> > Yes, keyinfo would be what you have to use.
> > Or perhaps an errata that adds an id attribute would be best. :)
> >
>
>