Changing the format has the advantage of allowing the one-pass signature verification and parsing, which reduces the compute (pasing) and memory usage. But it breaks already deployed certificates. With the current format we have the opposite pro and con. I personally prefer to add new types for the new format, to keep the old certificates still valid.
BR/Lijun On Fri, Feb 2, 2024 at 2:51 PM Derek Atkins <[email protected]> wrote: > Hi, > > On Fri, February 2, 2024 7:57 am, Lijun Liao wrote: > > Derek Atkins <[email protected]> schrieb am Fr., 2. Feb. 2024, 13:32: > > > [snip] > >> 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. > > I'm working on an MCU as well. We even have code on an AVR8. I > understand the "every KB counts" argument. > > For a certificate chain, there is no requirement that all certificates in > the chain be held in RAM together. You can process each certificate in > the chain somewhat indepenently, only storing the absolutely minimum data > required between them. Indeed, we did this ourselves when having to > handle this exact same situation -- we stream the chain one block at a > time so as not to require the full chain in RAM. The same can be done > here, so really, the most you need to store is 2x the size of the > certificate. > > > > > > > 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. > > I understand it is still an I-D, but it's been pretty stable (modulo some > minor changes and additions of extra data type values) for the past 3-4 > years. I think we started our implementation pre-COVID (which is when we > discovered the test vectors were wrong)! I'd have to go back and check > the exact date. > > [snip] > >> 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. > > We have not implemented CRL structures, so I have less skin in the game > there. > I can see how having a CBOR CRL map to the ASN1 CRL makes sense, although > I don't think it needs to be a direct syntactic translation; semantic > translation would suffice. Regardless, I don't see why the on-the-wire > data format of a CRL needs to be exactly the same as the on-the-wire data > format of a Certificate. > > > Gören -- responding to your additional message... I do agree that if we > could roll back time and go back to 2019 it would make sense to put the > algorithm identifier at the front of the structure. > > Using different identifiers (0,1 / 2,3) for the different structures would > solve the problem at the expense of a larger (and more complex) > specification and, possibly, more code to those that want to handle both > versions. Personally, I don't think we would implement versions 2,3 -- > and I suspect others would probably not implement versions 0,1, which > would lead to bifurcated systems. If others don't mind that, I could > certainly live with it. > > > Orie, > > > That said, the breaking changes should be worth it > > This is my point -- I don't see this particular change being worth it. > > The only place this would matter is for people wanting to use non-standard > PQC algorithms (which have EXTREMELY large key and/or signature sizes, > compared to NIST's Falson and Dilithum). Regardless, the CODE side > required to implement the PQC algorithm is often still going to be larger > than the supposed savings of streaming the certificate. If you have > enough space for the implementation, you have enough space for the > certificate. At least that is my experience. > > -derek > > -- > Derek Atkins 617-623-3745 > [email protected] www.ihtfp.com > Computer and Internet Security Consultant > > -- Lijun Liao
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
