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.
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 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. 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. -- Michael Richardson <[email protected] <mailto:[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
