[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

[Steve Roylance]

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?)

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.

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