Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping
@Ian McMillan<mailto:ian...@microsoft.com> and concur with this approach for the CSWG, specifically adding a policy OID for TS services intended to be CS BR compliant. Thanks, Mike From: Public On Behalf Of Tim Hollebeek via Public Sent: Friday, April 30, 2021 9:52 AM To: Doug Beattie ; CABforum1 ; Rob Stradling ; Sebastian Schulz Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping This was the approach that was discussed in the CS WG. We were going to add a policy identifier that would help distinguish between timestamping services intended to be CS BR compliant, and generic timestamping services. -Tim From: Public mailto:public-boun...@cabforum.org>> On Behalf Of Doug Beattie via Public Sent: Thursday, April 29, 2021 10:53 AM To: Rob Stradling mailto:r...@sectigo.com>>; CABforum1 mailto:public@cabforum.org>>; Sebastian Schulz mailto:sebastian.sch...@globalsign.com>> Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping Maybe the use of Policy Identifiers is a good way to assert that your TSA service complies with the CABF Code signing BRs, but that does not preclude other uses? From: Public mailto:public-boun...@cabforum.org>> On Behalf Of Rob Stradling via Public Sent: Thursday, April 29, 2021 10:36 AM To: public@cabforum.org<mailto:public@cabforum.org>; Sebastian Schulz mailto:sebastian.sch...@globalsign.com>> Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping > I don't think the creation of another WG would be justified or useful Practically, that may well be the case, but I think it's right to arrive at that conclusion by going through this thought process rather than circumventing it. > I don't see an issue with the CS WG defining requirements for timestamping as > long as it's very clear that this is ONLY for timestamping used with > CodeSigning certificates so that is no violation of the scope of the WG. Policing "ONLY for timestamping used with CodeSigning certificates" seems like it would be hard. A timestamping server has no idea whether it's being asked to timestamp signed code or some other "datum" (to quote RFC3161). Sectigo's publicly-trusted RFC3161 timestamping service (and the timestamping certificates that it uses) is expected to be used in conjunction with both Code Signing and Document Signing. From: Public mailto:public-boun...@cabforum.org>> on behalf of Sebastian Schulz via Public mailto:public@cabforum.org>> Sent: 29 April 2021 11:03 To: public@cabforum.org<mailto:public@cabforum.org> mailto:public@cabforum.org>> Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I can't think of anything else except proprietary systems that use timestamping in for example Supply Chain Management and rely on CA issued timestamps due to the complexity of Enterprises building on-premise TSAs. When it comes to Adobe, they also trust other, non-qualified timestamps: "When a Time Stamping Authority is imposed or recommended to the signers by the Member, it must follow state of the art security policies and provide proper timestamps. The time-stamping practices and policies must be provided to Adobe and Adobe reserve the right to not accept the Time Stamping Authority." From AATL TR v2.0 EE3 I'm not generally opposed, but all in all I don't think the creation of another WG would be justified or useful, other major use cases of timestamping have their major stakeholders outside the CA/B Forum. I don't see an issue with the CS WG defining requirements for timestamping as long as it's very clear that this is ONLY for timestamping used with CodeSigning certificates so that is no violation of the scope of the WG. But I can see how opinions differ. Maybe an item to discuss on the next F2F? Best, Seb Sebastian Schulz Product Manager Client Certificates From: Public mailto:public-boun...@cabforum.org>> On Behalf Of Adriano Santoni via Public Sent: 29 April 2021 11:42 To: public@cabforum.org<mailto:public@cabforum.org> Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping Well, considering that Adobe is not currently a CABF member, I see no context wherein time stamping plays a role, other than code signing. Adobe already trusts qualified time stamping providers (according to EU regulations) based on the EU trust lists, in the context of Document Signing, and I am not aware that they may want to also trust time stamps based on different criteria. In theory, time stamping could be used to extend the validity of an S/MIME signature beyond the
Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping
This was the approach that was discussed in the CS WG. We were going to add a policy identifier that would help distinguish between timestamping services intended to be CS BR compliant, and generic timestamping services. -Tim From: Public On Behalf Of Doug Beattie via Public Sent: Thursday, April 29, 2021 10:53 AM To: Rob Stradling ; CABforum1 ; Sebastian Schulz Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping Maybe the use of Policy Identifiers is a good way to assert that your TSA service complies with the CABF Code signing BRs, but that does not preclude other uses? From: Public mailto:public-boun...@cabforum.org> > On Behalf Of Rob Stradling via Public Sent: Thursday, April 29, 2021 10:36 AM To: public@cabforum.org <mailto:public@cabforum.org> ; Sebastian Schulz mailto:sebastian.sch...@globalsign.com> > Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping > I don't think the creation of another WG would be justified or useful Practically, that may well be the case, but I think it's right to arrive at that conclusion by going through this thought process rather than circumventing it. > I don't see an issue with the CS WG defining requirements for timestamping as long as it's very clear that this is ONLY for timestamping used with CodeSigning certificates so that is no violation of the scope of the WG. Policing "ONLY for timestamping used with CodeSigning certificates" seems like it would be hard. A timestamping server has no idea whether it's being asked to timestamp signed code or some other "datum" (to quote RFC3161). Sectigo's publicly-trusted RFC3161 timestamping service (and the timestamping certificates that it uses) is expected to be used in conjunction with both Code Signing and Document Signing. _ From: Public mailto:public-boun...@cabforum.org> > on behalf of Sebastian Schulz via Public mailto:public@cabforum.org> > Sent: 29 April 2021 11:03 To: public@cabforum.org <mailto:public@cabforum.org> mailto:public@cabforum.org> > Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I can't think of anything else except proprietary systems that use timestamping in for example Supply Chain Management and rely on CA issued timestamps due to the complexity of Enterprises building on-premise TSAs. When it comes to Adobe, they also trust other, non-qualified timestamps: "When a Time Stamping Authority is imposed or recommended to the signers by the Member, it must follow state of the art security policies and provide proper timestamps. The time-stamping practices and policies must be provided to Adobe and Adobe reserve the right to not accept the Time Stamping Authority." From AATL TR v2.0 EE3 I'm not generally opposed, but all in all I don't think the creation of another WG would be justified or useful, other major use cases of timestamping have their major stakeholders outside the CA/B Forum. I don't see an issue with the CS WG defining requirements for timestamping as long as it's very clear that this is ONLY for timestamping used with CodeSigning certificates so that is no violation of the scope of the WG. But I can see how opinions differ. Maybe an item to discuss on the next F2F? Best, Seb Sebastian Schulz Product Manager Client Certificates From: Public mailto:public-boun...@cabforum.org> > On Behalf Of Adriano Santoni via Public Sent: 29 April 2021 11:42 To: public@cabforum.org <mailto:public@cabforum.org> Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping Well, considering that Adobe is not currently a CABF member, I see no context wherein time stamping plays a role, other than code signing. Adobe already trusts qualified time stamping providers (according to EU regulations) based on the EU trust lists, in the context of Document Signing, and I am not aware that they may want to also trust time stamps based on different criteria. In theory, time stamping could be used to extend the validity of an S/MIME signature beyond the signing certificate's expiration, but there is no S/MIME client supporting this, and no plans to support it in the future, so this is just theory. After all, S/MIME signatures are not meant for the long-term. Is there any other context that I am overlooking? Adriano Il 29/04/2021 11:07, Rob Stradling via Public ha scritto: Could it be argued, at least conceptually, that there should be a separate CABForum working group dedicated entirely to Time Stamping? After all, the Code Signing ecosystem doesn't have a monopoly on Time Stamping. For example, Adobe software uses Time Stamping in the
Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping
Maybe the use of Policy Identifiers is a good way to assert that your TSA service complies with the CABF Code signing BRs, but that does not preclude other uses? From: Public On Behalf Of Rob Stradling via Public Sent: Thursday, April 29, 2021 10:36 AM To: public@cabforum.org; Sebastian Schulz Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping > I don't think the creation of another WG would be justified or useful Practically, that may well be the case, but I think it's right to arrive at that conclusion by going through this thought process rather than circumventing it. > I don't see an issue with the CS WG defining requirements for timestamping as long as it's very clear that this is ONLY for timestamping used with CodeSigning certificates so that is no violation of the scope of the WG. Policing "ONLY for timestamping used with CodeSigning certificates" seems like it would be hard. A timestamping server has no idea whether it's being asked to timestamp signed code or some other "datum" (to quote RFC3161). Sectigo's publicly-trusted RFC3161 timestamping service (and the timestamping certificates that it uses) is expected to be used in conjunction with both Code Signing and Document Signing. _ From: Public on behalf of Sebastian Schulz via Public Sent: 29 April 2021 11:03 To: public@cabforum.org Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I can't think of anything else except proprietary systems that use timestamping in for example Supply Chain Management and rely on CA issued timestamps due to the complexity of Enterprises building on-premise TSAs. When it comes to Adobe, they also trust other, non-qualified timestamps: "When a Time Stamping Authority is imposed or recommended to the signers by the Member, it must follow state of the art security policies and provide proper timestamps. The time-stamping practices and policies must be provided to Adobe and Adobe reserve the right to not accept the Time Stamping Authority." From AATL TR v2.0 EE3 I'm not generally opposed, but all in all I don't think the creation of another WG would be justified or useful, other major use cases of timestamping have their major stakeholders outside the CA/B Forum. I don't see an issue with the CS WG defining requirements for timestamping as long as it's very clear that this is ONLY for timestamping used with CodeSigning certificates so that is no violation of the scope of the WG. But I can see how opinions differ. Maybe an item to discuss on the next F2F? Best, Seb Sebastian Schulz Product Manager Client Certificates From: Public On Behalf Of Adriano Santoni via Public Sent: 29 April 2021 11:42 To: public@cabforum.org Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping Well, considering that Adobe is not currently a CABF member, I see no context wherein time stamping plays a role, other than code signing. Adobe already trusts qualified time stamping providers (according to EU regulations) based on the EU trust lists, in the context of Document Signing, and I am not aware that they may want to also trust time stamps based on different criteria. In theory, time stamping could be used to extend the validity of an S/MIME signature beyond the signing certificate's expiration, but there is no S/MIME client supporting this, and no plans to support it in the future, so this is just theory. After all, S/MIME signatures are not meant for the long-term. Is there any other context that I am overlooking? Adriano Il 29/04/2021 11:07, Rob Stradling via Public ha scritto: Could it be argued, at least conceptually, that there should be a separate CABForum working group dedicated entirely to Time Stamping? After all, the Code Signing ecosystem doesn't have a monopoly on Time Stamping. For example, Adobe software uses Time Stamping in the context of Document Signing. If Adobe wanted to collaborate with CABForum members on Time Stamping certificate profiles, what (assuming Adobe had no interest in Code Signing) would be the best venue for that? (Please note: I'm not advocating any position here; I'm just thinking aloud). _ From: Cscwg-public <mailto:cscwg-public-boun...@cabforum.org> on behalf of Bruce Morton via Cscwg-public <mailto:cscwg-pub...@cabforum.org> Sent: 26 April 2021 14:18 To: Ben Wilson <mailto:bwil...@mozilla.com> ; cscwg-pub...@cabforum.org <mailto:cscwg-pub...@cabforum.org> <mailto:cscwg-pub...@cabforum.org> ; Dean Coclin <mailto:dean.coc...@digicert.com> ; CA/Browser Forum Public Discussion List <mailto:public@cabforum.org> Subject: Re: [Cscwg-public] [E
Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping
On Thu, Apr 29, 2021 at 10:36 AM Rob Stradling via Public < public@cabforum.org> wrote: > > I don’t think the creation of another WG would be justified or useful > > Practically, that may well be the case, but I think it's right to arrive > at that conclusion by going through this thought process rather than > circumventing it. > > > I don’t see an issue with the CS WG defining requirements for > timestamping as long as it’s very clear that this is ONLY for timestamping > used with CodeSigning certificates so that is no violation of the scope of > the WG. > > Policing "ONLY for timestamping used with CodeSigning certificates" seems > like it would be hard. A timestamping server has no idea whether it's > being asked to timestamp signed code or some other "datum" (to quote > RFC3161). > > Sectigo's publicly-trusted RFC3161 timestamping service (and the > timestamping certificates that it uses) is expected to be used in > conjunction with both Code Signing and Document Signing. > Indeed Rob, I think this gets to the heart of the concern. If the CSC WG is expecting that CAs will stand up separate EVCS Timestamping services, exclusively to be used for code signing (which cannot be enforced by the TSA), from a separate hierarchy, then at least we should be clear about that. The fundamental issue here is that the references to timestamping appear to be implementation/policy-specific to a particular implementor, rather than generalized regarding code signing. I appreciate the challenge here (code outliving the code signing certificate), and I can understand the rationale for wanting to address it, but it fundamentally feels like an attempt to scope an entirely unrelated service, which has no **defined** interaction, and which fundamentally is a matter of Relying Party policy. It seems the CSC WG should define how the CS *certificates* work, and the broader question about how code signing is conveyed (e.g. PKCS#7/CMS, ZIP files, bespoke vendor format - all of which are practically deployed today), or how those *certificates* are authenticated after their useful lifetime, is really a question for root program policies, in the absence of industry norms. And there could be opportunity here for something. However, if the CSC WG is determined to have this scoped within its charter, which is still something highlighted previously as problematic, then it really is and must simply be scoped to CS, and that's fundamentally saying a new, separate trust hierarchy "should" be established. We previously discussed, during the chartering of the S/MIME WG, exactly this issue (the need for a separate WG), due to the attempts to conflate S/MIME WG with document signing, since they both may choose to use legal identities in addition to or in lieu of technical identities (like an email address). This was the major blocker to getting the S/MIME charter approved, but we managed to eventually do so by making it clear document signing (and the related support services, including timestamping) are out of scope of S/MIME. ___ Public mailing list Public@cabforum.org https://lists.cabforum.org/mailman/listinfo/public
Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping
> I don’t think the creation of another WG would be justified or useful Practically, that may well be the case, but I think it's right to arrive at that conclusion by going through this thought process rather than circumventing it. > I don’t see an issue with the CS WG defining requirements for timestamping as > long as it’s very clear that this is ONLY for timestamping used with > CodeSigning certificates so that is no violation of the scope of the WG. Policing "ONLY for timestamping used with CodeSigning certificates" seems like it would be hard. A timestamping server has no idea whether it's being asked to timestamp signed code or some other "datum" (to quote RFC3161). Sectigo's publicly-trusted RFC3161 timestamping service (and the timestamping certificates that it uses) is expected to be used in conjunction with both Code Signing and Document Signing. From: Public on behalf of Sebastian Schulz via Public Sent: 29 April 2021 11:03 To: public@cabforum.org Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I can’t think of anything else except proprietary systems that use timestamping in for example Supply Chain Management and rely on CA issued timestamps due to the complexity of Enterprises building on-premise TSAs. When it comes to Adobe, they also trust other, non-qualified timestamps: “When a Time Stamping Authority is imposed or recommended to the signers by the Member, it must follow state of the art security policies and provide proper timestamps. The time-stamping practices and policies must be provided to Adobe and Adobe reserve the right to not accept the Time Stamping Authority.” From AATL TR v2.0 EE3 I’m not generally opposed, but all in all I don’t think the creation of another WG would be justified or useful, other major use cases of timestamping have their major stakeholders outside the CA/B Forum. I don’t see an issue with the CS WG defining requirements for timestamping as long as it’s very clear that this is ONLY for timestamping used with CodeSigning certificates so that is no violation of the scope of the WG. But I can see how opinions differ. Maybe an item to discuss on the next F2F? Best, Seb Sebastian Schulz Product Manager Client Certificates From: Public On Behalf Of Adriano Santoni via Public Sent: 29 April 2021 11:42 To: public@cabforum.org Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping Well, considering that Adobe is not currently a CABF member, I see no context wherein time stamping plays a role, other than code signing. Adobe already trusts qualified time stamping providers (according to EU regulations) based on the EU trust lists, in the context of Document Signing, and I am not aware that they may want to also trust time stamps based on different criteria. In theory, time stamping could be used to extend the validity of an S/MIME signature beyond the signing certificate's expiration, but there is no S/MIME client supporting this, and no plans to support it in the future, so this is just theory. After all, S/MIME signatures are not meant for the long-term. Is there any other context that I am overlooking? Adriano Il 29/04/2021 11:07, Rob Stradling via Public ha scritto: Could it be argued, at least conceptually, that there should be a separate CABForum working group dedicated entirely to Time Stamping? After all, the Code Signing ecosystem doesn't have a monopoly on Time Stamping. For example, Adobe software uses Time Stamping in the context of Document Signing. If Adobe wanted to collaborate with CABForum members on Time Stamping certificate profiles, what (assuming Adobe had no interest in Code Signing) would be the best venue for that? (Please note: I'm not advocating any position here; I'm just thinking aloud). From: Cscwg-public <mailto:cscwg-public-boun...@cabforum.org> on behalf of Bruce Morton via Cscwg-public <mailto:cscwg-pub...@cabforum.org> Sent: 26 April 2021 14:18 To: Ben Wilson <mailto:bwil...@mozilla.com>; cscwg-pub...@cabforum.org<mailto:cscwg-pub...@cabforum.org> <mailto:cscwg-pub...@cabforum.org>; Dean Coclin <mailto:dean.coc...@digicert.com>; CA/Browser Forum Public Discussion List <mailto:public@cabforum.org> Subject: Re: [Cscwg-public] [EXTERNAL] Re: [cabfpub] Code signing and Time stamping CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. To follow up, the CSCWG charter includes the following documents: a. EV Code Signing Guidelines, v. 1.4 an
Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping
I can't think of anything else except proprietary systems that use timestamping in for example Supply Chain Management and rely on CA issued timestamps due to the complexity of Enterprises building on-premise TSAs. When it comes to Adobe, they also trust other, non-qualified timestamps: "When a Time Stamping Authority is imposed or recommended to the signers by the Member, it must follow state of the art security policies and provide proper timestamps. The time-stamping practices and policies must be provided to Adobe and Adobe reserve the right to not accept the Time Stamping Authority." From AATL TR v2.0 EE3 I'm not generally opposed, but all in all I don't think the creation of another WG would be justified or useful, other major use cases of timestamping have their major stakeholders outside the CA/B Forum. I don't see an issue with the CS WG defining requirements for timestamping as long as it's very clear that this is ONLY for timestamping used with CodeSigning certificates so that is no violation of the scope of the WG. But I can see how opinions differ. Maybe an item to discuss on the next F2F? Best, Seb Sebastian Schulz Product Manager Client Certificates From: Public On Behalf Of Adriano Santoni via Public Sent: 29 April 2021 11:42 To: public@cabforum.org Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping Well, considering that Adobe is not currently a CABF member, I see no context wherein time stamping plays a role, other than code signing. Adobe already trusts qualified time stamping providers (according to EU regulations) based on the EU trust lists, in the context of Document Signing, and I am not aware that they may want to also trust time stamps based on different criteria. In theory, time stamping could be used to extend the validity of an S/MIME signature beyond the signing certificate's expiration, but there is no S/MIME client supporting this, and no plans to support it in the future, so this is just theory. After all, S/MIME signatures are not meant for the long-term. Is there any other context that I am overlooking? Adriano Il 29/04/2021 11:07, Rob Stradling via Public ha scritto: Could it be argued, at least conceptually, that there should be a separate CABForum working group dedicated entirely to Time Stamping? After all, the Code Signing ecosystem doesn't have a monopoly on Time Stamping. For example, Adobe software uses Time Stamping in the context of Document Signing. If Adobe wanted to collaborate with CABForum members on Time Stamping certificate profiles, what (assuming Adobe had no interest in Code Signing) would be the best venue for that? (Please note: I'm not advocating any position here; I'm just thinking aloud). _ From: Cscwg-public <mailto:cscwg-public-boun...@cabforum.org> on behalf of Bruce Morton via Cscwg-public <mailto:cscwg-pub...@cabforum.org> Sent: 26 April 2021 14:18 To: Ben Wilson <mailto:bwil...@mozilla.com> ; cscwg-pub...@cabforum.org <mailto:cscwg-pub...@cabforum.org> <mailto:cscwg-pub...@cabforum.org> ; Dean Coclin <mailto:dean.coc...@digicert.com> ; CA/Browser Forum Public Discussion List <mailto:public@cabforum.org> Subject: Re: [Cscwg-public] [EXTERNAL] Re: [cabfpub] Code signing and Time stamping CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. To follow up, the CSCWG charter includes the following documents: a. EV Code Signing Guidelines, v. 1.4 and subsequent versions b. Version 1.0 Draft of November 19, 2015, Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates (subject to the CSCWG making a written finding that the provenance of such document is sufficiently covered by the Forum's IPR Policy) The documents define requirements or reference: timestamp authority (TSA), timestamps, timestamp implementation method, timestamp certificate, timestamp signed objects, TSA logging, and timestamp key protection. The documents also define the certificate profiles for timestamp root, timestamp subordinate CA and timestamp authority. As such, the CSCWG has considered it is in scope to manage these documents and the requirements associated to allow timestamp signatures with code signed using certificates conforming to the CSBRs. The CSBRs also state, "CAs complying with these Requirements MAY also assert the reserved policy OIDs in such Certificates." The reserved policy OIDs reference those required for Non-EV and EV code signing certificates. The CSBRs do not reference an OID for a timestamp certificate, since the OID has not been reserved. It is also considered appropriate to use all applicable reserved certificate policy OIDs as we consider deploying dedicated PKI hierarchies to support code signing. As s
Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping
Well, considering that Adobe is not currently a CABF member, I see no
context wherein time stamping plays a role, other than code signing.
Adobe already trusts qualified time stamping providers (according to EU
regulations) based on the EU trust lists, in the context of Document
Signing, and I am not aware that they may want to also trust time stamps
based on different criteria.
In theory, time stamping could be used to extend the validity of an
S/MIME signature beyond the signing certificate's expiration, but there
is no S/MIME client supporting this, and no plans to support it in the
future, so this is just theory. After all, S/MIME signatures are not
meant for the long-term.
Is there any other context that I am overlooking?
Adriano
Il 29/04/2021 11:07, Rob Stradling via Public ha scritto:
Could it be argued, at least conceptually, that there should be a
separate CABForum working group dedicated entirely to Time Stamping?
After all, the Code Signing ecosystem doesn't have a monopoly on Time
Stamping. For example, Adobe software uses Time Stamping in the
context of Document Signing. If Adobe wanted to collaborate with
CABForum members on Time Stamping certificate profiles, what (assuming
Adobe had no interest in Code Signing) would be the best venue for that?
(Please note: I'm not advocating any position here; I'm just thinking
aloud).
*From:* Cscwg-public on behalf of
Bruce Morton via Cscwg-public
*Sent:* 26 April 2021 14:18
*To:* Ben Wilson ; cscwg-pub...@cabforum.org
; Dean Coclin ;
CA/Browser Forum Public Discussion List
*Subject:* Re: [Cscwg-public] [EXTERNAL] Re: [cabfpub] Code signing
and Time stamping
CAUTION: This email originated from outside of the organization. Do
not click links or open attachments unless you recognize the sender
and know the content is safe.
To follow up, the CSCWG charter includes the following documents:
a. EV Code Signing Guidelines, v. 1.4 and subsequent versions
b. Version 1.0 Draft of November 19, 2015, Baseline Requirements for
the Issuance and Management of Publicly-Trusted Code Signing
Certificates (subject to the CSCWG making a written finding that the
provenance of such document is sufficiently covered by the Forum’s IPR
Policy)
The documents define requirements or reference: timestamp authority
(TSA), timestamps, timestamp implementation method, timestamp
certificate, timestamp signed objects, TSA logging, and timestamp key
protection. The documents also define the certificate profiles for
timestamp root, timestamp subordinate CA and timestamp authority. As
such, the CSCWG has considered it is in scope to manage these
documents and the requirements associated to allow timestamp
signatures with code signed using certificates conforming to the CSBRs.
The CSBRs also state, “CAs complying with these Requirements MAY also
assert the reserved policy OIDs in such Certificates.” The reserved
policy OIDs reference those required for Non-EV and EV code signing
certificates. The CSBRs do not reference an OID for a timestamp
certificate, since the OID has not been reserved. It is also
considered appropriate to use all applicable reserved certificate
policy OIDs as we consider deploying dedicated PKI hierarchies to
support code signing.
As such, the CSCWG plans to add the following reserved certificate
policy OID to the CSBRs, which may be included in a timestamp
certificate, which meets the requirements of the CSBRs:
{joint-iso-itu-t(2) international-organizations(23)
ca-browser-forum(140) certificate-policies(1)
code-signing-requirements(4) timestamping(2)} (2.23.140.1.4.2)
Bruce.
*From:* Cscwg-public *On Behalf Of
* Ben Wilson via Cscwg-public
*Sent:* Tuesday, April 20, 2021 12:09 PM
*To:* Dean Coclin ; CA/Browser Forum Public
Discussion List
*Cc:* cscwg-pub...@cabforum.org
*Subject:* [EXTERNAL] Re: [Cscwg-public] [cabfpub] Code signing and
Time stamping
WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know
the content is safe.
Just a few thoughts to move this conversation forward, and speaking as
a CSCWG interested party and not to advocate any position of Mozilla,
I think the answer depends on how strict or flexible the CABF wants to
be as an organization when it comes to interpreting the scope of a
working group charter.
It seems that the mention of time stamping in a code signing work
product would be allowed even under a strict interpretation. While
creating standards for issuing and managing time stamping certificates
would certainly be out of scope with a flexible interpretation.
The Scope in the Charter does not expressly include or exclude the
assignment of a time stamping OID for time stamping certificates.
https://cabforum.org/2019/03/26
Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping
Could it be argued, at least conceptually, that there should be a separate
CABForum working group dedicated entirely to Time Stamping? After all, the
Code Signing ecosystem doesn't have a monopoly on Time Stamping. For example,
Adobe software uses Time Stamping in the context of Document Signing. If Adobe
wanted to collaborate with CABForum members on Time Stamping certificate
profiles, what (assuming Adobe had no interest in Code Signing) would be the
best venue for that?
(Please note: I'm not advocating any position here; I'm just thinking aloud).
From: Cscwg-public on behalf of Bruce
Morton via Cscwg-public
Sent: 26 April 2021 14:18
To: Ben Wilson ; cscwg-pub...@cabforum.org
; Dean Coclin ; CA/Browser
Forum Public Discussion List
Subject: Re: [Cscwg-public] [EXTERNAL] Re: [cabfpub] Code signing and Time
stamping
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
To follow up, the CSCWG charter includes the following documents:
a. EV Code Signing Guidelines, v. 1.4 and subsequent versions
b. Version 1.0 Draft of November 19, 2015, Baseline Requirements for the
Issuance and Management of Publicly-Trusted Code Signing Certificates (subject
to the CSCWG making a written finding that the provenance of such document is
sufficiently covered by the Forum’s IPR Policy)
The documents define requirements or reference: timestamp authority (TSA),
timestamps, timestamp implementation method, timestamp certificate, timestamp
signed objects, TSA logging, and timestamp key protection. The documents also
define the certificate profiles for timestamp root, timestamp subordinate CA
and timestamp authority. As such, the CSCWG has considered it is in scope to
manage these documents and the requirements associated to allow timestamp
signatures with code signed using certificates conforming to the CSBRs.
The CSBRs also state, “CAs complying with these Requirements MAY also assert
the reserved policy OIDs in such Certificates.” The reserved policy OIDs
reference those required for Non-EV and EV code signing certificates. The CSBRs
do not reference an OID for a timestamp certificate, since the OID has not been
reserved. It is also considered appropriate to use all applicable reserved
certificate policy OIDs as we consider deploying dedicated PKI hierarchies to
support code signing.
As such, the CSCWG plans to add the following reserved certificate policy OID
to the CSBRs, which may be included in a timestamp certificate, which meets the
requirements of the CSBRs:
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140)
certificate-policies(1) code-signing-requirements(4) timestamping(2)}
(2.23.140.1.4.2)
Bruce.
From: Cscwg-public On Behalf Of Ben Wilson
via Cscwg-public
Sent: Tuesday, April 20, 2021 12:09 PM
To: Dean Coclin ; CA/Browser Forum Public Discussion
List
Cc: cscwg-pub...@cabforum.org
Subject: [EXTERNAL] Re: [Cscwg-public] [cabfpub] Code signing and Time stamping
WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the
content is safe.
Just a few thoughts to move this conversation forward, and speaking as a CSCWG
interested party and not to advocate any position of Mozilla, I think the
answer depends on how strict or flexible the CABF wants to be as an
organization when it comes to interpreting the scope of a working group charter.
It seems that the mention of time stamping in a code signing work product would
be allowed even under a strict interpretation. While creating standards for
issuing and managing time stamping certificates would certainly be out of scope
with a flexible interpretation.
The Scope in the Charter does not expressly include or exclude the assignment
of a time stamping OID for time stamping certificates.
https://cabforum.org/2019/03/26/code-signing-certificate-wg-charter/#1-Scope<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fcabforum.org%2F2019%2F03%2F26%2Fcode-signing-certificate-wg-charter%2F*1-Scope__%3BIw!!FJ-Y8qCqXTj2!KO_2DRjCLlG3XphTaFOKt3DIbyewuzdXb3w04DZftMjNQ74YZEHuLmO13bB-Y764wXA%24=04%7C01%7C%7C427335acc5eb4722c34408d908b5c6ea%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637550399087360682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=On%2FYLtGShUwaWS%2FOYXT0aqM7HYc7PBpRLxglLEMhWN0%3D=0>
Included in the scope is "Version 1.0 Draft of November 19, 2015, Baseline
Requirements for the Issuance and Management of Publicly-Trusted Code Signing
Certificates (subject to the CSCWG making a written finding that the provenance
of such document is sufficiently covered by the Forum’s IPR Policy)." Time
stampi
