On 9/4/2016 02:04, Eddy Nigg wrote: > On 09/02/2016 07:02 PM, Nick Lamb wrote: >> On Friday, 2 September 2016 08:50:02 UTC+1, Eddy Nigg wrote: >>> Lets speak about relying parties - how does this bug affect you? >> As a relying party I am entitled to assume that there is no more than >> one certificate signed by a particular issuer with a certain serial >> number. If I have seen this certificate and verified by whatever >> means I choose that it's OK, then I can safely assume that any time I >> see a certificate in the future signed by that issuer with that same >> serial number it's the same one, and skip the verification process. > > Well, according to the CA policies and relying party terms, you should > always check with the CRL or OCSP responders if a certificate is > considered valid or not. So the verification process shouldn't be > skipped beyond the advertised refresh time (in CRLs/OCSP). > > Of course if you do some sort of certificate pinning based on serial > and issuer, than this wouldn't work. But I'm not aware of any common > software that doesn't use the certificate's public key for pinning and > relies just on a serial numbers. >
1: NSS does in fact pin on serial numbers. It has actually stopped me from utilizing a site in Firefox specifically because a CA had issued multiple certificates with the same serial number. As a relying party, my first and foremost requirement is that my verification software can and will actually let me rely on your assertions of identity, even though it enforces the technical mandates of the specifications involved. (A duplicate certificate serial number explicitly violates the definition in section 3.5.13 of X.509. Since PKIX is a profile of X.509, PKIX inherits all assumptions and definitions of X.509. Furthermore, 4.1.2.2 of RFC 5280 specifies that it MUST be unique for each certificate issued by a given CA.) There is no mandate that a public key not be certified multiple times (thus permitting renewals without rekeying), but there is a mandate that multiple certificates with different information not be given the same serial number. 2: If I were to get into a legal dispute with the subject of a certificate you issued and needed to obtain the documentation you had that was related to your issuance of that particular certificate, I would probably request the documents from you based on the certificate serial number. You would then be able to pull the documents related to that serial number and copy them appropriately. With multiple certificates having the same serial number it would be easier for the following errors to show up: a) provision of documents that related to a certificate that wasn't the one in question (thus muddying the waters as to exactly who had been identified by the certificate in question), and b) failure to provision documents that did relate to the certificate in question (thus throwing your due diligence and my reliance on it into question), by being improperly identified by StartCom as not relevant to the certificate in question. In either case, your errors and omissions insurance would probably be paying out because I wouldn't be able to prove the validity of my reliance to pin whatever dispute on the entity I was suing. -Kyle H _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
