Drafts are work in progress, and breaking changes should be expected. I would feel uncomfortable passing up improvements from breaking changes, especially if they were significant, just because deployments of drafts exist.
That said, the breaking changes should be worth it, and some extra visuals might help sell them better. Perhaps a few charts showing why the change is worth it would help? OS On Fri, Feb 2, 2024, 7:22 AM Göran Selander <goran.selander= [email protected]> wrote: > 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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
