Re: x.509 signature clarification?

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

> On Thu, Jul 05, 2001 at 01:09:39PM -0600, Joseph Galbraith wrote:
> > 
> > I'm tempted to suggest that the signature is in PKCS #7
> > format, though this seems to be a bit of an overkill...
> > it would however, address both the above problems, because
> > the digest algorithm would be specified as part of the PKCS #7
> > packet.  We might consider specifying a PKCS #7 signature,
> > with an "external signature" and no included certificates
> > or CRL information.
> 
> Actually, I think that if we were to go with PKCS #7 (which might
> not really be such a bad idea) we'd want to fill out the certificate
> as fully as possible, including CRL information.  Look what's happened
> to people who've failed to do so (e.g. VeriSign, who ended up in the
> unenviable position of having issued bogus certificates but being unable
> to revoke them!).
> 
> Certainly we should not specify that the CRL field is *not* to be
> filled in.

Hmm... the certificate itself has already
been communicated via the SSH protocol, which
is why I wrote what I did.  But, on the other hand,
it might be nice to be able to include other
certificates from the chain in the signature.

I think that CRLs in a PKCS #7 signature
are "hotlist" items intended as one method
of propagating revocations and to allow the
verifier to update it's certificate database.

They clearly can't be used to validate the
Certificate in use, since if I'm an attacker
using a compromised certificate, I'm certainly
not going to tell you it's been revoked!

On the other hand, it seems much cleaner to
 accept PKCS #7 entirely, rather then try
to specify PKCS #7 minus this feature and
that feature.  So, I think you're right,
if we decide to go with PKCS #7, we shouldn't
restrict what fields can be used.

I original thought that I PKCS #7 had a lot
of information that was not applicable to
SSH applications or was redundant... but,
on further thought, (and having actually
implemented a decoder / encoder now), it
seems that most of the information is useful
to us in the SSH context.  So perhaps PKCS #7
isn't an overkill.

Would implementers find it overly burdensome to
implement PKCS #7?  Or are most people using
crypto libraries that would already do this
for them?

For myself, my crypto library produces PKCS #7,
so it would actually be more convenient for me...
otherwise, I have to decode the PKCS #7 packet
on the signing side and build a PKCS #7 packet
on the verifying side.

Joseph Galbraith
galb-list%vandyke.com@localhost