Good morning, On Fri, February 2, 2024 3:05 am, Lijun Liao wrote: > 1. oid: It is fine for me to extend it by only the PEN option. > 2. signatureAlgorithm: the only reason I see here is it breaks the already > deployed certificates.
The only reason to make this breaking change at this point in time is if there is a consensus that one-pass processing of signatures is an absolute requirement. I, for one, do not see that need. I work in very small environments, and I have not seen that need, yet. > 2.1. Considering the PQC certificate, the public key may be several > kilo-bytes, without the one-pass signature property, the additional > required memory usage is not ignorable. Okay, let's look at the NIST PQC algorithms: A Dilithum public key is 1-1.5 KB and signature is about 2-3 KB. (total 3-4.5 KB) A Falcon public key is 1-2 KB and signature is about 1 KB. (total 2-3 KB) Yes, this is much larger than the 32-64B of ECC, but in the grand scheme of things, compared to pretty much any other data structure, this additional size *IS* ignorable. If we were talking multiple tens of KBs, let alone MBs, then I would agree with you that we should revisit the topic. But even the smallest of devices can easily hold 2-5KB of data in RAM. > 2.2. As mentioned in the > https://github.com/cose-wg/CBOR-certificates/issues/152, if the CRL have > the same structure as in the current certificate, the impact may be much > larger. To parse the CRL, the application has to parse the > *revokedCertificates* field before getting the signature algorithm. And > since revokedCertificates may be very large, e,g. In mega-bytes. IMHO, > putting the *signatureAlgorithm* at the begging is necessary. > 2.3. To unify the structures of certificates and CRLs, I think > *signatureAlgorithm* shall also be at the begging. To keep the backwards > compatibility with the deployed certificates, we shall increase the syntax > version (the *version* field). I see no requirement or need to have the Certificate and CRL share a structure format. From where is that requirement stemming? Thanks, -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
