Hi, I object to change #2.
My objection is based on three issues: 1) It would break all existing code 2) It would invalidate all existing certificates 3) These certificates are just not big enough, even when considering PQC, that running it in a "single-pass" without buffering is a necessary goal. Honestly, even if a certificate a 1MB, I don't see the need to validate that ina streaming vs buffering method. In practice, except for certain (non standard) PQC mechanisms, the certificates are going to be in the KB size range, not MB size range, so breaking all existing implementations and deployments seems not warranted. Thanks, -derek On Tue, January 30, 2024 10:04 am, G�ran Selander wrote: > All, > > > > We got some suggestions for updates to C509 and would like to learn if > there are any preferences from the WG. Two issues are highlighted in this > mail, for more info see GitHub issue > tracker<https://github.com/cose-wg/CBOR-certificates/issues>. > > > > > > 1. One suggestion is to have a more optimised encoding for PEN using > relative OIDs, see > #143<https://github.com/cose-wg/CBOR-certificates/issues/143>. > > Here is the proposed change for extensions and attributes: > > > > OLD (-07) > > Extension = ( extensionID: int, extensionValue: any ) // > > ( extensionID: ~oid, ? critical: true, extensionValue: bytes ) > > > > NEW > > Extension = ( extensionID: int, extensionValue: any ) // > > ( extensionID: ~oid, ? critical: true, extensionValue: bytes ) > // > > ( extensionID: [int, ~roid], extensionValue: bytes ) > > > > > > > > OLD > > Attribute = ( attributeType: int, attributeValue: text ) // > > ( attributeType: ~oid, attributeValue: bytes ) > > > > > > NEW > > Attribute = ( attributeType: int, attributeValue: text ) // > > ( attributeType: ~oid, attributeValue: bytes ) // > > ( attributeType: [int, ~roid], attributeValue: bytes ) > > > > > > where there will be a new register with integers representing OIDs from > which the relative OID is based. Critical extensions are handled using > negative numbers in the same way as with the other int-based encoding. The > same construction is proposed to be applied to other settings relevant to > PEN, such as KeyPurposeID and PolicyIdentifier, see > #143<https://github.com/cose-wg/CBOR-certificates/issues/143>. > > > > Any objections to this or other comments? > > > > > > 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. > > > > > > C509Certificate = [ > > TBSCertificate, > > issuerSignatureValue : any, > > ] > > > > > > OLD > > > > TBSCertificate = ( > > c509CertificateType: int, > > certificateSerialNumber: CertificateSerialNumber, > > > > issuer: Name, > > validityNotBefore: Time, > > validityNotAfter: Time, > > subject: Name, > > subjectPublicKeyAlgorithm: AlgorithmIdentifier, > > subjectPublicKey: any, > > extensions: Extensions, > > issuerSignatureAlgorithm: AlgorithmIdentifier, > > ) > > > > > > NEW > > > > TBSCertificate = ( > > c509CertificateType: int, > > certificateSerialNumber: CertificateSerialNumber, > > issuerSignatureAlgorithm: AlgorithmIdentifier, > > issuer: Name, > > validityNotBefore: Time, > > validityNotAfter: Time, > > subject: Name, > > subjectPublicKeyAlgorithm: AlgorithmIdentifier, > > subjectPublicKey: any, > > extensions: Extensions, > > > > ) > > > > Any objections to this or other comments? > > > > > > G�ran > > > > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- 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
