Re: Redundant signature algorithm info in certs.
Erwann Abalea <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <CA+i=0E5M3XOKqtn+OVAJEMir4ThqMgYVXc6RX5VmQpMaUgzQkQ@mail.gmail.com> |
Bonsoir, 2016-05-24 15:06 GMT+02:00 Erik Andersen <[email protected]>: > The question about apparently redundant signature algorithm information in > public-key certificates, attribute certificates and CRLs has been raised > before. It seems clear that by including the signature algorithm within the > body of the cert, it is protected by the signature. But why does the > algorithm then has to be part of the signature itself? > Probably because X.509 starts by defining what a signature is, defining a SIGNED ASN.1 macro able to take a private key, a signature algorithm, and some opaque "ToBeSigned" data, resulting in a complete structure that can be passed to an equivalent hypothetical VERIFY macro? This macro doesn't need to know that the signatureAlgorithm is or isn't included in this ToBeSigned. From an API point of view, that doesn't sound illogical. A Certificate is defined as a SIGNED{Something} since the 1993 edition, at least. The order between "defining what is a Certificate" and "what is a digital signature" has been reversed between 1993 and 1997 editions. I am not suggesting to change current specifications. The question could be > relevant for new signed structures developed by other specifications. > > PKCS#7/CMS hasn't followed this path. What is really protected in integrity is either the sole content or a DER encoded version of the signed attributes. The signature algorithm in itself isn't protected. -- Erwann. _______________________________________________ pkix mailing list [email protected] https://www.ietf.org/mailman/listinfo/pkix