Thanks, Göran! Michael,
On Wed, January 31, 2024 1:55 am, G�ran Selander wrote: > Hi Michael, > > The proposal is to change TBSCertificate of C509, i.e. what is being > signed, both in case of compressed X.509 and native. So existing C509 > implementations need to change and existing C509 certificates are not > compliant. I don’t know to what extent this is already deployed, Derek is > one. And I can’t say how important one-pass verification is in this case. > Which is why we asked the WG for more input. This is exactly the issue.. By changing TBSCertificate, it is making my existing (deployed) code invalid, and also invalidating all my devices deployed in the field because their manufacturer certificates would no longer be considered valid. In my case, the certificates are under 1KB (many under 512B), which is easily held in RAM in even the smallest of devices. > > Göran > > > On 2024-01-31, 04:25, "Michael Richardson" <[email protected]> wrote: > > > Derek Atkins <[email protected] <mailto:[email protected]>> wrote: > >> I object to change #2. > > > > okay. > > > >> My objection is based on three issues: 1) It would break all existing > >> code 2) It would invalidate all existing certificates 3) These > > > > Why is that? > > I don't see it. What don't you see? TBSCertificate currently has structure a,b,c,d,e,f,g that gets signed. The proposal changes the structure to a,b,g,d,e,f. This is an incompatible change, so certificates structured and signed the old way would not be valid by parsers who read it the new way. Similarly, "new" certs would not be valid by "old" parsers. > > > > What I think Goran is saying is that when encoding/compressing, that we'd > > take the value from a different location (which should be identical), and > > then when restoring, we'd restore the value to both locations. > > It could also be that he is talking about Native signed C509, which has no > > installed base. Maybe I mis-understand the proposal. You are mis-understanding the proposal. The proposal is to change the order of items in the TBSCertificate "array". > > > > The words from the email: > > > >>> 2. Another proposed simple but breaking change is about the location > >>> of the signature algorithm in the CDDL for C509Certificate. In common > >>> X.509 certificates this information is given twice, in the > >>> signatureAlgorithm and Signature fields of TBSCertificate, containing > >>> identical values. In -07 we only have the field corresponding to the > >>> second occurrence at the end of TBSCertificate. The proposal is to > >>> change this to first occurrence, to enable essentially one-pass > >>> signature verification. > > > > I'd still like better terms than C509 and Natively signed C509. I consider "C509" to be native, and my C509Certificate only implements that. I don't have a word for CBOR-encoded-X509 because, frankly, I don't use it or implement it. -derek -- Derek Atkins 617-623-3745 [email protected] www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
