Derek Atkins <[email protected]> schrieb am Fr., 2. Feb. 2024, 13:32: > 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. > For one certificate, this may be ok. But for a certificate chain (let's say 4 levels), you have about additional 8-20KB in RAM. I am currently working on a MCU, every KB counts. Note that in the DICE proposed by TCG, you usually have 4+ levels. Add with the introduction of new version, your deployed certificates remain still valid. Btw, this is still in I-D status, if published as RFC, I will also not change the structure. > > 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? > There is no requirement, but it is much beter to keep all data structures in pkix (CRL, CSR, OCSP, CRL) having the same structure logic. > Thanks, > > -derek > > -- > Derek Atkins 617-623-3745 > [email protected] www.ihtfp.com > Computer and Internet Security Consultant > Thanks Lijun >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
