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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
