Thanks Ilari! I will go through your comments next week and include updates for version -01.
Great that you are implementing, there are other people implementing as well. In the future, we should maybe make a list of implementations and maybe make sure that they are interoperable. Next week I will release the RUST code I wrote to generate the examples in the draft. My code take a DER encoded cert from file, or a DER encoded chain from a TLS server and compress it to C509. Cheers, John -----Original Message----- From: COSE <[email protected]> on behalf of Ilari Liusvaara <[email protected]> Date: Monday, 22 March 2021 at 18:26 To: cose <[email protected]> Subject: [COSE] Some comments on draft-mattsson-cose-cbor-cert-compress I am trying to write an implementation of draft-mattsson-cose-cbor-cert-compress, some comments on editor's draft about things that came up: - Section 3.3. Encoding of Extensions says that: "Critical extensions are encoded with a positive sign and non-critical extensions are encoded with a negative sign." However, section 8.3. C509 Certificate Extensions Registry has: 0 -> Subject Key Identifier 0 is neither positive nor negative, so sign-flipping can not be used with it. Name kinds do similar name flipping, but there at least is no name kind 0. - Section 3.3. Encoding of Extensions says that: "Critical extensions are encoded with a positive sign and non-critical extensions are encoded with a negative sign." However, section 3.3.1. Example Encoding of Extensions contains a number of examples, where seemingly sign is used in exactly the opposite way (positive is non-critical, negative is critical). - Section 8.3. C509 Certificate Extensions Registry has: Authority Key Identifier -> bytes However, section 3.3. Encoding of Extensions says: "authorityKeyIdentifier. extensionValue is encoded as an array where" So AKI may be an array. - Section 3.3. Encoding of Extensions has CDDL, which has derivation: ExtValueAKI -> bytes However, the prose does not seem to say what having bytes there means. It would make sense to use bytes to mean AKI that has only the keyIdentifier field, as that is seemignly the most common case, and it would make AKI match up with SKI. - Section 8.3. C509 Certificate Extensions Registry has: Extended Key Usage -> int However, section 3.3. Encoding of Extensions says: "extKeyUsage. extensionValue is encoded as an array of" So EKU may be an array. - Section 3.1. Message Fields says: "If the array contains exactly two ints and the absolute value of the first int is 2, the array is omitted and" Extension 2 is Subject Alternative Name, which does not admit int as argument (only array and text). - Unknown algorithms with no parameters could be encoded as bytes instead of current [bytes]. - Unknown non-critical extensions could be encoded as (bytes, bytes) instead of current (bytes, false, bytes). - This may be intentional, but looks bit odd: RSASSA-PKCS1-v1_5 with SHA-256 is 23, which is 1 byte int, whereas all the other RSA signatures use 2 byte identifiers. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
