Re: Symantec Response L

2017-04-16 Thread Peter Bachman via dev-security-policy
The 2017 ACES CP excluding anything other than citizen to E-gov breaks certain 
use cases that are outside the scope of Mozilla, but not from the standpoint of 
a fully functional commercial  c=US structure which I have developed since 1996 
since I reached an agreement with GSA on how to proceed after managing the  
c=US pilot and implementing X.509 for the National Labs in the Directory.

Specifically it blocks the development of a functional national patient and 
provider Directory structure in which relying parties require fully valid cross 
certified trust chains that was already developed with HHS. 

Invalid patient identity is at the heart of one of the leading causes of 
mortality in the US. Not reaching consensus on equipping end users with low 
cost affordable PKI in addition to browser security policy puts profit over 
human rights.

The only rational reason I can see for such a policy is to MITM at will medical 
records under the 702 Authorities, since end user implementation of PKI based 
tecnology in an end to end manner precludes business level meddling and trust, 
replaced by the original Diffie concept. As we know this is already the policy 
of the IETF and IAB to encrypt everything. But the policy mapping between these 
different use cases is perhaps overly complex and certainly not user friendly. 

Also the Blue Button MU2 used ACES in their trust bundle at one point and I 
checked yesterday for medical providers that already attested to MU2 SMTP/SMIME 
compliance and received Federal money under the recovery stimulus package and 
that's not limited to just the VA but the VA has used this very effectively. 

Browsers of course don't typically implement bi-directional TLS authenticating 
the client which is very useful in use cases related to maintaining data 
integrity in disaster situations for logging.

i checked the Identrust site and their ACES CP had poor user documentation with 
CP dated 2015. That's when I subsequently found your information which was up 
to date and very useful.

I see that the only remaining bug issue was to drop the cross certificate so 
that Mozilla users could not incorrectly validate,
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Response L

2017-04-16 Thread Eric Mill via dev-security-policy
For the benefit of the list, I'm the author of that text and that quote is
from this page, which is maintained by the General Services Administration
(though again, not by the Federal PKI team):

https://https.cio.gov/certificates/#does-the-us-
government-operate-a-publicly-trusted-certificate-authority%3f

The intended audience is federal agencies, and the intended takeaway is
that certificates from the Federal Common Policy CA should not be used for
TLS/HTTPS services where the expected client base is "the general public",
since the Federal PKI is not a member of the Mozilla root program.

Certificates from the Federal PKI can obviously be used where the client
base can be expected to trust its root CA, and there are many such uses of
the Federal PKI.

-- Eric

On Sun, Apr 16, 2017 at 8:50 PM, Peter Bachman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Since we use ACES certificates for sending healthcare information in a way
> that mimimizes MITM, I was surprised to read the following.
>
>
> "The Federal PKI has cross-certified other agencies and commercial CAs,
> which means their certificates will be trusted by clients that trust the
> Federal PKI. However, none of these roots are publicly trusted. Even when a
> publicly trusted commercial CA is cross-certified with the Federal PKI,
> they maintain complete separation between their publicly trusted
> certificates and their Federal PKI cross-certified certificates.
>
> As a result, there is not currently a viable way to obtain an individual
> certificate for use in TLS/HTTPS that is issued or trusted by the Federal
> PKI, and also trusted by the general public."
>
> Source CIO Council
>
>
>
> The new ACES CP dated Jan 17 2017 does not assure public use of the ACES
> root.
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
Eric Mill
Senior Advisor, Technology Transformation Service, GSA
eric.m...@gsa.gov, +1-617-314-0966 <(617)%20314-0966>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Response L

2017-04-16 Thread Peter Bachman via dev-security-policy
Since we use ACES certificates for sending healthcare information in a way that 
mimimizes MITM, I was surprised to read the following.


"The Federal PKI has cross-certified other agencies and commercial CAs, which 
means their certificates will be trusted by clients that trust the Federal PKI. 
However, none of these roots are publicly trusted. Even when a publicly trusted 
commercial CA is cross-certified with the Federal PKI, they maintain complete 
separation between their publicly trusted certificates and their Federal PKI 
cross-certified certificates.

As a result, there is not currently a viable way to obtain an individual 
certificate for use in TLS/HTTPS that is issued or trusted by the Federal PKI, 
and also trusted by the general public."

Source CIO Council



The new ACES CP dated Jan 17 2017 does not assure public use of the ACES root. 

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


Re: CloudFlare Issuing SHA-1 SSL Certificates

2017-04-16 Thread Nick Lamb via dev-security-policy
On Saturday, 15 April 2017 13:59:18 UTC+1, Samuel Pinder  wrote:
> Quite an interesting workaround to support older
> software, it's not exactly encouraging since SHA-1 collisions are now
> possible. I would expect that CloudFlare operate this solution on the
> condition that their customers are made aware of the risks, at the
> very least.

Your description of why this works, and why it isn't a concern to m.d.s.policy 
without some other context to make it so, is correct

However, although collision itself is enough reason to consider SHA-1 flawed 
and reject its use for new systems entirely, functionally a collision attack 
poses a risk only under very tightly defined conditions, thus:

A bad guy must be able to persuade the CA to sign a specific document whose 
content the bad guy chose in advance, so that the bad guy can then prepare a 
bad document with a colliding hash, whose signature would correctly be 
identical.

For the infamous MD5 certificate attack, a CA provided a web site where robots 
could order (and pay for) a great number of certificates with tightly specified 
contents until the CA filled in exactly what was desired and signed it. This is 
no longer possible for a BR-compliant CA today even if the hash used is flawed.

CloudFlare is not issuing certificates to a third party at all, they're either 
making these certificates themselves, or they have an API with the private CA 
which allows them to order such certificates on demand. In neither case is 
there a direct avenue for a bad guy to request the bogus certificate needed for 
a collision attack.

Because cryptographic attacks only get better with time, it would be foolish 
for us to assume this constraint protects the wider Web PKI and thus we needn't 
have acted so quickly on SHA-1 already, but it would _also_ be foolish to 
complain of a risk from something like CloudFlare's approach here.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy