CVSROOT: /cvs
Module name: src
Changes by: [email protected] 2025/12/05 00:26:42
Modified files:
usr.sbin/rpki-client: ccr.c rpki-asn1.h
Log message:
rpki-client: turn CCR into a proper CMS citizen
Using an EncapsulatedContentInfo was a hack which arose out of the
desire of having an OID next to the stuff we really care about.
Russ Housley pointed out that an EncapsulatedContentInfo is never
really used at the top level and that CMS (of course) has a proper
mechanism for this. (The absence of signers also makes this original
choice dubious, see last paragraph before RFC 5652, section 5.2.1.)
So, switch to a ContentInfo and fix another encoding issue, namely
using a naked OID instead of a CMS DigestAlgorithmIdentifier.
In addition to CCR becoming a plain CMS object, the code becomes
simpler overall despite the DigestAlgorithmIdentifier adding some
complexity. The big win is that the opaque OCTET STRING wrapping
the CCR SEQUENCE and the manual DER wrangling can go away.
Russ confirmed by decoding a detailed example that this produces
the appropriate DER matching the changes in the ASN.1 in
draft-ietf-sidrops-rpki-ccr-02.txt.
In detail:
- mechanically rename EncapContentInfo (back) to ContentInfo
- embed the CanonicalCacheRepresentation directly in ContentInfo
- make hashAlg an X509_ALGOR, representing an AlgorithmIdentifier
rather than an ASN1_OBJECT (an OID).
- in generate_ccr() we embed the OID in the X509_ALGOR with no
parameters V_ASN1_UNDEF, as appropriate for SHA-256
- in serialize_ccr_content() and ccr_parse() get rid of the OCTET
STRING wrapping dance
- in ccr_parse() unwrap OID and parameters and check they are as
they should be for SHA-256.
ok job
