[cabfpub] Questions regarding timestamping certificates
Dimitris Zacharopoulos
jimmy at it.auth.gr
Sun Sep 11 05:57:33 UTC 2016
On 9/9/2016 10:13 πμ, Inigo Barreira wrote:
>
> In the ETSI standards this has been “divided” to distinguish between a
> certificate and a timestamp token and/or unit, considering them
> “differently” (in fact there are different standards for each, 411-x
> is for issuing certificates and 421 is for timestamping policies).
>
> Basically the CABF docs are for issuing SSL certs with additional
> “features” that affect the whole ecosystem, but always based on this
> type of certificates. There´s also the code signing which is not of
> “such” importance because of the numbers and platforms in which the
> TSA is mentioned.
>
> So, if we´re reforming the fórum, there are some standards out there
> to be used, … instead of updating/modifying the BRs or EVGs, I´d
> rather go for an independent document, like in ETSI, in where all the
> matters related to timestamping be addressed in one document and not
> surfing or digging in many of them. IMHO, I´d be easier to mantain,
> address, make Standards bodies life easier, etc. But the issue will
> remain if some software vendors still request it and TSPs will be
> “forced” to do so in order to have their services “recognized” in that
> software, though maybe is a matter of time
>
> Regards
>
I proposed to update/modify the BRs because -as I clearly stated- it
involves Root Certificates that also down the chain issue SSL
Certificates. So, I believe we should try to eliminate this "open to
interpretations" clause and either allow or explicitly deny the direct
issuance of a timestamping end-entity certificate from a Root.
I'd like to discuss this on the next call and see if there is interest
to draft a ballot. In case it is decided that it should not be allowed,
I am sure there would be a fairly proper effective date for CAs to comply.
Best regards,
Dimitris.
> *De:*public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> *En nombre de *Dimitris Zacharopoulos
> *Enviado el:* jueves, 8 de septiembre de 2016 23:28
> *Para:* Jody Cloutier; Ryan Sleevi
> *CC:* Bruce.Morton at entrust.com; public at cabforum.org
> *Asunto:* Re: [cabfpub] Questions regarding timestamping certificates
>
>
> Thanks everyone for your input. To be honest, I didn't expect this to
> be a controversial issue since timestamping has been around for many
> years.
>
> I think Microsoft's reference c(5) is probably aligned with the BRs
> (6.1.7). However, technically speaking, an OCSP responder certificate
> is also an end-entity certificate but it is specifically allowed in
> the BRs (same section).
>
> Currently, as written, section 6.1.7 of the BRs numbered item 3,
> allows the Root Key to be used to sign "Certificates for
> infrastructure purposes (e.g. administrative role certificates,
> internal CA operational device certificates, and OCSP Response
> verification Certificates)".
>
> I think that we can all agree that this exception is kind of vague and
> should probably be narrowed down to a smaller, more specific set. Of
> course, a TimeStamping Certificate is not your everyday "Subscriber"
> Certificate and could be defined by some CAs as a "Certificate for
> infrastructure purposes", since it is usually operated by the CA/TSP
> and not some other non-TSP entity as it works with SSL, S/MIME, Code
> Signing Certificates. The ETSI EN 319 421 and the minimum requirements
> for Code Signing document, have very strict controls on how to issue
> and maintain a Timestamping Certificate that minimize the risk (from a
> risk management perspective) compared to other end-entity (SSL, S/MIME
> and CodeSigning) Certificates. Also, the CRL issuance frequency for
> the status of Timestamping Certificates is aligned with the frequency
> of the status of Subordinate CA Certificates so they are treated
> differently.
>
> We could ballot this and change 6.1.7(3) to either specifically allow
> or disallow timestamping end-entity certificates to be issued directly
> from a Root and -obviously- if the majority votes that timestamping
> certificates must not be allowed to be issued directly from Root
> Certificates, introduce a proper effective date for enforcing this policy.
>
>
> Dimitris.
>
> On 8/9/2016 9:02 μμ, Jody Cloutier wrote:
>
> Thanks, Ryan.
>
> Dimitris, See http://aka.ms/ c(5). “The CA must not use the root
> certificate to issue end-entity certificates.”.
>
> J
>
> *From:*public-bounces at cabforum.org
> <mailto:public-bounces at cabforum.org>
> [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan Sleevi
> *Sent:* Thursday, September 8, 2016 10:56 AM
> *To:* Dimitris Zacharopoulos <jimmy at it.auth.gr>
> <mailto:jimmy at it.auth.gr>
> *Cc:* Bruce.Morton at entrust.com <mailto:Bruce.Morton at entrust.com>;
> public at cabforum.org <mailto:public at cabforum.org>
> *Subject:* Re: [cabfpub] Questions regarding timestamping certificates
>
> Dimitris,
>
> Thanks for raising this. I'd be especially curious to get Jody's
> take, and I'd suggest you see if https://aka.ms/rootcert has
> anything to say on this matter.
>
> As it stands, I'm loathe to suggest that it would be acceptable,
> simply because of EKU, to suggest that direct root issuance is
> safe or acceptable. As you know, the sub-CA approach ensures a
> proper risk-limiting scope; that is, we want to ensure the sub-CA
> is created "safely", and thus not have to worry about anything
> that the sub-CA itself signs.
>
> Ultimately, it's about risk management. Let's assume we said that
> the mere presence of the id-kp-timeStamping EKU was sufficient to
> make the "EE issued by Root" safe, and thus out of scope of the
> BRs. Would it be acceptable for that Root to sign the EE with
> SHA-1, since it's Out of Scope? Obviously, no - as the risk with
> SHA-1 would be an attacker could collide with an
> attacker-controlled cert that wasn't id-kp-timeStamping limited.
> However, if it was an id-kp-timeStamping sub-CA, then that sub-CA
> could issue however many certificates were desired, and the risk
> of any SHA-1 collisions under that sub-CA would be limited to
> affecting the timestamping services, thus minimizing the risk to
> most (but not all) browser vendors.
>
> Similarly, if we accept that it was sufficient, we'd run the risk
> that the Root's CRL could potentially grow. That is, imagine the
> impact to clients if there was 1 TLS sub-CA, and 100,000
> id-kp-whatever EE certs, and the 100,000 certs needed to be
> revoked. TLS clients wanting to check if the sub-CA was revoked
> would also need to download the CRL with the 100,000 other
> revocations, potentially impacting performance.
>
> We unquestionably know that the root itself needs to comply with
> the BRs, and so I believe the MUST NOT absolutely applies,
> regardless of what you're signing. If you issue a sub-CA with
> id-kp-timestamping from this root, then the goal is that the
> sub-CA's profile fits the acceptable set (of what the Root is
> allowed to sign; in particular, the choice of algorithm), the
> Root's CRL matches the CRL policies, but that the sub-CA itself is
> not bound by the BRs in what it issues or how it operates.
>
> I agree, this is not entirely obvious from the BRs, and is the
> long-standing scope issue (both of the BRs and the Forum), and
> hopefully, as we work towards resolving the Forum structure some,
> we can revise the BRs as necessary to make it clearer the scope of
> common matters, and what elements are out of scope.
>
> In this regard, I appreciate the structured approach that ETSI has
> taken, in that it makes a clearer distinction between policies and
> profiles. We want the Root to have a known set of policies, and
> issue certificates with a bounded set of profiles. However, some
> subordinate certificates may follow one set of policies (and issue
> with one set of profiles), while another subordinate certificate
> may follow a different set of policies and profiles. That is, we
> could assume the Root has a uniform set of Policies (that are the
> minimum safety net for the *union* of all subrodinates; aka the
> most restrictive policy wins), while Subordinates may only have to
> comply with one set of policies (such as TLS or code signing), if
> the risk is constrained to a specific set of profiles (such as
> id-kp-serverAuth vs id-kp-codeSigning)
>
> Does that help offer a 'vendor' perspective?
>
> On Thu, Sep 8, 2016 at 9:15 AM, Dimitris Zacharopoulos
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>
>
> Yes, I was wondering if this is in fact allowed by the BRs. In
> a case where you have a Root that doesn't have the SSL
> trust-bits, I am sure you can do that. But what happens if
> your Root is included in the browsers with the SSL trust-bits set?
>
> Dimitris.
>
>
>
>
> On 8/9/2016 6:14 μμ, Inigo Barreira wrote:
>
> Well, it depends. There are some software vendors that
> “request” to have the TSA signed by a known certificate,
> and as they only trust on root certificate, usually to get
> your timestamps “recognized” you have to sign the TSA with
> the CA root cert just in case.
>
> *De:*public-bounces at cabforum.org
> <mailto:public-bounces at cabforum.org>
> [mailto:public-bounces at cabforum.org] *En nombre de
> *Dimitris Zacharopoulos
> *Enviado el:* jueves, 8 de septiembre de 2016 16:39
> *Para:* Bruce Morton
> *CC:* public at cabforum.org <mailto:public at cabforum.org>
> *Asunto:* Re: [cabfpub] Questions regarding timestamping
> certificates
>
> On 8/9/2016 4:59 μμ, Bruce Morton wrote:
>
> Hi Dimitris,
>
> I don’t think that the spirit of BR 6.1.7 would be for
> a root CA to issue a certificate for a TSA. Also, the
> members of the Code Signing Working Group have
> recommended that there be a separate CA for issuing
> time-stamping certificates which is defined in
> Appendix B (4) of the Minimum Requirements for Code
> Signing certificates.
>
>
> That was my initial reading too and thank you for
> confirming. If others think that's not the case, please
> let us know.
>
>
> You may want to get feedback directly from the vendor of
> the client software which will validate the time-stamp
> signatures.
>
>
> I don't think that will be necessary because if the
> standards require a 2 level certificate chain
> verification, the client software must support it :)
>
>
> Best regards,
> Dimitris.
>
>
> Bruce.
>
> *From:*Dimitris Zacharopoulos [mailto:jimmy at it.auth.gr]
> *Sent:* Thursday, September 8, 2016 9:03 AM
> *To:* Bruce Morton <Bruce.Morton at entrust.com>
> <mailto:Bruce.Morton at entrust.com>; public at cabforum.org
> <mailto:public at cabforum.org>
> *Subject:* Re: [cabfpub] Questions regarding timestamping
> certificates
>
> On 8/9/2016 3:07 μμ, Bruce Morton wrote:
>
> Hi Dimitris,
>
> I think the best document to use for Time-stamping
> Authority is the Minimum Requirements for Code Signing
> certificates, see
> https://casecurity.org/wp-content/uploads/2016/07/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf.
>
> Thanks, Bruce.
>
>
> Thank you Bruce, you helped me find answers related to my
> second question. I am not 100% sure if it answers my first
> question. The minimum requirements for code signing
> document, describes a scenario where there are explicit
> Subordinate CA Certificates for TimeStamping but there is
> no requirement that forbids end-entity certificates to be
> issued directly from the Root (at least not one I could
> spot straight away).
>
> I guess my 1st question is more focused on what is allowed
> under the currently approved CA/B Forum Baseline Requirements.
>
>
> Best regards,
> Dimitris.
>
>
>
>
> *From:*public-bounces at cabforum.org
> <mailto:public-bounces at cabforum.org>
> [mailto:public-bounces at cabforum.org] *On Behalf Of
> *Dimitris Zacharopoulos
> *Sent:* Thursday, September 8, 2016 4:34 AM
> *To:* public at cabforum.org <mailto:public at cabforum.org>
> *Subject:* [cabfpub] Questions regarding timestamping
> certificates
>
> Hello everyone,
>
> We are setting up a new Timestamping Authority and we
> are looking for specific rules that apply to
> certificates and subCA Certificates related to
> timestamping. While reading various standards and the
> CA/B Forum documents, and after looking at various
> existing implementations of publicly-trusted CAs, I
> have some questions and would appreciate any feedback
> from the forum. Although the BRs apply to SSL
> certificates, some Root Certificates might be used for
> both SSL and timestamping services. So the questions
> that follow, apply to CAs that use the same Root
> Certificate for both SSL and timestamping purposes. Of
> course, the EV CodeSigning requirements also define
> some rules for "EV Timestamp Authorities".
>
> 1. Section 6.1.7 of the Baseline Requirements states
> that the Root CA Private Keys MUST NOT be used to
> sign end-entity certificates with some exceptions.
> This exception list does not specifically mention
> end-entity certificates with EKU
> id-kp-timeStamping. Are Root CAs allowed to
> directly issue end-entity certificates for
> timestamping authorities (end-entity certificates
> with EKU only id-kp-timeStamping)?
> 2. Section 4.9.7 describes the CRL issuance frequency
> for Subscriber and Subordinate CA Certificates. If
> there is a Subordinate CA Certificate constrained
> with EKU id-kp-timeStamping, is an end-entity
> certificate (with only id-kp-timeStamping) issued
> from that subCA considered a "Subscriber"
> Certificate? Should this subCA issue CRLs every 7
> days or every 12 months? My understanding
> (according to section 1.1 of the BRs) is that the
> end-entity certificates from that subCA are not
> required to comply with the CA/B Forum BRs. This
> should allow the CA to choose the CRL issuance
> (from that restricted subCA), to exceed the 7-day
> requirement.
>
>
> Thank you in advance.
>
>
> Dimitris Zacharopoulos.
>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160911/d6b352f6/attachment-0003.html>
More information about the Public
mailing list