Thanks for that quick response.  The existence of implementations makes me
feel better about the situation, including those in the shepherd's write up
would have been awesome.

I understand how easy it is to miss reviews.  I think it was a big win
having a PKI guy assigned to this draft as secdir reviewer!

Deb

On Tue, Apr 28, 2026 at 10:44 AM Göran Selander <[email protected]>
wrote:

> Hi Deb,
>
> Just a couple of quick reactions, mainly on the general comment, please
> see inline. More responses to the detailed comments will follow.
>
> Thanks,
> Göran
>
>
>
> *From: *Deb Cooley via Datatracker <[email protected]>
> *Date: *Tuesday, 28 April 2026 at 15:08
> *To: *The IESG <[email protected]>
> *Cc: *[email protected] <[email protected]>; [email protected] <
> [email protected]>; [email protected] <
> [email protected]>; [email protected] <
> [email protected]>
> *Subject: *Deb Cooley's No Objection on
> draft-ietf-cose-cbor-encoded-cert-18: (with COMMENT)
>
> Deb Cooley has entered the following ballot position for
> draft-ietf-cose-cbor-encoded-cert-18: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cfd526519356e462c31bb08dea5273f3d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639129785138488984%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gNLf9EVfDn1yn3V0LJjDBXeVqMc5iej55buMaeZQthI%3D&reserved=0
> <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/>
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-cbor-encoded-cert%2F&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cfd526519356e462c31bb08dea5273f3d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639129785138533146%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YtG5KcXGB%2BCf%2BMbG2PThkvGlMaS%2FeQreVu9PSDRytBs%3D&reserved=0
> <https://datatracker.ietf.org/doc/draft-ietf-cose-cbor-encoded-cert/>
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm balloting no obj, but there are substantial comments to address.  I did
> consider abstaining, see my 'general comment' near the top of my ballot.
>
> Thanks to Corey Bonnell for their secdir reviews.  I agree with many
> points in
> their review, and I would like to see their comments addressed.
>
> [ GS: Thanks, we missed that! As mentioned elsewhere, there's been some
> difficulties for the authors to follow up on the reviews. ]
>
> Thanks to Chris Inacio for deferring this draft for a telechat cycle, it
> is a
> complex draft for which I needed the extra time.
>
> General:  While one can claim that CBOR encoded certs eliminate the need
> for
> ASN.1 implementation, that only works if the C509 cert can only be CBOR
> encoded.  As it stands implementations now need both CBOR and
> ASN.1 depending
> on what certificates are being used.  Instead of reduced complexity, there
> is
> now double the complexity.  In addition, the choices that can be made for
> various field selections also increase the complexity, which under normal
> circumstances reduces interoperability.  Sadly there is only one prototype
> implementation currently.  I'll be curious to see what the uptake is for
> this
> idea as it stands.
>
>
> [ GS: For re-encoded X.509 certificates (c509CertificateType =
> 2) implementations need both CBOR and ASN.1.  This is the type considered
> by for example the aviation industry, since it is invertible and compatible
> with legacy CAs. However, for native C509 certificates
> (c509CertificateType = 3) implementations only need CBOR. This is useful,
> e.g., in systems where CAs are more easily controlled, including many IoT
> systems. This is the type we know is implemented by a car manufacturer and
> a CA software vendor. So, while the Rust code in the GitHub repo was
> developed by the authors mainly for trying out the concept, there are
> multiple independent implementations. (Incidentally, the reason why
> c509CertificateTypes 0 and 1 are reserved is because of another early
> deployment.) ]
>
>
>
>
>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to