Re: BR compliance of legacy certs at root inclusion time

[Gervase Markham via dev-security-policy]

On 22/08/17 11:02, Ryan Sleevi wrote:
> I think it'd be useful if we knew of reasons why standing up (and
> migrating) to a new infrastructure was not desirable?

It is true that in the case of a legacy root, creating a new root with a
cross-sign is not technically all that complex (although it may take
some time organizationally) and then we could embed that new one.

Given that option, perhaps a blanket statement of BR compliance for all
unexpired and unrevoked certificates is OK - allowing the CA to choose
how best to meet the requirement. (Of course, given the recent
BRpocalypse and how many CAs it affected, we may expect a new CA to need
to go through a similar process of weeding out problems.)

https://github.com/mozilla/pkipolicy/issues/99 filed.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Nick Lamb via dev-security-policy]

Actually previous SHA-1 certs might be one of the least objectionable 
non-compliances assuming that nobody expects Firefox, or other clients in the 
Web PKI to actually trust these certs, because the difference in signature 
algorithm contains the risk nicely.

Bad guys who have speculatively attacked a CA using a (by no means 
computationally cheap) SHA-1 collision attack in expectation that it might one 
day get added to trust stores gain nothing if the entire signature algorithm 
they attacked is meanwhile distrusted, as SHA-1 has been.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Peter Kurrasch via dev-security-policy]

  Yes, I think it's fair for Mozilla to stake out the position that only those certs which comply with the relevant standards, policies, etc. will be accepted. Indeed, much of the other discussion on this list of late would support such a statement. That said, I suppose situations may arise where the interests of the community and relying parties are better served by granting exceptions or waivers to that position. If a CA has a compelling argument for seeking such a waiver and would like to make their case, I suppose it doesn't hurt to hear them out.Perhaps some guidelines would be in order?* The non-compliant certs must not have the potential to cause harm. For example, maybe a compelling case could be made for allowing certs with faulty SAN data but I'm not sure a compelling case could be made for allowing SHA1 certs.* Mozilla has no obligation to create or maintain special functionality in its software to support non-compliant certs.‎ A CA requesting a waiver would need to accept the risk that some of their non-compliant certs could fail to validate in Mozilla products at some point in the future. * ‎In the spirit of transparency, a CA requesting a waiver should be prepared to provide documentation as to how many certs are to be covered by the waiver. For example: "As of (date) there are (number) certificates that do not comply with (specific requirements/policies) in the Not-before date range of (month/year) to (month/year)." Such documentation should be updated "regularly".* I think a CA should be made to explain why they are unable to bring their certs into compliance. There could be an understandable reason, so let's hear it. ("We don't want to" or "We can't afford it" are not acceptable reasons.)I think the bottom line has to be the trust relationship between Mozilla products and relying parties (end users specifically). If Mozilla says a connection is secure it has to mean that all elements of the connection meet the standards of technical excellence or, failing that, that Mozilla has deemed that the technical elements and special circumstances warrant the continued trust and use of that connection by the user.   From: Gervase MarkhamSent: Tuesday, August 22, 2017 11:01 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: BR compliance of legacy certs at root inclusion timeOn 21/08/17 06:20, Peter Kurrasch wrote:> The CA should decide what makes the most sense for their particular> situation, but I think they‎ should be able to provide assurances that> only BR-compliant certs will ever chain to any roots they submit to the> Mozilla root inclusion program.So you are suggesting that we should state the goal, and let the CA workout how to achieve it? That makes sense.I agree with Nick that transparency is important.Is there room for an assessment of risk, or do we need a blanketstatement? If, say, a CA used short serials up until 2 years ago but hassince ceased the practice, we might say that's not sufficiently riskyfor them to have to stand up and migrate to a new cross-signed root. Iagree that becomes subjective.Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Ryan Sleevi via dev-security-policy]

On Tue, Aug 22, 2017 at 12:01 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 21/08/17 06:20, Peter Kurrasch wrote:
> > The CA should decide what makes the most sense for their particular
> > situation, but I think they‎ should be able to provide assurances that
> > only BR-compliant certs will ever chain to any roots they submit to the
> > Mozilla root inclusion program.
>
> So you are suggesting that we should state the goal, and let the CA work
> out how to achieve it? That makes sense.
>
> I agree with Nick that transparency is important.
>
> Is there room for an assessment of risk, or do we need a blanket
> statement? If, say, a CA used short serials up until 2 years ago but has
> since ceased the practice, we might say that's not sufficiently risky
> for them to have to stand up and migrate to a new cross-signed root. I
> agree that becomes subjective.


I think it'd be useful if we knew of reasons why standing up (and
migrating) to a new infrastructure was not desirable?

It helps avoid value-based judgement of risk, which, like human processes
for verifying certificates, can fail - and instead sets up objective
criteria and processes that provide greater assurance. It's also useful to
consider that the function of cost (whether fiduciary or in complexity) is
something that is amortized over time, and achieves economies of scale
through its mandate, so we should keep a critical eye in remembering that
the associated costs will go down over time as CAs develop processes to
routinely do so.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Gervase Markham via dev-security-policy]

On 21/08/17 06:20, Peter Kurrasch wrote:
> The CA should decide what makes the most sense for their particular
> situation, but I think they‎ should be able to provide assurances that
> only BR-compliant certs will ever chain to any roots they submit to the
> Mozilla root inclusion program.

So you are suggesting that we should state the goal, and let the CA work
out how to achieve it? That makes sense.

I agree with Nick that transparency is important.

Is there room for an assessment of risk, or do we need a blanket
statement? If, say, a CA used short serials up until 2 years ago but has
since ceased the practice, we might say that's not sufficiently risky
for them to have to stand up and migrate to a new cross-signed root. I
agree that becomes subjective.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Peter Kurrasch via dev-security-policy]

  I don't think Mozilla ‎can tolerate having certs that successfully chain to a root contained in its trust store that are not BR compliant.The end user trusts Mozilla products to provide a certain level of assurance in the cert chains that it allows. Having a cert chain successfully validated with a (perhaps?) hidden caveat of "by the way, we don't actually trust this cert because it doesn't comply with accepted policies" doesn't make much sense.The CA should decide what makes the most sense for their particular situation, but I think they‎ should be able to provide assurances that only BR-compliant certs will ever chain to any roots they submit to the Mozilla root inclusion program.From: Gervase Markham via dev-security-policySent: Friday, August 18, 2017 10:03 AM‎...What should our policy be regarding BR compliance for certificatesissued by a root requesting inclusion, which were issued before the dateof their request? Do we:A) Require all certs be BR-compliant going forward, but grandfather in   the old ones; orB) Require that any non-BR-compliant old certs be revoked; orC) Require that any seriously (TBD) non-BR-compliant old certs be   revoked; orD) something else?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Ryan Sleevi via dev-security-policy]

On Sun, Aug 20, 2017 at 3:44 PM, Peter Bowen  wrote:

> From the perspective of being "clean" from a given NSS version this,
> makes sense.  However the reality for most situations is there is
> demand to support applications and devices with trust stores that have
> not been updated for a while.  This could be something as similar as
> Firefox ESR or it could be a some device with an older trust store.
> Assuming there is a need to have the same certificate chain work in
> both scenarios, the TLS server may need to send a chain with multiple
> root to root cross-certificates.
>

I'm not sure it's fair to say there needs to be the 'same' certificate
chain working in both. The variety of trust stores already shows how that's
not necessary today. Merely, one needs to have 'a' certificate chain.

Perhaps I've missed a point you weren't stating, but I'm not sure why you
would need root-to-root cross-certificates, as this proposal only applies
to the roots included in Mozilla's store, and offers a transition path for
those roots.


> https://gist.github.com/pzb/cd10fbfffd7cb25bb57c38c3865f18f2 is just
> the roots in each unique disconnected graph.  Having the entries there
> does not imply that all have cross-signed each other, rather than
> there is a path from each pair of roots to a common node.  For
> example, Root A and Root B might each have a subordinate CA that have
> each cross-certified the same, third subordinate.
>

I'm not sure if you're arguing that this is a desired config, or merely, a
config that exists. I certainly would not be willing to suggest CAs have
(effectively) managed their cross-certificates well, and it would seem as
if some of these paths are reflective of business transitions/deals (and
their expirations) rather than intrinsic needs of the Web PKI.

As it sounds like you agree that the overall design is both sound and
desirable, from a Web PKI perspective, perhaps you could clarify what you
believe is a case not supported by this design. This would be useful to
understanding what, if any, material consequence there would be of
implementing this saner approach to root store management.


> Considering we already see paths like:
>
> OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US =>
> CN=VeriSign Class 3 Public Primary Certification Authority - G3,OU=(c)
> 1999 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust
> Network,O=VeriSign\, Inc.,C=US =>
> CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c)
> 2006 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust
> Network,O=VeriSign\, Inc.,C=US =>
> CN=VeriSign Universal Root Certification Authority,OU=(c) 2008
> VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust
> Network,O=VeriSign\, Inc.,C=US =>
> CN=Symantec Class 3 Extended Validation SHA256 SSL CA,OU=Symantec
> Trust Network,O=Symantec Corporation,C=US * =>
> (End-Entity Certificate)
>
> I think we need to be careful when considering root rotations.
>

While a useful real world example, I think the cross-signing activities of
several CAs (and one can examine Entrust for a similar issue, or the
multiple paths StartCom previously did) are not necessarily designed with
either interoperability or consideration of the ecosystem in mind. After
all, this is the same set of activities that make it easy for 'forget'
disclosure of critical intermediates.

Rather, with appropriate advice, one can easily end up with a linear path,
where the only 'cost' is paid by legacy systems that don't update, and the
servers that need to support such legacy systems. As there is an inherent
lifetime for how long something can be 'safely' connected to the Internet,
this doesn't seem unreasonable to build upon.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Peter Bowen via dev-security-policy]

On Fri, Aug 18, 2017 at 8:47 AM, Ryan Sleevi via dev-security-policy
 wrote:
> On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Sometimes, CAs apply for inclusion with new, clean roots. Other times,
>> CAs apply to include roots which already have a history of issuance. The
>> previous certs issued by that CA aren't always all BR-compliant. Which
>> is in one sense understandable, because up to this point the CA has not
>> been bound by the BRs. Heck, the CA may never even have heard of the BRs
>> until they come to apply - although this seems less likely than it would
>> once have been.
>>
>> What should our policy be regarding BR compliance for certificates
>> issued by a root requesting inclusion, which were issued before the date
>> of their request? Do we:
>>
>> A) Require all certs be BR-compliant going forward, but grandfather in
>>the old ones; or
>> B) Require that any non-BR-compliant old certs be revoked; or
>> C) Require that any seriously (TBD) non-BR-compliant old certs be
>>revoked; or
>> D) something else?
>>
>
> D) Require that the CA create a new root certificate to be included within
> Mozilla products, and which all future BR-compliant certificates will be
> issued from this new root. In the event this CA has an existing root
> included within one or more software products, this CA may cross-certify
> their new root with their old root, thus ensuring their newly-issued
> certificates (which are BR compliant) work with such legacy software.
>
> This ensures that all included CAs operate from a 'clean slate' with no
> baggage or risk. It also ensures that the slate always starts from "BR
> compliant" and continues forward.
>
> However, some (new) CAs may rightfully point out that existing, 'legacy'
> CAs have not had this standard applied to them, and have operated in a
> manner that is not BR compliant in the past.
>
> To reduce and/or eliminate the risk from existing CAs, particularly those
> with long and storied histories of misissuance, which similar present
> unknowns to the community (roots that may have been included for >5 years,
> thus prior to the BR effective date), require the same of existing roots
> who cannot demonstrate that they have had BR audits from the moment of
> their inclusion. That is, require 'legacy' CAs to create and stand up new
> roots, which will be certified by their existing roots, and transition all
> new certificate issuance to these new 'roots' (which will appear to be
> cross-signed/intermediates, at first). Within 39 months, Mozilla will be
> able to remove all 'legacy' roots for purposes of website authentication,
> adding these 'clean' roots in their stead, without any disruption to the
> community. Note that this is separable from D, and represents an effort to
> holistically clean up and reduce risk.
>
> The transition period at present cannot be less than 39 months (the maximum
> validity of a newly issued certificate), plus whatever time is afforded to
> CAs to transition (presumably, on the order of 6 months should be
> sufficient). In the future, it would also be worth considering reducing the
> maximum validity of certificates, such that such rollovers can be completed
> in a more timely fashion, thus keeping the ecosystem in a constant 'clean'
> state.

>From the perspective of being "clean" from a given NSS version this,
makes sense.  However the reality for most situations is there is
demand to support applications and devices with trust stores that have
not been updated for a while.  This could be something as similar as
Firefox ESR or it could be a some device with an older trust store.
Assuming there is a need to have the same certificate chain work in
both scenarios, the TLS server may need to send a chain with multiple
root to root cross-certificates.

To get a feel for how long a not looping path might be, I recently
pulled trust stores for dozens of versions of Windows, Netscape,
Mozilla, and Java.  I then used unexpired cross-certificates from CT
to group these trust anchors into unique clusters or disconnected
graphs.  The results are available as gists.

https://gist.github.com/pzb/cd10fbfffd7cb25bb57c38c3865f18f2 is just
the roots in each unique disconnected graph.  Having the entries there
does not imply that all have cross-signed each other, rather than
there is a path from each pair of roots to a common node.  For
example, Root A and Root B might each have a subordinate CA that have
each cross-certified the same, third subordinate.

https://gist.github.com/pzb/ffab25cbe7d32c616792a5dec3711315 is the
same data with all the unexpired subordinate cross-certificates
included.

Note that the clustering does not take into account anything besides
expiration; for example it is possible that two paths to a common node
have conflicting constraints.

Considering we already see paths like:

OU=Class 3 Public 

BR compliance of legacy certs at root inclusion time

[Nick Lamb via dev-security-policy]

I'll speak up for transparency again. In terms of policy the most vital thing 
is that a CA tells us about such certs during application. One way to do that 
would be to CT log them, but especially for small sets there might be other 
sensible ways. If we can't be shown the certs in question (or much worse the CA 
didn't keep records) it's tough to be sure the risk is tolerable, we're back to 
taking the CA's word for it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Kristian Fiskerstrand via dev-security-policy]

[Intro; long time lurker but I rarely post, but given this is an open
question not directly tied to any CA or official capacity my opinions are..]

On 08/18/2017 05:02 PM, Gervase Markham via dev-security-policy wrote:
> Sometimes, CAs apply for inclusion with new, clean roots. Other times,
> CAs apply to include roots which already have a history of issuance. The
> previous certs issued by that CA aren't always all BR-compliant. Which
> is in one sense understandable, because up to this point the CA has not
> been bound by the BRs. Heck, the CA may never even have heard of the BRs
> until they come to apply - although this seems less likely than it would
> once have been.
> 
> What should our policy be regarding BR compliance for certificates
> issued by a root requesting inclusion, which were issued before the date
> of their request? Do we:
> 

Iff the CA has known non-BR compliant certs issued I would be in favor
of the CA setting up a new, clean root certificate for the inclusion in
the root program at this point, and require all the certificates issued
by the approved root to be BR compliant.

> A) Require all certs be BR-compliant going forward, but grandfather in
>the old ones; or
> B) Require that any non-BR-compliant old certs be revoked; or
> C) Require that any seriously (TBD) non-BR-compliant old certs be
>revoked; or
>

If new root required for non-BR compliant history, the issues above
seems mitigated

 D) something else?

Yes please


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Nil satis nisi optimum
Nothing but the best is good enough



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: BR compliance of legacy certs at root inclusion time

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Sometimes, CAs apply for inclusion with new, clean roots. Other times,
> CAs apply to include roots which already have a history of issuance. The
> previous certs issued by that CA aren't always all BR-compliant. Which
> is in one sense understandable, because up to this point the CA has not
> been bound by the BRs. Heck, the CA may never even have heard of the BRs
> until they come to apply - although this seems less likely than it would
> once have been.
>
> What should our policy be regarding BR compliance for certificates
> issued by a root requesting inclusion, which were issued before the date
> of their request? Do we:
>
> A) Require all certs be BR-compliant going forward, but grandfather in
>the old ones; or
> B) Require that any non-BR-compliant old certs be revoked; or
> C) Require that any seriously (TBD) non-BR-compliant old certs be
>revoked; or
> D) something else?
>

D) Require that the CA create a new root certificate to be included within
Mozilla products, and which all future BR-compliant certificates will be
issued from this new root. In the event this CA has an existing root
included within one or more software products, this CA may cross-certify
their new root with their old root, thus ensuring their newly-issued
certificates (which are BR compliant) work with such legacy software.

This ensures that all included CAs operate from a 'clean slate' with no
baggage or risk. It also ensures that the slate always starts from "BR
compliant" and continues forward.

However, some (new) CAs may rightfully point out that existing, 'legacy'
CAs have not had this standard applied to them, and have operated in a
manner that is not BR compliant in the past.

To reduce and/or eliminate the risk from existing CAs, particularly those
with long and storied histories of misissuance, which similar present
unknowns to the community (roots that may have been included for >5 years,
thus prior to the BR effective date), require the same of existing roots
who cannot demonstrate that they have had BR audits from the moment of
their inclusion. That is, require 'legacy' CAs to create and stand up new
roots, which will be certified by their existing roots, and transition all
new certificate issuance to these new 'roots' (which will appear to be
cross-signed/intermediates, at first). Within 39 months, Mozilla will be
able to remove all 'legacy' roots for purposes of website authentication,
adding these 'clean' roots in their stead, without any disruption to the
community. Note that this is separable from D, and represents an effort to
holistically clean up and reduce risk.

The transition period at present cannot be less than 39 months (the maximum
validity of a newly issued certificate), plus whatever time is afforded to
CAs to transition (presumably, on the order of 6 months should be
sufficient). In the future, it would also be worth considering reducing the
maximum validity of certificates, such that such rollovers can be completed
in a more timely fashion, thus keeping the ecosystem in a constant 'clean'
state.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

BR compliance of legacy certs at root inclusion time

[Gervase Markham via dev-security-policy]

Sometimes, CAs apply for inclusion with new, clean roots. Other times,
CAs apply to include roots which already have a history of issuance. The
previous certs issued by that CA aren't always all BR-compliant. Which
is in one sense understandable, because up to this point the CA has not
been bound by the BRs. Heck, the CA may never even have heard of the BRs
until they come to apply - although this seems less likely than it would
once have been.

What should our policy be regarding BR compliance for certificates
issued by a root requesting inclusion, which were issued before the date
of their request? Do we:

A) Require all certs be BR-compliant going forward, but grandfather in
   the old ones; or
B) Require that any non-BR-compliant old certs be revoked; or
C) Require that any seriously (TBD) non-BR-compliant old certs be
   revoked; or
D) something else?

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy