===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/74.html,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- www/74.html	2023/10/11 15:32:29	1.22
+++ www/74.html	2023/10/11 16:19:33	1.23
@@ -314,7 +314,70 @@
   </ul>
   <li><a href="https://man.openbsd.org/rpki-client.8">rpki-client(8)</a> saw some changes:
   <ul>
-	<li>...
+	<li>A 30%-50% performance improvement was achieved through libcrypto's
+	    partial chains certificate validation feature. Already validated
+	    non-inheriting CA certificates are now marked as trusted roots. This
+	    way it can be ensured that a leaf's delegated resources are properly
+	    covered, and at the same time most validation paths are
+	    significantly shortened.
+	<li>Support for gzip and deflate HTTP Content-Encoding compression was
+	    added. This allows web servers to send RRDP XML in compressed form,
+	    saving around 50% of bandwidth.
+	<li>ASPA support was updated to draft-ietf-sidrops-aspa-profile-16.
+	    As part of supporting AFI-agnostic ASPAs, the JSON syntax for
+	    Validated ASPA Payloads changed in both filemode and normal output.
+	<li>In filemode (-f option) the applicable manifests are now shown as
+	    part of the signature path.
+	<li>A new -P option was added to manually specify a moment in time
+	    to use when parsing the validity window of certificates. Useful
+	    for regression testing. Default is invocation time of rpki-client.
+	<li>The -A option will now also exclude ASPA data from the JSON output.
+	<li>The synchronisation protocol used to sync the repository is now
+	    included in the OpenMetrics output.
+	<li>Improved accounting by tracking objects both by repo and tal.
+	<li>Check whether products listed on a manifest were issued by the same
+	    authority as the manifest itself.
+	<li>File modification timestamps of objects retrieved via RRDP are now
+	    deterministically set to prepare the on-disk cache for seamless
+	    failovers from RRDP to RSYNC.
+	<li>Improved detection of RRDP session desynchronization: a check was
+	    added to compare whether the delta hashes associated to previously
+	    seen serials are different in newly fetched notification files.
+	<li>Improved handling of RRDP deltas in which objects are published,
+	    withdrawn, and published again.
+	<li>Disallow X.509 v2 issuer and subject unique identifiers in certs.
+	    RPKI CAs will never issue certificates with V2 unique identifiers.
+	<li>A check to disallow duplicate X.509 certificate extensions was
+	    added.
+	<li>A check to disallow empty sets of IP Addresses or AS numbers in RFC
+	    3779 extensions was added.
+	<li>A warning is printed when the CMS signing-time attribute in a Signed
+	    Object is missing.
+	<li>Warnings about unrecoverable message digest mismatches now include
+	    the manifestNumber to aid debugging the cause.
+	<li>A check was added to disallow multiple RRDP publish elements for the
+	    same file in RRDP snapshots. If this error condition is encountered,
+	    the RRDP transfer is failed and the RP falls back to rsync.
+	<li>A compliance check for the proper X.509 Certificate version and CRL
+	    version was added.
+	<li>A compliance check was added to ensure CMS Signed Objects contain
+	    SignedData, in accordance to RFC 6488 section 3 checklist item 1a.
+	<li>Compliance checks were added for the version, KeyUsage, and
+	    ExtendedKeyUsage of EE certificates in Manifest, TAK, and GBR Signed
+	    Objects.
+	<li>A CMS signing-time value being after the X.509 notAfter timestamp
+	    was downgraded from an error to a warning.
+	<li>A bug was fixed in the handling of CA certificates which inherit IP
+	    resources.
+	<li>A compliance check was added to ensure the X.509 Subject only
+	    contains commonName and optionally serialNumber.
+	<li>A compliance check was added to ensure the CMS SignedData and
+	    SignerInfo versions to be 3.
+	<li>Fisher-Yates shuffle the order in which Manifest entries are
+	    processed. Previously, work items were enqueued in the order the CA
+	    intended them to appear on a Manifest. However, there is no obvious
+	    benefit to third parties deciding the order in which things are
+	    processed.
   </ul>
 
   <li>In <a href="https://man.openbsd.org/snmpd.8">snmpd(8)</a>,