Raised during the independent review of #190, flagged as low confidence and needing knowledge outside this repository.
PowerShellBuild/build.properties.ps1 describes the setting as an RFC 3161 timestamp server, and #190 carried that wording into the README:
# RFC 3161 timestamp server URI embedded in Authenticode signatures.
TimestampServer = "http://timestamp.digicert.com"
The value is passed to Set-AuthenticodeSignature -TimestampServer. The reviewer notes that this parameter has historically used the legacy Authenticode timestamping protocol, not RFC 3161 — the distinction being signtool /t versus signtool /tr. If that is right, the comment names the wrong protocol and the README now repeats it.
Why it is worth checking rather than assuming
http://timestamp.digicert.com answers both protocols depending on what the client asks for, so a signed module verifies either way and nothing visibly breaks. That is exactly why a wrong label here could persist indefinitely.
It also matters for anyone choosing a different timestamp server: several providers publish separate endpoints for legacy Authenticode and RFC 3161. A consumer who reads "RFC 3161" and configures an RFC 3161-only endpoint could find timestamping fails, with the documentation having pointed them there.
What would settle it
Sign something with Set-AuthenticodeSignature -TimestampServer, then inspect the resulting signature for which timestamp structure it carries — an RFC 3161 signature has a 1.3.6.1.4.1.311.3.3.1 unauthenticated attribute, where legacy Authenticode uses a counter-signature. Get-AuthenticodeSignature and signtool verify /pa /v both surface enough to tell them apart.
Scope
This is inherited wording, not something #190 or #194 introduced. Fix the comment and the README row together, or — if the parameter does support RFC 3161 on supported PowerShell versions — close this and leave both as they are.
Related: #193, which existed because an inline comment in the same settings block described behavior the code did not have.
Raised during the independent review of #190, flagged as low confidence and needing knowledge outside this repository.
PowerShellBuild/build.properties.ps1describes the setting as an RFC 3161 timestamp server, and #190 carried that wording into the README:The value is passed to
Set-AuthenticodeSignature -TimestampServer. The reviewer notes that this parameter has historically used the legacy Authenticode timestamping protocol, not RFC 3161 — the distinction beingsigntool /tversussigntool /tr. If that is right, the comment names the wrong protocol and the README now repeats it.Why it is worth checking rather than assuming
http://timestamp.digicert.comanswers both protocols depending on what the client asks for, so a signed module verifies either way and nothing visibly breaks. That is exactly why a wrong label here could persist indefinitely.It also matters for anyone choosing a different timestamp server: several providers publish separate endpoints for legacy Authenticode and RFC 3161. A consumer who reads "RFC 3161" and configures an RFC 3161-only endpoint could find timestamping fails, with the documentation having pointed them there.
What would settle it
Sign something with
Set-AuthenticodeSignature -TimestampServer, then inspect the resulting signature for which timestamp structure it carries — an RFC 3161 signature has a1.3.6.1.4.1.311.3.3.1unauthenticated attribute, where legacy Authenticode uses a counter-signature.Get-AuthenticodeSignatureandsigntool verify /pa /vboth surface enough to tell them apart.Scope
This is inherited wording, not something #190 or #194 introduced. Fix the comment and the README row together, or — if the parameter does support RFC 3161 on supported PowerShell versions — close this and leave both as they are.
Related: #193, which existed because an inline comment in the same settings block described behavior the code did not have.