[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

[Ryan Sleevi]

On Thu, Aug 1, 2013 at 8:00 AM, Steve Roylance
<steve.roylance at globalsign.com> wrote:
> Dear all,
>
> I think it's fair to say that there is simply a lack of common
> understanding concerning key and certificate lifecycle management.
> Please note that CABForum has tried to define some of the terms in the
> past to help, but they may have hindered as they were for EV, where
> duration was already agreed, so there were no instances of legacy
> certificates to cause confusion.
>
>
> >From EV 1.4
>
> * EV Certificate Renewal: The process whereby an Applicant who has a valid
> unexpired and non-revoked EV Certificate makes an application, to the CA
> that issued the original certificate, for a newly issued EV Certificate
> for the same organizational name and Domain Name prior to the expiration
> of the Applicant's existing EV Certificate but with a new 'valid to' date
> beyond the expiry of the current EV Certificate.
>
> * EV Certificate Reissuance: The process whereby an Applicant who has a
> valid unexpired and non-revoked EV Certificate makes an application, to
> the CA that issued the original certificate, for a newly issued EV
> Certificate for the same organizational name and Domain Name prior to the
> expiration of the Applicant's existing EV Certificate but with a 'valid
> to' date that matches that of the current EV Certificate.
>
>
> As it stands GlobalSign, Like Symantec does not have a dog in the duration
> race as we do not have any certificates longer than the current 60 months,
> so any re-issuance would not break the BR rules, however, in 2015 when the
> industry flips to a 39 month max I believe from my engineering team we
> would have had a similar issue to others, again due to the existing
> contract precedence understanding that others have mentioned.
>
> Once we all solve our combined general understanding on this point we need
> to ensure we also cover the other areas the duration subject raises.
> Namely:-
>
> 1) If the intention of duration is to limit the useable duration of the
> key then the current BRs do not achieve this as they talk about
> certificates meaning a CA that uses any sort of "renew" operation would
> simply sign the same key again so what's the difference here?  Two back to
> back 5 year certificates with the same key is ostensibly the same as one
> ten year one if you are trying to crunch the key.
> 2) Even if each CA were to look at their own database of issued
> certificates to prevent renewal after a certain period of time, any
> customer is open to moving to another CA and using the same CSR so we are
> again back to 5+5=10.  (Maybe CT would help here?)

Steve,

Thanks for highlighting these definitions and continuing the discussion.

I would suggest that there are several reasons for the date policies,
beyond key lifecycle:
1) Ensuring that the information presented in the certificate is
accurate and regularly vetted.
2) Ensuring that even in the absence of hard-fail revocation checking
(a point that things like mustStaple are arguably helping to actually
get to the point of actually being practical on the Internet), that
certificates cannot live on 'in perpetuity'
3) Ensuring that the certificates themselves reflect the best security
practices at the time of issuance (eg: minimally, the BRs), but that
they also recognize that the threat landscape changes, and thus are
periodically reviewed and adjusted to reflect best current practice.

>
> I suggest a discussion in the September Face to Face with homework for
> each CA to bring along their lifecycle charts so we can all exit with
> agreement on our terms.

While I appreciate the suggestion, I feel that postponing this
discussion for over a month will not exactly be prudent. Though this
matter seems to require much more discussion - which is the whole
point of our raising this in the first place - I would like to make
sure we're not just punting on the issue.

Given that I suspect many CAs will have differing definitions, I would
almost suggest it would be more prudent to continue the discussions on
the public list here, so that we can see if there is a convergence
ahead of the F2F.

Cheers,
Ryan

>
> Finally there's one other issue which rekey causes if certificates are
> keyed with a NotBefore date in the past.  Whilst for SSL this doesn't
> present a problem, for document signing and signing for individuals it
> does, as the statement made by the CA with respect to the status of the
> key
> at the point of issuance actually makes no sense and any previous CRLs
> from the past can be used in combination with the certificate at a
> modified signing date to make false statements.
>
> Finally, Finally I'm led to believe that adding serial numbers to CRLs
> with expiry dates in the past (think prior to malware being signed) may
> also be problematic.
>
> All these lead me to suspect that CABForum members continue to work
> together to find a level playing field where everyone follows the rules,
> the rules make sense and everyone remains protected.
>
> Let's move forwards one step at a time.
>
> Steve


>
>
> On 01/08/2013 14:56, "Jeremy Rowley" <jeremy.rowley at digicert.com> wrote:
>
>>Agreed.
>>
>>-----Original Message-----
>>From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
>>Behalf Of Gervase Markham
>>Sent: Thursday, August 01, 2013 7:46 AM
>>To: richard.smith at comodo.com
>>Cc: public at cabforum.org
>>Subject: Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline
>>Requirements
>>
>>On 01/08/13 14:43, Rich Smith wrote:
>>> The subject we're currently discussing was not spelled out clearly at
>>> all, and my recollection regarding the discussions around validity
>>> period was that it was well understood that there were long lived
>>> certificates out there, and that they would be allowed to live out their
>>life-cycles.
>>
>>There's a difference between allowing a cert to live out its life cycle
>>because it's unreasonable to ring up a customer and tell them to make a
>>change to their running system, and the situation where they are already
>>making that change and you have an opportunity to issue them a replacement
>>cert which is BR-compliant.
>>
>>> Certificate duration has the potential to effect a much larger number
>>> of customers and I don't think those of us who have issued them in the
>>> past would have agreed to specific terms in the BR stating that we
>>> would have to revoke them, absent any other security vulnerability,
>>> had that been clearly stated from the outset.
>>
>>This is not a request for revocation, it's a request that newly-minted
>>certificates conform to the BRs, even if the cert they are replacing did
>>not.
>>
>>Gerv
>>_______________________________________________
>>Public mailing list
>>Public at cabforum.org
>>https://cabforum.org/mailman/listinfo/public
>>
>>_______________________________________________
>>Public mailing list
>>Public at cabforum.org
>>https://cabforum.org/mailman/listinfo/public
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public