Re: [EXT] Symantec Update on SubCA Proposal

[Rick Andrews via dev-security-policy]

On Friday, July 21, 2017 at 12:39:54 PM UTC-7, Peter Bowen wrote:
> Steve,
> 
> I think this level of public detail is very helpful when it comes to
> understanding the proposal.
> 
> On Thu, Jul 20, 2017 at 8:00 AM, Steve Medin via dev-security-policy
> wrote:
> > 1)  December 1, 2017 is the earliest credible date that any RFP 
> > respondent can provide the Managed CA solution proposed by Google, assuming 
> > a start date of August 1, 2017. Only one RFP respondent initially proposed 
> > a schedule targeting August 8, 2017 (assuming a start date of June 12, 
> > 2017). We did not deem this proposal to be credible, however, based on the 
> > lack of specificity around our RFP evaluation criteria, as compared to all 
> > other RFP responses which provided detailed responses to all aspects of the 
> > RFP, and we have received no subsequent information from this bidder to 
> > increase our confidence.
> 
> You note that this assumes a start date of June 12.   A later email
> from Rick Andrews says "Our proposed dates assume we are able to
> finalize negotiation of contracts with the selected Managed CA
> partner(s), [...] by no later than July 31, 2017."
> 
> Presumably the June 12 date is long gone.  However if one assumes the
> delta of 57 days from start to delivery stands, this would put
> delivery at September 26, 2017.  This is two months sooner than the
> December 1 date.  This seems like a pretty big difference.  Given you
> are asking to delay the timeline based on other RFP respondents being
> unable to hit earlier dates, it seems prudent to ask whether the you
> attempted to investigate the proposal from the bidder who proposed
> August 8.

Please see our response to Alex Gaynor.
 
> Given that one of the requirements stated by Google is that the SubCA
> operator had to have roots that have been in the Google trust store
> for several years, it seems unusual that any eligible respondent would
> not be "credible" out of the gate.
> 
> Did you ask them to provide more information and details to help
> determine if it was a "credible" offer?

There is a difference between a prospective SubCA being capable of performing 
the activities of a Managed CA under the SubCA proposal and having a realistic 
plan to do so. We concluded the RFP response from the sole respondent who 
proposed a 2-month timeline was not credible because it failed to meet a 
minimum bar of providing us with sufficient information to evaluate the 
bidder’s ability to satisfy RFP requirements or meaningfully compare / contrast 
the bidder’s response with all other RFP respondents.  There were other 
attributes relating to this bidder’s proposal beyond its lack of content in 
addressing RFP evaluation criteria that reinforced our conclusion that the bid 
was not credible.

> > 2)  We are using several selection criteria for evaluating RFP 
> > responses, including the depth of plan to address key technical integration 
> > and operational requirements, the timeframe to execute, the ability to 
> > handle the scope, volume, language, and customer support requirements both 
> > for ongoing issuance and for one-time replacement of certificates issued 
> > prior to June 1, 2016, compliance program and posture, and the ability to 
> > meet uptime, interface performance, and other SLAs. Certain RFP respondents 
> > have distinguished themselves based on the quality and depth of their 
> > integration planning assumptions, requirements and activities, which have 
> > directly influenced the dates we have proposed for the SubCA proposal.
> >
> > 3)  The RFP was first released on May 26, 2017. The first round of 
> > bidder responses was first received on June 12, 2017.
> 
> In the 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
> message, it was implied that Symantec was aware of the SubCA plan and
> dates since at least May 12.  Given the plan to sign an agreement by
> July 31, the August 8 date seems rather impossible. Did Symantec push
> back on the August 8 date at that point?

Yes, Symantec pushed back on the August 8 date in its earliest discussions with 
both Google and Mozilla after the SubCA proposal was made. We pushed back on 
the dates again publicly on June 1st.  We have now done the work of executing a 
robust RFP process that included multiple parties and involved multiple working 
sessions to arrive at dates that are both aggressive and achievable for the 
size and scale of our CA operations. 

> In the original email that started this subthread, you said, "Some of
> the prospective Managed CAs have proposed supporting only a portion of
> our volume (some by customer segment, others by geographic focus), so
> we are also evaluating options that involve working with multiple
> Managed CAs."
> 
> Have you considered a staggered date system for different classes of
> certificates.  For example, I would assume that certificates that
> don't contain subject identity information 

Re: [EXT] Symantec Update on SubCA Proposal

[Rick Andrews via dev-security-policy]

On Friday, July 21, 2017 at 12:07:02 PM UTC-7, Alex Gaynor wrote:
> On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin wrote:
> 
> > 1)  *December 1, 2017 is the earliest credible date that any RFP
> > respondent can provide the Managed CA solution proposed by Google, assuming
> > a start date of August 1, 2017. Only one RFP respondent initially proposed
> > a schedule targeting August 8, 2017 (assuming a start date of June 12,
> > 2017). We did not deem this proposal to be credible, however, based on the
> > lack of specificity around our RFP evaluation criteria, as compared to all
> > other RFP responses which provided detailed responses to all aspects of the
> > RFP, and we have received no subsequent information from this bidder to
> > increase our confidence.*
> >
> >
> Hi Steve,
> 
> Given that this represents nearly a 4 month difference in timelines, can
> you give us any more insight here as why you see such a large delta?
> 
> Alex

We have evaluated the rigor of the proposals with regard to integration between 
Symantec and the Managed CA(s) for all certificate lifecycle functions for 
retail, partner, and Enterprise RA models, supporting enrollment, all methods 
of domain verification, organization and extended validation vetting, 
re-authentication, replacement, renewal, cancelation, modification, revocation, 
CAA checking, CT logging, and CRL and OCSP response provisioning; the models 
for cross-team engagement and release planning; identification of any gaps and 
the plans to address; and the plans for end-to-end testing. The most aggressive 
of the RFP responses was the sole outlier in terms of timing (2 months to 
implementation) and offered the least amount of information in response to the 
RFP. There were other attributes relating to this bidder’s proposal beyond its 
lack of content in addressing RFP evaluation criteria that reinforced our 
conclusion that the bid was not realistic.  The difference between the most 
aggressive timing proposal when compared with the other RFP respondent plans 
was only about two months. All other RFP responses independently offered 
project plan timelines that spanned approximately 4-6 months. Symantec’s 
internal planning concluded that a 4 month timeline was aggressive but 
achievable.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

[Matthew Hardeman via dev-security-policy]

It seems that a group of Princeton researchers just presented a live 
theoretical* misissuance by Let's Encrypt.

They did a sub-prefix hijack via a technique other than those I described here 
and achieved issuance while passing-through traffic for other destination 
within the IP space of the hijacked scope.

They've got a paper at: 
https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf

I say that theoretical because they hijacked a /24 of their own /23 under a 
different ASN but I am given to believe that the "adversarial" ASN is also 
under their control or that they had permission to use it.  In as far as this 
is the case, this technically isn't a misissuance because hijacking ones own IP 
space is technically just a different routing configuration diverting the 
traffic to the destination they properly control to another point of 
interconnection they properly controlled.

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

RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Just as a follow up, these two certificates (with
www.intesasanpaolovita..biz) were revoked on 19 July 2017.  See
http://ca.intesasanpaolo.com/portalCais0/crl/servext2.crl.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Tuesday, July 18, 2017 9:54 AM
To: Jakob Bohm ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Tue, Jul 18, 2017 at 8:05 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/07/2017 21:27, Nick Lamb wrote:
> > On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson  wrote:
> >> Thank you for bringing this to our attention.  We have contacted 
> >> Intesa
> Sanpaolo regarding this error and have asked them to correct it as 
> soon as possible.
> >
> > "Correcting" the error is surely the smaller of the two tasks ahead.
> >
>
> Depends if the only error is allowing double dots (while correctly 
> validating the domain as if spelled without the extra dot).  Things 
> are much worse if double dots bypass domain validation completely.
>
> Since at least two CA systems have now been found to accept double 
> dots, where only single dots should be allowed, it is reasonable to 
> assume that some relying parties also allow double dots.


It is not reasonable to conclude there is a pattern based on two samples,
nor is it reasonable to conclude there is a pattern in an unrelated system.
If you are aware of any relying party libraries based on CA validation
libraries, that would be useful in establishing the reasonableness of the
conclusion.


This makes it
> essential that any certificates with this syntax error have been 
> completely validated for the equivalent single-dotted name.
>
> I also notice that this is apparently an unconstrained 
> intermediate/SubCA.
>
> Since this appears to be a certificate for the cert holders own 
> domains, it is also possible domain validation was done manually, as 
> in "we know first hand that we control these domains", making this an 
> OV cert, not a DV cert.


All OV certs are DV certs - they are subsets.

Perhaps you're confusing DNS validation done at an Authorization Domain
Name, rather than FQDN. That would be consistent with allowing the customer
to enter labels below the validated domain (under 3.2.5 of the BRs), but not
validating it's a valid DNS label or well formed domain name.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec Update on SubCA Proposal

[Peter Bowen via dev-security-policy]

Steve,

I think this level of public detail is very helpful when it comes to
understanding the proposal.

On Thu, Jul 20, 2017 at 8:00 AM, Steve Medin via dev-security-policy
 wrote:
> 1)  December 1, 2017 is the earliest credible date that any RFP 
> respondent can provide the Managed CA solution proposed by Google, assuming a 
> start date of August 1, 2017. Only one RFP respondent initially proposed a 
> schedule targeting August 8, 2017 (assuming a start date of June 12, 2017). 
> We did not deem this proposal to be credible, however, based on the lack of 
> specificity around our RFP evaluation criteria, as compared to all other RFP 
> responses which provided detailed responses to all aspects of the RFP, and we 
> have received no subsequent information from this bidder to increase our 
> confidence.

You note that this assumes a start date of June 12.   A later email
from Rick Andrews says "Our proposed dates assume we are able to
finalize negotiation of contracts with the selected Managed CA
partner(s), [...] by no later than July 31, 2017."

Presumably the June 12 date is long gone.  However if one assumes the
delta of 57 days from start to delivery stands, this would put
delivery at September 26, 2017.  This is two months sooner than the
December 1 date.  This seems like a pretty big difference.  Given you
are asking to delay the timeline based on other RFP respondents being
unable to hit earlier dates, it seems prudent to ask whether the you
attempted to investigate the proposal from the bidder who proposed
August 8.

Given that one of the requirements stated by Google is that the SubCA
operator had to have roots that have been in the Google trust store
for several years, it seems unusual that any eligible respondent would
not be "credible" out of the gate.

Did you ask them to provide more information and details to help
determine if it was a "credible" offer?

> 2)  We are using several selection criteria for evaluating RFP responses, 
> including the depth of plan to address key technical integration and 
> operational requirements, the timeframe to execute, the ability to handle the 
> scope, volume, language, and customer support requirements both for ongoing 
> issuance and for one-time replacement of certificates issued prior to June 1, 
> 2016, compliance program and posture, and the ability to meet uptime, 
> interface performance, and other SLAs. Certain RFP respondents have 
> distinguished themselves based on the quality and depth of their integration 
> planning assumptions, requirements and activities, which have directly 
> influenced the dates we have proposed for the SubCA proposal.
>
> 3)  The RFP was first released on May 26, 2017. The first round of bidder 
> responses was first received on June 12, 2017.

In the 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
message, it was implied that Symantec was aware of the SubCA plan and
dates since at least May 12.  Given the plan to sign an agreement by
July 31, the August 8 date seems rather impossible. Did Symantec push
back on the August 8 date at that point?

In the original email that started this subthread, you said, "Some of
the prospective Managed CAs have proposed supporting only a portion of
our volume (some by customer segment, others by geographic focus), so
we are also evaluating options that involve working with multiple
Managed CAs."

Have you considered a staggered date system for different classes of
certificates.  For example, I would assume that certificates that
don't contain subject identity information would have less work for
migration integration than EV certificates.  Given that it is common
practice to have a different SubCA for different certificates types,
could you hit an earlier date for non-EV certificates and then later
have the EV SubCA ready?

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

Re: [EXT] Symantec Update on SubCA Proposal

[Alex Gaynor via dev-security-policy]

On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin 
wrote:

> 1)  *December 1, 2017 is the earliest credible date that any RFP
> respondent can provide the Managed CA solution proposed by Google, assuming
> a start date of August 1, 2017. Only one RFP respondent initially proposed
> a schedule targeting August 8, 2017 (assuming a start date of June 12,
> 2017). We did not deem this proposal to be credible, however, based on the
> lack of specificity around our RFP evaluation criteria, as compared to all
> other RFP responses which provided detailed responses to all aspects of the
> RFP, and we have received no subsequent information from this bidder to
> increase our confidence.*
>
>
Hi Steve,

Given that this represents nearly a 4 month difference in timelines, can
you give us any more insight here as why you see such a large delta?

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

Re: How long to resolve unaudited unconstrained intermediates?

[Rob Stradling via dev-security-policy]

On 20/07/17 15:24, Gervase Markham via dev-security-policy wrote:

On 12/07/17 21:18, Ben Wilson wrote:

For CAs with emailProtection and proper name constraints, where would such CAs 
appear in https://crt.sh/mozilla-disclosures?  
https://crt.sh/mozilla-disclosures#constrainedother?  Or a new section of the 
list, yet to be determined?


I believe Rob has now split the list into two.


Ben, these intermediate certs should appear in 
https://crt.sh/mozilla-disclosures#constrained (if they've not been 
disclosed to CCADB).


https://crt.sh/mozilla-disclosures#constrainedother is for intermediate 
certs for which there is a signature chain up to a root that is trusted 
by Mozilla, but which are trusted for neither Server Authentication nor 
Secure Email.  (Mostly they're Code Signing intermediates, it seems).



And for CAs where EKU contains emailProtection, what are the programmatic 
criteria that determine whether the CA will be in such list as properly name 
constrained, since the Baseline Requirements don’t cover email certificates?  
(Presumably, a properly name-constrained email CA would not require any audit.)


Rob would be able to say. But the criteria for whether an email
intermediate is properly name constrained are in Mozilla policy 2.5.


The purpose of the https://crt.sh/mozilla-disclosures page is to track 
compliance with the Mozilla Root Store Policy.  BRs, or the lack of 
them, are only relevant to this page insofar as the Mozilla Root Store 
Policy says they're relevant.


So yes, this page uses the criteria from Mozilla Root Store Policy v2.5.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Symantec Update on SubCA Proposal

[Gervase Markham via dev-security-policy]

On 21/07/17 07:00, Rick Andrews wrote:
> In light of all of these implications, we respectfully request that Mozilla, 
> Google and the community consider the dates Symantec has proposed, which are 
> the results of our earnest and extensive efforts to implement the spirit of 
> the SubCA proposal. 

Thank you for the timeliness and completeness of your response. I am
travelling today, but will try and consider it over the weekend.

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

Re: Symantec Update on SubCA Proposal

[Rick Andrews via dev-security-policy]

On Thursday, July 20, 2017 at 12:31:56 PM UTC-7, Gervase Markham wrote:
> Hi Steve,
> 
> Thanks for posting this. I appreciate the level of detail provided,
> which is useful in giving us a basis for discussion. It's a little
> regrettable, though, that it was published a couple of weeks after we
> were led to expect it...

In our June 1 post, we stated that we would update the community after the end 
of the month. Considering the community’s request for detail in our response, 
we wanted our update to reflect our latest discussions with RFP respondents, 
which took place during the first two weeks of July.  These discussions have 
directly informed our proposed dates as described in our post.  We also felt it 
was important to collect feedback from both Google and Mozilla (which we have 
done) on our draft timing proposal before submitting it to the community for 
consideration given that Google and Mozilla authored / endorsed the SubCA 
proposal.

> One note before we start: Symantec's business dealings regarding its CA
> business are not of concern to Mozilla other than relating to the
> "change of ownership or control" provisions in Mozilla policy (policy
> 2.5 section 8). However, if dates are proposed or agreed for
> implementation of the consensus plan, we would not expect those dates to
> be renegotiated because of a change of ownership or control.
> 
> Am I right in saying that, in order to hit these dates you are
> proposing, you would strongly desire to get consensus on them by August 1st?

Symantec would like to reach consensus on the totality of the SubCA proposal, 
including final dates, as soon as possible.  This is in the best interest of 
all.  Our proposed dates assume we are able to finalize negotiation of 
contracts with the selected Managed CA partner(s), which incorporate final 
agreed-upon dates by the community, by no later than July 31, 2017.

> On 18/07/17 19:22, Steve Medin wrote:
> > New Certificate Issuance: We believe the dates for transition of validation 
> > and issuance to the Managed CA that are both aggressive and achievable are 
> > as follows:
> > 
> > - Implement the Managed CA by December 1, 2017 (changed from August 8, 
> > 2017);
> > 
> > - Managed CA performs domain validation for all new certificates by 
> > December 1, 2017 (changed from November 1, 2017); and
> > 
> > - Managed CA performs full validation for all certificates by February 1, 
> > 2018. Prior to this date, reuse of Symantec authenticated organization 
> > information would be allowable for certificates of <13 months in validity.
> 
> To summarise for those reading along: this represents a change of a
> little less than 4 months for the first date, 1 month for the second
> date, and the third date is as originally proposed.

This is correct. We have worked with our RFP respondents to put together an 
aggressive but achievable plan that delivers on the spirit of the original 
proposal.

> Steve: to be clear, this means that browsers could implement a block on
> certificates from Symantec's existing PKI as follows: after December
> 1st, 2017, they could dis-trust all certificates with a notBefore
> greater than December 1st 2017?

Correct. However, as we indicated in our update, with a change of this 
magnitude we believe that there will likely be material compatibility and 
interoperability issues that will only come to light once server operators 
begin the transition to the Managed CA issued certificates. Recognizing this, 
we recommend that we establish a clear process to evaluate exception requests 
that includes consultations with the browsers to handle such corner cases.

> Given the explanations Symantec has given as to why these dates are
> reasonable, and the effort required to stand up the new PKI, I am minded
> to accept them, particularly as they have managed to hit the third
> originally-proposed date on the nose. However, I am still open to
> community input.
> 
> > Replacement of Unexpired Certificates Issued Before June 1, 2016: There are 
> > two major milestones that must be achieved after implementation of the 
> > Managed CA in order to replace unexpired certificates issued before June 1, 
> > 2016 that do not naturally expire before the distrust date(s) in the SubCA 
> > proposal. Those include the full revalidation of certificate information 
> > and then the customer replacement of those certificates. 
> 
> That is not necessarily so. The customers could replace their
> certificates using new, CT-logged certificates from Symantec's old
> infrastructure. This doesn't require any revalidation or any change in
> the certificate chain, so should have excellent compatibility
> properties, and it's something that could begin today.

While this is true under the terms of the SubCA proposal, we do not believe 
this is consistent with the spirit of Google’s and Mozilla’s prior commentary 
on their intent regarding the SubCA proposal, which is to limit the issuance of 
Symantec