Update:

C509 vs X509 is much more than CBOR vs ASN.1 DER, here some key optimisation 
points:

1. Use int instead of AlgorithmIdentifier to identify the signature algorithms, 
key algorithms
2. Use int instead of OBJECT IDENTIFIER to identify RDN (a names consisting of 
multiple RDNs), extensions, Extended Key Usage, Policy Identifiers, ….
3. Use text (or SpecialText for technically correct) instead of complex ASN.1 
SET for RDN value.
4. Use better machine-readable int instead of text for the timestamp (e.g. in 
NOT BEFORE, NOT AFTER).


> On 9. Oct 2025, at 11:48, Lijun Liao <[email protected]> wrote:
> 
> In the PQC era, the main advantage of C509 (CBOR) is the simple encoding 
> (CBOR vs ASN.1 DER).
> 
> Please do not ignore this difference. Due to the complexity of X.509, the 
> (latest) mbed-tls is only able to parse a very limited subset of the 
> extensions.
> 
> Regards, Lijun
> 
> 
>> On 9. Oct 2025, at 11:41, Blumenthal, Uri - 0553 - MITLL <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> Trying to understand: with the inevitable move to PQ algorithms and 
>> certificates, the bulk of the certificate “volume” will be occupied by the 
>> public key and signature - the metadata size will “drown in the noise”. 
>> 
>> In that case, what are the benefits of CBOR?
>> Or is the assumption that ECC crypto with its small key and signature sizes  
>> will be there for the foreseeable future?
>> —
>> Regards,
>> Uri
>> 
>> Secure Resilient Systems and Technologies
>> MIT Lincoln Laboratory
>> 
>>> On Oct 9, 2025, at 04:46, Lijun Liao <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> 
>>> This Message Is From an External Sender
>>> This message came from outside the Laboratory.
>>> 1. There are not standard-conform X509 certificates, but such certificates 
>>> are usually not allowed in the public areas (e.g. CA/Browser Forum). If 
>>> exists, only ignorable percent. 
>>> 2. For the not standard-conform fields issuer, subject, and extensions, the 
>>> CBOR-compressed version uses the DER-encoded bytes  so that it can still be 
>>> converted back.
>>> 
>>>> On 8. Oct 2025, at 23:19, Phillip Hallam-Baker <[email protected]> 
>>>> wrote:
>>>> 
>>>> It is a feature that is going to impose a very high burden on developers, 
>>>> is unlikely to work because of issues that are outside their control (i.e. 
>>>> X.509v3 certs not necessarily using correct DER) and is going to prevent 
>>>> the wider effort taking advantage of the opportunity to break backwards 
>>>> compatibility and jettison some of the X.500 legacy.
>>> 
>>> _______________________________________________
>>> COSE mailing list -- [email protected] <mailto:[email protected]>
>>> To unsubscribe send an email to [email protected] 
>>> <mailto:[email protected]>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to