[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

Mon Aug 5 13:14:25 UTC 2013

Steve and Wayne,
I am also in full support of Wayne's additions to my wording, and would
happily act as either the sponsor or an endorser, but before we rush this
into a ballot, I'd like to consider this point from Ryan:
"I just hope and expect CAs are fully aware and considering the implications
of the language - as it appears they may not have when negotiating the BRs -
and how this might affect other provisions: domain validation, subject
information, EKUs, revocation responders, serial numbers/entropy, etc. It's
entirely possible that such 'reissued' certificates will differ much more
significantly than just flipping some dates and/or a key."

I am not the subject expert in the technical aspects, but perhaps we should
all have our technical experts take a quick look at any other possible
issues which may come up on a re-issuance/re-key of a pre-BR cert so that if
there is anything else that we may want to discuss along with this we tackle
it all at the same time.  I am not proposing at all that we make any kind of
allowance for something like internal names, or anything else that has real
security implecations.  I would be absolutely against carving out any kind
of exception to the BRs for something with real and significant security
concerns, but before we move this forward perhaps we should take a short
amount of time to run through all aspects of the BRs and ask ourselves if
there are any other issues which are both very low security concern vs. the
existing certificate AND may cause us as CAs significant customer relations
problems if we modify it in a re-issuance.  I strongly suspect that there
are no other such issues, but I think at this point we can agree that we did
not give the re-issuance/re-key questions enough consideration when drafting
the BRs and we should probably do so now so that we hash out any and all
problematic items at one time.

-Rich 

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Steve Roylance
> Sent: Saturday, August 03, 2013 9:06 AM
> To: Wayne Thayer
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline
> Requirements
> 
> Hi Wayne.
> 
> GlobalSign would endorse this language helping us all to move this
> forward quickly.
> 
> I would not like to slow approval by trying to add language about
> changes
> to OIDs or Policy at this stage.    In some cases customers need to
> have
> exactly the same certificate Subject DN so it's not possible to amend
> (adding an OU statement etc).   Policy OID seems problematic too as
> cross
> referencing to a specific CPS version would be quite confusing for
> relying
> parties.    The only thing I can see that makes long term sense is
> having
> a direct CPS reference, however, here again cycles between CPS updates
> (Which may simply be to clarify wording rather than something that
> materially affects the content of a certificate) and engineering
> updates may be difficult to align, hence why I prefer to move forward
> with the date based wording (as this is effectively what happens today)
> and not rush a knee jerk reaction to other areas.
> 
> Steve
> 
> 
> 
> On 03/08/2013 00:03, "Wayne Thayer" <wthayer at godaddy.com> wrote:
> 
> >Ryan,
> >
> >I took a stab at updating Rich's proposal based on what I perceive to
> >be the consensus of what it means to rekey (not the definitions I've
> >been
> >using):
> >
> >Motion Begins
> >
> >Add the following definitions to section 4:
> >
> >Reissue - the act of issuing a new Certificate with the identical
> >Subject and Expiry Date as a previously issued and valid Certificate,
> >to the same Subscriber as the original Certificate.
> >
> >Rekey - see Reissue.
> >
> >Add section 9.4.1 Reissuance
> >
> >Reissued Certificates MUST conform to all requirements set forth in
> >this document for newly issued Certificates, including those in
> >sections 9.4 (Validity Period) and 11.3 (Age of Certificate Data).
> >
> >In spite of the requirements set forth in the preceding paragraph,
> >Certificates issued prior to the effective date of this document
> having
> >a Validity Period greater than 60 months, AND; Certificates issued
> >prior to
> >1 April 2015, having a Validity Period greater than 39 months; MAY be
> >Reissued  with a Validity Period exceeding these requirements but not
> >to exceed the Valid To date of the originally issued certificate,
> >provided that the Reissued Certificate is otherwise in full compliance
> >with all other technical and verification requirements contained in
> this document.
> >
> >Motion Ends
> >
> >Thanks,
> >
> >Wayne
> >-----Original Message-----
> >From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> >On Behalf Of Ryan Sleevi
> >Sent: Friday, August 02, 2013 2:56 PM
> >To: kirk_hall at trendmicro.com
> >Cc: public at cabforum.org
> >Subject: Re: [cabfpub] Concerns regarding Mozilla Root
> Program/Baseline
> >Requirements
> >
> >On Fri, Aug 2, 2013 at 2:28 PM, kirk_hall at trendmicro.com
> ><kirk_hall at trendmicro.com> wrote:
> >> We also agree.  We were part of all BR discussions, and the effect
> of
> >>rekeying was never discussed.  If it had been, our position would
> have
> >>been that rekeying would not make a cert that was issued before the
> >>BRs become subject to the BRs -- that would put CAs in the position
> of
> >>having to breach their valid pre-BR contracts (which promised
> rekeying
> >>if needed) with their customers -- something no CA would have agreed
> >>to, barring a showing of an extraordinary security risk which we
> don't
> >>have here.
> >>
> >> Disclosure:  we have no certificates affected by this discussion,
> but
> >>think the Forum would do better to focus on actual, current risks
> that
> >>need to be remedied, and let the improvements we have already made
> >>through the BRs take effect as older certificates expire by their
> terms.
> >
> >Kirk,
> >
> >I think the clearly fundamental disagreement on 'issuance' puts at
> risk
> >every other advance we might make in the BRs to address the actual,
> >current risks, which is why we raised this issue and are thankful to
> >see the spirited discussion.
> >
> >It's been made abundantly clear that, during discussions on
> >expirations, CAs were implicitly assuming that re-keying and
> >re-issuance would be exempt from the BRs. However, I think that
> >highlights the challenge - if that's a valid interpretation, there's
> >absolutely nothing in the BRs to suggest it's "dates only" - after
> all,
> >why not issue arbitrary extensions, unverified names, etc? Why not add
> new fields or extensions?
> >After all, if the pre-BR contracts promised certain functionality that
> >the BRs prohibit - whether it be expiration or any other aspect - why
> >wouldn't this be acceptable?
> >
> >You can see that, at a minimum, we should least converge on an
> >acceptable definition about what certificate fields can be
> manipulated,
> >and what the CA is obligated to do when issuing new certificates under
> >pre-BR contracts.
> >
> >While not exactly a "Yes" vote for Rich's proposal, I think it's
> >certainly the most reasonable attempt to close this hole.
> >
> >I just hope and expect CAs are fully aware and considering the
> >implications of the language - as it appears they may not have when
> >negotiating the BRs - and how this might affect other provisions:
> >domain validation, subject information, EKUs, revocation responders,
> >serial numbers/entropy, etc. It's entirely possible that such
> 'reissued'
> >certificates will differ much more significantly than just flipping
> >some dates and/or a key.
> >
> >Cheers,
> >Ryan
> >
> >>
> >> -----Original Message-----
> >> From: public-bounces at cabforum.org
> >> [mailto:public-bounces at cabforum.org]
> >> On Behalf Of Steve Roylance
> >> Sent: Friday, August 02, 2013 6:46 AM
> >> To: Rich Smith; jeremy.rowley at digicert.com; 'Sigbjørn Vik';
> >> public at cabforum.org
> >> Subject: Re: [cabfpub] Concerns regarding Mozilla Root
> >> Program/Baseline Requirements
> >>
> >> +1
> >>
> >> ..and just to be clear, we are talking about a re-key where only the
> >>key (and therefore SKI) change as well as the unique elements of
> >>serial number
> >> and start date.   All other information remains the same as the
> previous
> >> certificate.    This is what the majority of players in the CA
> industry
> >> today deem "re-issuance" and it's mainly due to the complexity of
> PKI
> >>on platforms coupled with the increase in virtualisation where keys
> >>seem to be lost more frequently that has caused the CA industry to
> >>offer these types of services to help PKI grow - without the need for
> >>customers to buy separate insurance cover to help pay for this
> service
> >>or be charged a 2nd
> >> time for accidental loss.   It's not something one CA can take away
> by
> >> itself and it's not easily something one CA can change by itself,
> but
> >>it's one area we all seemed to miss when looking at reduction of
> >>maximum certificate duration from 60 to 39 so that should be the
> focus
> >>(As Rich states and as I identified).
> >>
> >>
> >> Steve
> >>
> >>
> >> On 02/08/2013 14:30, "Rich Smith" <richard.smith at comodo.com> wrote:
> >>
> >>>Jeremy,
> >>>I agree with your reasoning, but at the same time, I don't think
> that
> >>>we ever really thought in all the way through regarding the
> >>>re-key/reissuance of certificates which had already been sold.  As I
> >>>said in my recent reply to Sigbjorn, I'm not really all that
> >>>concerned with certs sold for longer than 60 month term prior to the
> >>>BRs.  If the consensus is that those need to have time cut off, I
> can
> >>>live with that, but I would like to see us come up with a reasonable
> >>>compromise to deal with those certs which are fully under the BR
> >>>umbrella that fall into the 60 to 39 month change over period.
> >>>-Rich
> >>>
> >>>> -----Original Message-----
> >>>> From: public-bounces at cabforum.org
> >>>> [mailto:public-bounces at cabforum.org]
> >>>> On Behalf Of Jeremy Rowley
> >>>> Sent: Friday, August 02, 2013 7:26 AM
> >>>> To: 'Sigbjørn Vik'; public at cabforum.org
> >>>> Subject: Re: [cabfpub] Concerns regarding Mozilla Root
> >>>> Program/Baseline Requirements
> >>>>
> >>>> As pointed out, a ten year or five year timeline for implementing
> >>>> change in the industry is very long.  This was discussed
> >>>> extensively during adoption of the BRs where we finally agreed to
> a
> >>>> five year timeline that would shift to 3 years in 2015.  I'm
> >>>> strongly opposed to going back and re-evaluating these timelines
> >>>> now, especially considering the amount of discussion, debate, and
> >>>> compromise went into it last time.
> >>>>
> >>>> -----Original Message-----
> >>>> From: public-bounces at cabforum.org
> >>>> [mailto:public-bounces at cabforum.org]
> >>>> On Behalf Of Sigbjørn Vik
> >>>> Sent: Friday, August 02, 2013 4:56 AM
> >>>> To: public at cabforum.org
> >>>> Subject: Re: [cabfpub] Concerns regarding Mozilla Root
> >>>> Program/Baseline Requirements
> >>>>
> >>>> I think the BRs are clear on what they require, and the EV
> >>>>definitions clearly spell out that renewals and reissuances create
> >>>>newly issued certificates. All new certificates require valid
> >>>>validity periods.
> >>>> While I can understand that people may want to discuss if the
> rules
> >>>>are optimal, I dislike CAs claiming ignorance of the rules, or
> >>>>exception to the rules since they have done things differently in
> >>>>the past. If someone wants to claim the rules are unclear, do so
> >>>>before assuming a particular interpretation, not afterwards.
> >>>>
> >>>> Opera is happy to work with the group to define optimal rules, but
> >>>> we dislike CAs engaging in creative reinterpretation of the rules.
> >>>> If we can't trust that CAs follow the rules decided upon, then the
> >>>> rules are close to worthless.
> >>>>
> >>>> In addition to reasons mentioned previously about why constrained
> >>>> validity periods is a good idea, there is also the point about the
> >>>> web moving forwards. For us to be able to upgrade requirements,
> >>>> ditch insecure practices, and promise a secure experience in the
> >>>> future, we need to limit the time limit of certificates today.
> This
> >>>> is basic insurance for the web in the future. Any exceptions we
> >>>> carve out today, take away from this insurance, and might end up
> >>>> costing us a lot. This is not a zero-sum game, and decisions we
> >>>> make today might have serious consequences some years down the
> road.
> >>>>
> >>>> This discussion has also highlighted some other issues:
> >>>> * It seems some CAs are happy to issue backdated certificates. We
> >>>> should probably spell out that signing, issuance and first
> validity
> >>>> dates should all be as close as possible, with a maximum
> >>>> discrepancy allowance.
> >>>> * To be able to verify this, we should also require that any CT
> >>>> registrations happen within that time limit. I will contact the CT
> >>>> team and ask them to consider this.
> >>>> * It seems audits don't catch CAs issuing certificates contrary to
> >>>> the BR.
> >>>> What can we do to ensure that audits catch such issues?
> >>>> * Does the CABForum need an explicit objective?
> >>>>
> >>>> On 01-Aug-13 15:08, Rich Smith wrote:
> >>>> > Taking Ryan's definition and subsequent logic would effectively
> >>>> > nullify all pre-BR agreements made with thousands of CA
> customers
> >>>> > who bought certificates for terms greater than the now allowed
> 60
> >>>> > months max (and soon to be 39 month max).  My lay opinion is
> that
> >>>> > such
> >>>> action
> >>>> > would open the CAs to lawsuits for breach of those agreements.
> >>>>
> >>>> For CAs not to follow the BRs would presumably open them to
> >>>> lawsuits from those who rely on the CAs for trust. For browsers
> not
> >>>> to follow due diligence and best practices would presumably open
> >>>> them to lawsuits from their customers. So if you care about
> >>>> potential lawsuits, the score is
> >>>> 2-1 for not issuing such certificates. However, I think potential
> >>>> lawsuits are irrelevant. The goal of this group should be to
> secure
> >>>> the web, not to ensure the short-term profits for individual
> members.
> >>>> (See the last point above, about an objective.)
> >>>>
> >>>> On 01-Aug-13 17:00, Steve Roylance wrote:
> >>>> > [...] 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.
> >>>>
> >>>> That would be strange. Since the BRs were adopted in November
> 2011,
> >>>> all CAs have known (and been audited on) the fact that after 1
> >>>> April
> >>>> 2015 the maximum validity period is 39 months. For CAs today to
> >>>> sell certificates valid more than 39 months past that date, and
> >>>> promise to reissue them at any point would be shooting themselves
> in the foot.
> >>>>
> >>>> --
> >>>> Sigbjørn Vik
> >>>> Opera Software
> >>>> _______________________________________________
> >>>> 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
> >>
> >>
> >> _______________________________________________
> >> Public mailing list
> >> Public at cabforum.org
> >> https://cabforum.org/mailman/listinfo/public
> >> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
> >> TREND MICRO EMAIL NOTICE
> >> The information contained in this email and any attachments is
> >>confidential and may be subject to copyright or other intellectual
> >>property protection.
> >> If you are not the intended recipient, you are not authorized to use
> >>or disclose this information, and we request that you notify us by
> >>reply mail or telephone and delete the original message from your
> mail
> >>system.
> >> </pre></td></tr></table>
> >>
> >> _______________________________________________
> >> 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
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130805/bff04b33/attachment-0003.bin>