Re: StartCom cross-signs disclosed by Certinomis

[J.C. Jones via dev-security-policy]

On 8/3/17 5:27 PM, Kathleen Wilson via dev-security-policy wrote:
> On Thursday, August 3, 2017 at 4:34:27 PM UTC-7, Ryan Sleevi wrote:
> In bug #1311832 there is a note about cross-signing:
> "[1] The new (replacement) root certificates may be cross-signed by the 
> Affected Roots. However, the Affected Roots may *not* be cross-signed by the 
> new (replacement) root certificates, because that would bring the concerns 
> about the Affected Roots into the scope of the new roots. Due to the way we 
> are implementing the distrust, the new root certificates must have a Subject 
> Distinguished Name that does not overlap with the Subject Distinguished Names 
> listed above."
>
> I don't see anything expressly forbidding cross-signing of new roots, but 
> perhaps that was an oversight.

The issue in my eyes isn't necessarily the cross-signature (though the
delay in disclosure is a problem), it's using a publicly-trusted CA to
fine-tune the issuance process.

It's perfectly understandable to sign invalid certificates that violate
aspects of root policies and the BRs while proceeding with your test
plan. I've certainly done that myself. It's not acceptable to me that
the test plan used a CA that either already was or subsequently became
publicly-trusted.

This is a professional PKI operation, being overseen by industry
veterans. If something as concrete as the issuance process had such a
glaring quality assurance methodology failure, why should anyone believe
that something much harder -- subscriber validation -- is going to be
done correctly?

I agree that Mozilla should add these intermediates to OneCRL.

> Along this line of discussion, I have not felt comfortable with StartCom's 
> current root inclusion request (bug #1381406), because Hanno raised a concern 
> about the private key used by the new root is also used by two intermediate 
> certificates, one of them revoked. This doesn't see like good practice to me, 
> and I'm not sure that Inigo's response is sufficient. So, I'm also wondering 
> if I should close Bug #1381406 and request StartCom to start completely over 
> with their new CA Hierarchy, and get it right, before creating their next 
> root inclusion request.

I agree, it's not good practice, even if it's not prohibited. Since this
brings it up, we should consider prohibiting it going forward. Keys, and
space on HSMs for keys, are certainly not free, but they aren't so
expensive that the Web PKI should suffer the costs of ambiguous mappings
of keys to CAs.

CRLs and OneCRL revoke trust based on issuer/serial combinations. If
this key were compromised in some way, we would need to have knowledge
of, and revoke, all combinations. We've discussed before needing a way
through OneCRL (or OneCRL 2.0) to revoke based on public key hash; this
is part of the reason why.

J.C.

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

Re: Misissued certificates

[J.C. Jones via dev-security-policy]

Lee,

Different parts of Mozilla does monitor CT, both for internal IT
purposes, as well as research into the WebPKI. It seems like crt.sh does
a great job already of handling cablint/x509lint of newly-observed certs.

What are you looking for Mozilla to provide here that isn't already
being accomplished by the community (e.g., crt.sh, censys.io, and others)?

Thanks,
J.C.

On 8/9/17 9:23 PM, Lee via dev-security-policy wrote:
> What's it going to take for mozilla to set up near real-time
> monitoring/auditing of certs showing up in ct logs?
>
> Lee
>
> On 8/9/17, Alex Gaynor via dev-security-policy
>  wrote:
>> (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
>> was to IdenTrust)
>>
>> Hi,
>>
>> The following certificates appear to be misissued:
>>
>> https://crt.sh/?id=77893170=cablint
>> https://crt.sh/?id=77947625=cablint
>> https://crt.sh/?id=78102129=cablint
>> https://crt.sh/?id=92235995=cablint
>> https://crt.sh/?id=92235998=cablint
>>
>> All of these certificates have a pathLenConstraint value with CA:FALSE,
>> this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
>> pathLenConstraint field unless the cA boolean is asserted and the key usage
>> extension asserts the keyCertSign bit.
>>
>> Alex
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right to
>> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>>
>>
>>
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right to
>> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

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

Faking a key compromise event with franken-keys

[J.C. Jones via dev-security-policy]

All,

Today Hanno Böck blogged about performing surgery on ASN.1-encoded RSA
private keys to make them appear to correspond to a target certificate's
public key, and using the franken-key file to appear to legitimately hold
the private key of that target certificate.

https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html

The franken-key is quite convincing to casual inspection. Always check when
making trust decisions.

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

Re: P-521

[J.C. Jones via dev-security-policy]

On Tue, Jun 27, 2017 at 1:49 PM, Tom .  wrote:

> On 27 June 2017 at 11:44, Alex Gaynor wrote:
> > I'll take the opposite side: let's disallow it before it's use expands
> :-)
>
> But is that what we're talking about? I didn't think the question was
> "Should we remove P-521 code from NSS" it's "Should we permit CAs to
> use P-521?"
>

Note: Forbidding P-521 by policy likely wouldn't prompt us to disable or
remove any code from NSS in any quick fashion; that curve is one of those
exported to WebCrypto, and we'd need to be sure we weren't breaking things
by pulling it from there.  Given the low usage of ECDH/ECDSA and the lack
of compatibility in Chrome, probably not, but we'd want to at least check.

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

Re: Final Decision by Google on Symantec

[J.C. Jones via dev-security-policy]

I share the desire to move faster than these dates, but upon
consideration, I don't think it's much of a boon to web security for
Mozilla to be substantially ahead of Chrome in implementing these trust
changes.

Since Chrome's decision to implement in April is final, their large user
population is exposed to any problem certificates until then; presumably
they believe the risk is low enough to proceed that way. No matter what
choice we make, the Web PKI as a whole has this nebulous danger until
Chrome's implementation date arrives.

If Firefox chooses to move faster, we'd need to educate users on why
some websites are functioning in Chrome but not in Firefox, for over 5
months. While we all know users need more education on security on the
Web, I don't want to spend their attention spans on this particular issue.

I think we should match Google's 17 April date.

(For the record: I am not swayed by this talk in July about avoiding Q4
configuration freezes; I absolutely agree with 1 December 2017 being a
practical cut-off date as long as the decision point is in the next
several days.)

J.C.


On 7/27/17 11:14 PM, Gervase Markham via dev-security-policy wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
>
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
>
> Gerv
>
>  Forwarded Message 
> Subject:  Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date: Thu, 27 Jul 2017 17:16:06 -0700
> From: Darin Fisher 
> To:   Darin Fisher 
> CC:   blink-dev 
>
>
>
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
>
>
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
>
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> proposal of August 2017 and Mozilla’s proposal for late 2017
> ,
> we think it hits an appropriate balance between the security risk to
> Chrome users and minimizing disruption to the ecosystem. This time will
> allow clear messaging and scheduling for site operators to update
> certificates.
>
>
> We considered a number of alternative dates for distrusting this subset
> of existing certificates before landing on Chrome 66. Given the scale of
> Symantec’s existing PKI and the impact to the ecosystem that these
> mitigations pose, one of our goals was to consider dates that gave site
> operators enough lead time, as well as to try to clear 

The State of CRLs Today

[J.C. Jones via dev-security-policy]

All,

As part of some related research, I did some analysis of availability,
size, and download latency of the CRLs currently known in Censys. There
are a number of CRLs missing, or whose DNS no longer resolves; a number
of graphs of size and latency, and the code.

https://tacticalsecret.com/the-state-of-crls/

Cheers,

J.C.

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

Ampersands in intermediates' PrintableString

[J.C. Jones via dev-security-policy]

All,

Just an interesting heads up:

While we were doing some maintenance on the CCADB, Chris Henderson found
Golang could not process several of Wells Fargo's intermediate CAs, such as:

   - sha256sum =
   3B8812E6F851B6F933DC23ED764082FB5F50DE3C2DDDEBCC9CA240B7ACACE4D1
   

  - https://crt.sh/?id=250864705=x509lint
   - sha256sum =
   3B8812E6F851B6F933DC23ED764082FB5F50DE3C2DDDEBCC9CA240B7ACACE4D1
   

   - https://crt.sh/?id=250864704=x509lint
   - sha256sum =
   D8D7627D0F5D0AD09155B2C9347307925EF3E7F6364F231969C0D2E4C71962F0
   

  - https://crt.sh/?id=254024589=ocsp,x509lint

This is because the organizationName field is typed as a PrintableString
but contains a character illegal in that type, the ampersand. This is
surely just a template typo during the issuance process, and since most
software is permissive to ASN.1 mistakes like this, it wouldn't have been
caught by casual inspection.

Notably, some of the intermediates are UTF8String, and thus compliant:

   - sha256sum =
   CF7CFA4F9DBCCBCA6D20EFDEBEAD4E173B34E76BDA1EB1E619F44E06E95FC208
   

  - https://crt.sh/?asn1=254978692

It also appears that the end-entity certificates issued from Wells Fargo's
intermediates are compliant.

Since Golang is very strict, it caught the constraint error. Chris has
opened Issue #22970  for Golang
to decide if it should be permissive or selectively permissive for this
case. (Interestingly, a year ago, Adam Langley scanned CT for these errrors
 and
found that ampersand is the big offender.)

Note that x509lint already catches this -- as is shown on the crt.sh links
above.

I'd encourage everyone in the Mozilla Root Program to use tools like
x509lint on certificates before making them operational. I think it'd also
be a good idea to, in the future, run these kinds of linting tools on new
intermediates added to the CCADB, and require remediation of some sort for
errors.

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

Re: Third party use of OneCRL

[J.C. Jones via dev-security-policy]

Niklas,

That's fine. Thanks for the heads up. Note that the format has a
possibility of changing some in 2018, but only in the way of adding fields,
not changing existing data.

Cheers,

J.C.
Crypto Engineering

On Thu, Dec 14, 2017 at 9:03 AM, niklas.bachmaier--- via
dev-security-policy  wrote:

> We are now ready to use the OneCRL in production. Approximately 2500 hosts
> would be requesting one OneCRL copy per day. Please let me know if this is
> not okay for you.
>
> Thanks a lot
> Niklas
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Plan to update CCADB PEM extraction tool

[J.C. Jones via dev-security-policy]

Ryan -

Originally the Observatory had "Subject+SPKI" hash field. Someone filed a
bug that Subject+SPKI field wasn't as useful for external comparisons as
the SPKI, and the Observatory changed over, replacing the old Subject+SPKI
hash with a pure SPKI hash.

We were proposing to switch to just the SPKI, simply because that is what
the Observatory is using today. However, there's no reason not to have the
Observatory provide the Subject+SPKI hash alongside the SPKI, and then we
can keep that field and effectively add the SPKI hash. That seems like a
good idea, for all the reasons David pointed out in 2016
.

Thanks for catching this!

Cheers,
J.C.

On Fri, Jun 1, 2018 at 11:57 AM, Julien Vehent via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think the revert was a mistake. I should have added the SPKI instead of
> replacing the Subject+SPKI with SPKI. (I don't recall the discussion at the
> time, but I think someone confused Subject+SPKI for SPKI and I meant to
> address the confusion).
>
> I'll re-add the subject+spki field, this time in addition to SPKI, and
> re-populate the DB.
>
> - Julien
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[J.C. Jones via dev-security-policy]

As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked
through it in the Validation Working Group. The ADN lookup is DNS, and what
you find when you connect there via TLS, within the certificate, should be
the random value (somewhere). 3.2.2.4.10 was written to permit ACME's
TLS-SNI-01 while being generic enough to permit CAs to accomplish the same
general validation structure without following the ACME-specified algorithm.

J.C.

On Thu, Jan 18, 2018 at 1:47 PM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01
> performs a DNS lookup for the ADN, connects to that IP, and initiatives a
> TLS connection with the .acme.invalid SNI value.
>
> Certificates don't exist on Domain Names if we think really hard about it,
> but servers with IPs that domain names point to can serve certificates, and
> that seems like a reasonable interpretation of the intent of that sentence,
> which TLS-SNI-01 fulfills.
>
> Alex
>
> On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Now that I'm more familiar with method 9 and 10 domain validation methods
> > and heard a few side discussions about the topic, it's made me (and
> others)
> > wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.
> >
> > The BRs say:
> > 3.2.2.4.10. TLS Using a Random Number
> > Confirming the Applicant's control over the FQDN by confirming the
> > presence of a Random Value within a Certificate on the Authorization
> Domain
> > Name which is accessible by the CA via TLS over an Authorized Port.
> >
> > But it's my understanding that the CA validates the presence of the
> random
> > number on "random.acme.invalid" and not on the ADN specifically.  Is the
> > validation done by confirming the presence of a random number within the
> > certificate on the ADN, or some other location?  I'm probably misreading
> > the ACME spec, but is sure seems like the validation is not being done on
> > the ADN.
> >
> > Doug
> >
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TLS-SNI-01 and compliance with BRs

[J.C. Jones via dev-security-policy]

That would be the right place. At the time there was not universal desire
for these validation mechanisms to be what I'd call 'fully specified'; the
point of having them written this way was to leave room for individuality
in meeting the requirements.

Of course, having a few carefully-specified-and-validated mechanisms
instead of individuality has worked rather well for other security-critical
operations, like the very transport security this whole infrastructure
exists to support. Perhaps that argument could be re-opened.

J.C.


On Thu, Jan 18, 2018 at 3:25 PM, Matthew Hardeman <mharde...@gmail.com>
wrote:

>
>
> On Thu, Jan 18, 2018 at 4:14 PM, J.C. Jones via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked
>> through it in the Validation Working Group. The ADN lookup is DNS, and
>> what
>> you find when you connect there via TLS, within the certificate, should be
>> the random value (somewhere). 3.2.2.4.10 was written to permit ACME's
>> TLS-SNI-01 while being generic enough to permit CAs to accomplish the same
>> general validation structure without following the ACME-specified
>> algorithm.
>>
>> J.C.
>
>
> I would presume that the CABforum would be the place to explore further
> details, but it seems that the specifications for the #10 method should be
> reexamined as to what assurances they actually provide with a view to
> revising those specifications.  At least 1 CA so far has found that the
> real world experience of a (presumably) compliant application of method #10
> as it exists today was deficient in mitigating the provision of
> certificates to incorrect/unauthorized parties.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy