Re: [cabfpub] Questions regarding timestamping certificates

[Dimitris Zacharopoulos]

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-boun...@cabforum.org [mailto:public-boun...@cabforum.org] 
*En nombre de *Dimitris Zacharopoulos
*Enviado el:* jueves, 8 de septiembre de 2016 23:28
*Para:* Jody Cloutier; Ryan Sleevi
*CC:* bruce.mor...@entrust.com; public@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-boun...@cabforum.org
    <mailto:public-boun...@cabforum.org>
    [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan Sleevi
    *Sent:* Thursday, September 8, 2016 10:56 AM
    *To:* Dimitris Zacharopoulos <ji...@it.auth.gr>
    <mailto:ji...@it.auth.gr>
    *Cc:* bruce.mor...@entrust.com <mailto:bruce.mor...@entrust.com>;
    public@cabforum.org <mailto:public@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
    <ji...@it.auth.gr <mailto:ji...@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-boun...@cabforum.org
            <mailto:public-boun...@cabforum.org>
            [mailto:public-boun...@cabforum.org] *En nombre de
            *Dimitris Zacharopoulos
            *Enviado el:* jueves, 8 de septiembre de 2016 16:39
            *Para:* Bruce Morton
            *CC:* public@cabforum.org <mailto:public@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:ji...@it.auth.gr]
            *Sent:* Thursday, September 8, 2016 9:03 AM
            *To:* Bruce Morton <bruce.mor...@entrust.com>
            <mailto:bruce.mor...@entrust.com>; public@cabforum.org
            <mailto:public@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-boun...@cabforum.org
                <mailto:public-boun...@cabforum.org>
                [mailto:public-boun...@cabforum.org] *On Behalf Of
                *Dimitris Zacharopoulos
                *Sent:* Thursday, September 8, 2016 4:34 AM
                *To:* public@cabforum.org <mailto:public@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@cabforum.org <mailto:Public@cabforum.org>
        https://cabforum.org/mailman/listinfo/public


_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public