Re: PROCERT issues

2017-09-29 Thread Eric Mill via dev-security-policy 
On Thu, Sep 28, 2017 at 12:50 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 27/09/17 18:54, Matthew Hardeman wrote:
> > In the case of StartCom, I can not help but feel that they are being
> > held to an especially high standard (higher than other prior adds to
> > the program) in this new PKI because of who they are -- despite the
> > fact that management and day-to-day decisions are a completely
> > different team.
> >
> > Where I am headed with this is a concern that perhaps no amount of
> > technical remediation can really get these entities back in the
> > graces of the community.
>
> I don't know if it's quite as absolute as that, but recent incidents
> have caused me to ponder somewhat on the nature of trust. The root
> program is all about trust, and trust is not something which can be
> encoded in audits, checkboxes and rules. This will always be a tension
> at the heart of our root program - we are trying to be as objective as
> we can about something which is ultimately subjective.
>
> The nature of trust is that it's harder to regain than it is to gain in
> the first place. Just ask someone who's been the victim of adultery - or
> someone who is a now-repentant adulterer. Rightly or wrongly, people get
> a first chance, but it's tough to get a second. I think you are right
> when you conclude that this is just the way of things, and we should
> accept it rather than kick against it.
>

That dynamic is natural, but accepting that this dynamic exists is
different than giving into it in some absolute way. When offering second
chances, requiring that the person/org fulfill certain conditions that
speak directly to their ability to have learned and adapted from the thing
they failed at the first time is an approach that accepts this dynamic,
without shutting the door on people or organizations that have grown as a
result of the experience.

I think it would arguably lead to worse behavior, and less disclosure of
incidents and mistakes, if Mozilla adopted a posture where second chances
are rarely given. Not saying that's what's being said here, but I think
it's worth emphasizing that the first principle here should be to optimize
for incentivizing the behavior you want out of the CA community that
protects users and increases information sharing.

-- Eric


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



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

Doppelganger/tripleganger intermediate certificates

2017-09-29 Thread Rob Stradling via dev-security-policy 
Several CAs have issued intermediate CA certificates with duplicate 
serial numbers.  This is a clear violation of the serial number 
uniqueness requirement of the BRs and RFC5280 4.1.2.2.  Below is a list 
of all those known to crt.sh that chain to at least 1 NSS built-in root:



Issuer: https://crt.sh/?caid=140
  Issuer O: AC Camerfirma SA CIF A82743287
 Issuer CN: Chambers of Commerce Root
Subject CN: (id=1252) AC CAMERFIRMA AAPP
(id=12625404) AC Camerfirma Express Corporate Server
  Serial #: 0d
 Certs: https://crt.sh/?id=1252
https://crt.sh/?id=12625404
  Revoked?: No


Issuer: https://crt.sh/?caid=935
  Issuer O: Actalis S.p.A./03358520967
 Issuer CN: Actalis Authentication Root CA
Subject CN: UniCredit Subordinate External
  Serial #: 3e:5d:be:44:e7:51:5a:5a
 Certs: https://crt.sh/?id=47081615
https://crt.sh/?id=147626411
  Revoked?: No


Issuer: https://crt.sh/?caid=941
  Issuer O: Atos
 Issuer CN: Atos TrustedRoot 2011
Subject CN: Atos TrustedRoot Client-CA 2011
  Serial #: 5b:6a:8e:8d:5a:86:71:8f
 Certs: https://crt.sh/?id=12725513
https://crt.sh/?id=12725727
https://crt.sh/?id=12728899
  Revoked?: No
Subject CN: Atos TrustedRoot CodeSigning-CA 2011
  Serial #: 33:45:52:39:ec:16:dd:62
 Certs: https://crt.sh/?id=18068233
https://crt.sh/?id=49643406
  Revoked?: Yes
Subject CN: Atos TrustedRoot Server-CA 2011
  Serial #: 6b:5d:91:bc:13:61:ce:75
 Certs: https://crt.sh/?id=705899
https://crt.sh/?id=18068212
  Revoked?: Yes


Issuer: https://crt.sh/?caid=138
  Issuer O: SwissSign AG
 Issuer CN: SwissSign Gold CA - G2
Subject CN: AffirmTrust Networking
  Serial #: 84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9
 Certs: https://crt.sh/?id=3386
https://crt.sh/?id=1991456
  Revoked?: No
Subject CN: Trend Micro Gold CA
  Serial #: 49:e1:33:6e:94:e5:b6:a5:2d:a9:6e:d4:8a:e2:76
 Certs: https://crt.sh/?id=12629343
https://crt.sh/?id=198226194
  Revoked?: Yes


Issuer: https://crt.sh/?caid=656
  Issuer O: Trustwave Holdings, Inc.
 Issuer CN: Trustwave Organization Issuing CA, Level 2
Subject CN: Trustwave Enterprise CA
  Serial #: 6b:49:d2:04
 Certs: https://crt.sh/?id=12624965
https://crt.sh/?id=12629351
  Revoked?: Issuer cert revoked (https://crt.sh/?id=95565)

Issuer: https://crt.sh/?caid=12391
  Issuer O: Trustwave Holdings, Inc.
 Issuer CN: Trustwave Enterprise CA
Subject CN: Trustwave Enterprise VPN CA
  Serial #: 41:90:ae:5d
 Certs: https://crt.sh/?id=12625419
https://crt.sh/?id=12629788
  Revoked?: Issuer's issuer cert revoked (https://crt.sh/?id=95565)


Issuer: https://crt.sh/?caid=1450
  Issuer O: WoSign CA Limited
 Issuer CN: CA 沃通根证书
Subject CN: 中国湖南 EV 服务器证书
  Serial #: 44:80:7b:20:7c:f2:05:2e:8d:34:11:77:02:66:d2:95
 Certs: https://crt.sh/?id=7841622
https://crt.sh/?id=9318242
  Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots 
still in NSS)

Subject CN: CA 沃通 EV 代码签名证书
  Serial #: 3a:de:c4:02:27:0b:f4:ee:9e:89:2c:c6:5e:0a:da:21
 Certs: https://crt.sh/?id=12728869
https://crt.sh/?id=12729072
  Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots 
still in NSS)



P.S. Here's the query I ran on crt.sh to find these certs:

select count(*), min(c.id), max(c.id), c.issuer_ca_id, 
encode(x509_serialNumber(c.certificate), 'hex') from certificate c, 
ca_certificate cac where c.id=cac.certificate_id and exists (select 1 
from ca_trust_purpose ctp where ctp.ca_id = c.issuer_ca_id and 
ctp.trust_context_id=5) group by c.issuer_ca_id, 
x509_serialNumber(c.certificate) having count(*) > 1 order by count(*) desc;


--
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: Incident Report format

2017-09-29 Thread Jakob Bohm via dev-security-policy 

On 28/09/2017 18:11, Gervase Markham wrote:

On 22/09/17 00:12, Ryan Sleevi wrote:

Based on the number of reports reviewed recently, I suspect we've got
opportunities for improvement, but I'm not quite sure yet what the concrete
suggestions on that should look like. A few thoughts below:


Here's a set of changes which attempt to capture some of what you are
requesting. Further input, from you or others, is welcome.

https://wiki.mozilla.org/index.php?title=CA%2FResponding_To_A_Misissuance&diff=1181405&oldid=1179230



Suggested minor additional improvements to this excellent document:

1. Title should also reflect that this is now about various kinds of
  incidents.

2. Opening paragraph should be split in two just before the definition
  of "misissuance".  A third paragraph should be added with a similar
  spirit definition of "Other examples of incidents include ...".

3. In the definition of "misissuance" it may be prudent to add wording
  to the effect that "revocation" at the request of the certificate
  subject due to events entirely under the the subjects control are
  typically not considered "misissuance", just routine revocation work.

4. Under "Follow-Up actions", second bullet, perhaps change "rigorous"
  to "frequent/rigorous".

5. Under "Incident Report", item 1, add "internal self-audit" as another
  example of discovery.  (I think the recent DigiCert reissue incident
  might be a good example of that happening).

6. Under "Incident Report", item 3, remove the word "TLS/SSL" to make
  the bullet point equally applicable to e-mail certs, OCSP certs etc.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal -- Specify audit criteria according to trust bit

2017-09-29 Thread Gervase Markham via dev-security-policy 
On 29/09/17 13:21, Peter Bachman wrote:
> Can I have a pointer to the current up to date discussion on the S/MIME trust 
> bit?

What sort of discussion? Mozilla's root store still includes an S/MIME
trust bit and we have no plans to remove it.

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

Re: PROCERT issues

2017-09-29 Thread okaphone.elektronika--- via dev-security-policy 
I'd say this implies two things.

First CAs should be wary of the possibility loosing trust. For 
reacting/responding timely and adequately to any concerns being raised, instead 
of ignoring them or waiting to "see how they develop", is  a lot easier than 
any alternative, I'd say.

The other thing is that it is makes sense that CAs (or people) who have lost 
trust will have to figure out themselves how to get back to trust. Like I said, 
it depends a lot on how exactly trust was lost in te first place.

And bottom line it is their problem, not Mozilla's. They created it, it is not 
reasonable to expect/ask a root program to prescribe how to do that.

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

Re: Policy Update Proposal -- Specify audit criteria according to trust bit

2017-09-29 Thread Peter Bachman via dev-security-policy 
Can I have a pointer to the current up to date discussion on the S/MIME trust 
bit?

I am participating in the 21st Century Cures trust framework discussion which 
involves the Direct Project that specified S/MIME as the primary conduit for 
communication. 

This project attempted to simplify health care secure transport over the 
Internet to avoid building expensive EHR interfaces between HIPAA covered 
entities using VPN.

Digicert was a major part of this effort as a certified provider through Direct 
Trust. Also a great deal of money was distributed under the economic stimulus 
for usage of Direct known as Meaningful Use 2.

The creative tension between web PKI and email PKI still exists since HL7 also 
has a web based approach known as FHIR which is under development.

Part of this problem frame also includes digital signatures and how they should 
be applied. As a result the originally fairly insecure approaches to Direct 
were upgraded by Direct Trust such as NIST LOA Level Three requirements and 
dual signing and encryption certificates required by the Federal Bridge.

In addition ETSI requirements have been developed for signing XML medical 
documents that are long lived and can survive PKI CA failure and still be 
legally binding.



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