Specify that the EncapsulatedContentInfo MUST be some specific value (allocate an OID from IETF/IANA/whatever). RFC5652 states that if the EncapsulatedContentInfo is not id-data, then the signedAttrs MUST be present (whence solution 2 will apply).
2015-03-27 17:08 GMT+01:00 trans issue tracker <[email protected]>: > #79: Precertificate signature must be over something other than just the > TBSCertificate > > If I understand the CMS spec correctly, then we're currently defining a > Precertificate to be a CMS structure that contains a TBSCertificate and a > signature over just that TBSCertificate. > That means that the components of a Precertificate can be trivially > rearranged into an X.509 certificate with a valid signature! > > To fix this, we need to either... > > 1. Require the SignedData.encapContentInfo.eContent field to contain > "something || TBSCertificate" or "TBSCertificate || something". > or > 2. Require a signed attribute to be present in > SignedData.signerInfos[0].signedAttrs. This is essentially equivalent to > "TBSCertificate || something" in terms of what gets signed. > > I think 2 is the cleaner solution, unless there's a cryptographic reason > to prefer "something || TBSCertificate" (e.g. to protect against chosen > prefix collisions?) > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-trans- > [email protected] | [email protected] > Type: defect | Status: new > Priority: blocker | Milestone: > Component: rfc6962-bis | Version: > Severity: - | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/79> > trans <http://tools.ietf.org/trans/> > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > -- Erwann.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
