[pkix] RFC5280 "Freshest CRL" Duplication - erratum?
Sean Williams <[email protected]> Fri, 9 Jan 2026 01:40:49 +0000
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <BY5PR02MB674083F9B8913F093F242260BF85A@BY5PR02MB6740.namprd02.prod.outlook.com> |
--===============3939869503601057901==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_BY5PR02MB674083F9B8913F093F242260BF85ABY5PR02MB6740namp_"
--_000_BY5PR02MB674083F9B8913F093F242260BF85ABY5PR02MB6740namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hey folks,
My org is deploying a new CA service issuing certs for clients in a polyglo=
t OS/language ecosystem. While enabling online revocation via CRL, we disco=
vered that clients on another OS weren't polling for delta CRLs from the CA=
. Base CRL distribution/ingestion as described in section 4.2.1.13 et al st=
ill work as expected.
Our previously-operated CA service (we'll call this "CA Service A") support=
s publishing delta CRLs, and these were indeed getting consumed by the OS. =
The new CA service ("CA Service B") does as well, but clients aren't pickin=
g it up.
After some deep dives, we discovered an incompatibility between vendors - l=
ikely fueled by differing interpretations of RFC5280:
*
CA Service A uses the Freshest CRL extension in the CRL itself, described i=
n section 5.2.6 of RFC 5280.
*
CA Service B uses the Freshest CRL extension on certificates the CA issues,=
described in section 4.2.1.15 of RFC 5280.
In our tests, the OS only parses the CRL's extension (5.2.6), not the certi=
ficate's.
Both of these services seem to be in the right. The extension is labeled op=
tional (in both places) in the RFC. Both services are consuming/expecting t=
he same data, labeled with the same OID - they're just doing so from two di=
fferent locations. The spec describes the similarity in data format between=
the two extensions, but leaves the actual data contract between them (and =
issuers+verifiers as executors of that contract) undefined.
CA Service A and the OS in question are more tightly integrated, but reason=
able interpretations of the spec would suggest this should "just work" betw=
een conformant CAs/online verifiers.
I'm not sure if this would fall under technical errata or not - wanted to o=
pen a line of dialogue to understand architectural intent and so on.
Cheers!
--Sean W.
--_000_BY5PR02MB674083F9B8913F093F242260BF85ABY5PR02MB6740namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
Hey folks,</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
My org is deploying a new CA service issuing certs for clients in a polyglo=
t OS/language ecosystem. While enabling online revocation via CRL, we disco=
vered that clients on another OS weren't polling for delta CRLs from the CA=
. Base CRL distribution/ingestion
as described in section 4.2.1.13 et al still work as expected.</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
Our previously-operated CA service (we'll call this "CA Service A"=
;) supports publishing delta CRLs, and these were indeed getting consumed b=
y the OS. The new CA service ("CA Service B") does as well, but c=
lients aren't picking it up.</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
After some deep dives, we discovered an incompatibility between vendors - l=
ikely fueled by differing interpretations of RFC5280:</div>
<ul data-editing-info=3D"{"applyListStyleFromLevel":false,"u=
norderedStyleType":1}" style=3D"margin-top: 0px; margin-bottom: 0px; l=
ist-style-type: disc;">
<li style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apto=
s_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; col=
or: rgb(0, 0, 0);">
<div role=3D"presentation" class=3D"elementToProof">CA Service A uses the F=
reshest CRL extension in the CRL itself, described in section 5.2.6 of RFC =
5280.</div>
</li><li style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "=
;Aptos_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt=
; color: rgb(0, 0, 0);">
<div role=3D"presentation" class=3D"elementToProof">CA Service B uses the F=
reshest CRL extension on certificates the CA issues, described in section 4=
.2.1.15 of RFC 5280.</div>
</li></ul>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
In our tests, the OS only parses the CRL's extension (5.2.6), not the certi=
ficate's. </div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
Both of these services seem to be in the right. The extension is labeled op=
tional (in both places) in the RFC. Both services are consuming/expecting t=
he same data, labeled with the same OID - they're just doing so from two di=
fferent locations. The spec describes
the similarity in data format between the two extensions, but leaves the a=
ctual data contract between them (and issuers+verifiers as executors of tha=
t contract) undefined. </div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
CA Service A and the OS in question are more tightly integrated, but reason=
able interpretations of the spec would suggest this should "just work&=
quot; between conformant CAs/online verifiers.</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
I'm not sure if this would fall under technical errata or not - wanted to o=
pen a line of dialogue to understand architectural intent and so on.</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
Cheers!</div>
<div style=3D"font-family: Aptos, "Aptos_EmbeddedFont", "Apt=
os_MSFontService", Calibri, Helvetica, sans-serif; font-size: 12pt; co=
lor: rgb(0, 0, 0);" class=3D"elementToProof">
--Sean W.</div>
</body>
</html>
--_000_BY5PR02MB674083F9B8913F093F242260BF85ABY5PR02MB6740namp_--
--===============3939869503601057901==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls
aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBraXgtbGVhdmVAaWV0Zi5vcmcK
--===============3939869503601057901==--