May 1 is a meeting at ICAO in Montreal for adding authentication via
TESLA with cert signing of the key for GPS. This is referred to as
Satellite-Based Augmentation System (SBAS) Authentication.
Because of the restricted payload size (and channel capacity), the
workgroup plans on using CBOR encoding of their rather small (already!)
DER encoded certificates.
We still are debating things like:
How large the serialNumber
What MUST be in DN
Is SKI for EE really needed
What hashing method for SKI/AKI
And I keep advising them that they can't have their head in the sand on
PQ, as they will be a prime target for QC attacks.
Anyway to squeeze out more bytes.
Fun stuff.
For this standard work, ICAO REALLY needs this draft advancing to RFC
status. How can we accelerate this progress?
The workgroup really expects me to report favorably on progress with
this draft. But, I don't control the drafting work, only along for the
ride...
Bob
On 4/17/25 10:45 AM, Sipos, Brian J. wrote:
Carsten and authors,
It's been a while to follow-up on this, and I appreciate the more procedural
way to extract the full CDDL. I'm still seeing parsing problems with the
extracted CDDL and (at least) some of these are from the C509 document itself.
I'm verifying the validity of the extracted CDDL with the commands:
kramdown-rfc draft-ietf-cose-cbor-encoded-cert.md
>draft-ietf-cose-cbor-encoded-cert.xml
kramdown-rfc-extract-sourcecode -tfiles
draft-ietf-cose-cbor-encoded-cert.xml
cddl compile-cddl --cddl sourcecode/cddl/c509.cddl
Where the CDDL tool I'm using is the rust implementation installed with "cargo
install cddl".
The three categories of errors that I see are:
1. I needed to add a rule for the "oid" type from RFC 9090 (as below) because it isn't
included in the C509 document. It would be good for the C509 to be self-contained if possible,
maybe defining 'inherited' rules in the Introduction section. Some of my own internet drafts add an
introduction subsection titled "Use of CDDL" that explains any inherited rules and their
sources, how the document uses CDDL generally, and how it can be extracted from the published XML.
oid = #6.111(bstr)
2. About the rule " IPAddressOrRange = AddressPrefix / AddressRange" the error " missing definition for
rule AddressPrefix" which appears to be because "AddressPrefix" itself is a group and not a type while
"AddressRange" is defined as an array type.
3. About rules that involve OIDs like " KeyPurposeId = int / ~oid" the error "
expected assignment token '=', '/=' or '//=' after rule identifier" which I don't fully
understand. Maybe the CDDL parser I'm using doesn't properly unwrap tagged rules..?
Any help with working these out would be appreciated, and I think would improve
the utility of the CDDL that is part of this document.
Thank you,
Brian S.
-----Original Message-----
From: Carsten Bormann <[email protected]>
Sent: Monday, January 27, 2025 11:30 AM
To: Sipos, Brian J. <[email protected]>
Cc: Göran Selander <[email protected]>;
[email protected]
Subject: [EXT] Re: [COSE] I-D Action: draft-ietf-cose-cbor-encoded-cert-12.txt
APL external email warning: Verify sender [email protected] before clicking links or
attachments
On 2025-01-17, at 15:15, Sipos, Brian J. <[email protected]> wrote:
• It is currently difficult to extract a full CDDL document for this
draft.
Could one be extracted and added to the Github repo for reference? Or some
procedure for how we can extract a full, valid CDDL definition from the
markdown?
I did some copy-paste work to get this and am running into tool errors, it
seems like the “time” rule is missing… but maybe I’m extracting an incomplete
set..?
Also some reference CDDL like the “oid” from RFC 9090 needs to be included
somehow; manually in a Github file is fine, but having a complete and parseable
CDDL document would be very valuable for users.
I just made a pull request with various kramdown-rfc and cddl cleanups:
https://github.com/cose-wg/CBOR-certificates/pull/215
This allows the use of
kramdown-rfc-extract-sourcecode -tfiles draft-ietf-cose-cbor-encoded-cert.xml
to create a file sourcecode/cddl/c509.cddl from the collected CDDL in the I-D.
This c509.cddl can then be used for instance as follows:
cddlc -s C509CertificateRequest -r2i rfc9090 sourcecode/cddl/c509.cddl -tcddl |
cddl - gp
(Use v and not g as the cddl option to validate and not generate an example.)
The -r2i rfc9090 imports the oid rule from RFC 9090 (see draft-ietf-cbor-cddl-
modules).
(The specific example generated is not that useful because of the heavy use of
“any” in the CDDL, so you may want to dive in with different -s arguments.)
Grüße, Carsten
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
