Hi, Without casting my vote, I think Lijun has a point. With hindsight, if we today were to make the choice where to place the signature algorithm, we would probably choose the first instance for the reasons mentioned. Alignment between certificate and CRL format is not crucial. But there is a large span in device capabilities, and there are other signature algorithms to come, so it may be difficult at this stage to rule out that this construction may have an impact on the performance.
I also appreciate Derek’s argument about existing deployment. We do have the capability to define a new 'c509CertificateType'. The purpose of this field is to handle exactly this kind of situation when we need to distinguish between different versions. We didn’t think it would be necessary to define different versions during the specification phase, but considering that this work has been on the back burner for some time maybe this is one way to resolve differences between early adopters and newcomers? For example, we can reserve type 0 and 1 for the current versions, and add types 2 and 3 for the new versions of native and compressed X.509, respectively. (We probably still want to make some statement of which of the formats to recommend to avoid fragmentation.) Derek: Do you think there can be a way forward along these lines? What do others think? Göran From: COSE <[email protected]> on behalf of Derek Atkins <[email protected]> Date: Friday, 2 February 2024 at 13:32 To: Lijun Liao <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [COSE] C509: Optimisations for PEN and location of signatureAlgorithm 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-ca236a5313308fcc&q=1&e=7514c336-4107-4b64-8253-ddcc11396f15&u=https%3A%2F%2Fgithub.com%2Fcose-wg%2FCBOR-certificates%2Fissues%2F152, > 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] https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-79afdf7e0321e455&q=1&e=7514c336-4107-4b64-8253-ddcc11396f15&u=http%3A%2F%2Fwww.ihtfp.com%2F Computer and Internet Security Consultant _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
