Re: DigiCert-Symantec Announcement

2017-09-22 Thread Peter Bowen via dev-security-policy 
On Fri, Sep 22, 2017 at 6:22 AM, Nick Lamb via dev-security-policy
 wrote:
> On Friday, 22 September 2017 05:01:03 UTC+1, Peter Bowen  wrote:
>> I realize this is somewhat more complex than what you, Ryan, or Jeremy
>> proposed, but it the only way I see root pins working across both
>> "old" and "new" trust stores.
>
> I would suggest that a better way to spend the remaining time would be 
> remedial work so that your business isn't dependant on a single third party 
> happening to make choices that are compatible with your existing processes. 
> Trust agility should be built into existing processes and systems, where it 
> doesn't exist today it must be retro-fitted, systems which can't be 
> retrofitted are an ongoing risk to the company's ability to deliver.
>
> Trust agility doesn't have to mean you give up all control, but if you were 
> in a situation where the business trusted roots from Symantec, Comodo and 
> say, GlobalSign then you would have an obvious path forwards in today's 
> scenario without also needing to trust dozens of organisations you've no 
> contact with.
>
> I know the Mozilla organisation has made this mistake itself in the past, and 
> I'm sure Google has too, but I don't want too much sympathy here to get in 
> the way of actually making us safer.

Nick,

I agree with pretty much everything you said :)

However, as you point out, many organisations have run into problems
in this area.  As a community, we saw similar issues come up during
the SHA-1 deprecation phase and seemed surprised.  I want to try to
make sure there is not surprise, especially when it comes to
configurations that are not obvious.

For example, on some mobile platforms it is common to have the app
enforce pinning but the OS handle chain building and validation.  This
can have poor interaction if the OS were to update the trust store as
the returned chain may no longer have the pinned CA.

Consider what Jeremy drew:

GeoTrust Primary Certification Authority -> DigiCert Global G2 -> (new
issuing CA) -> (end entity)

If the platform trusts DigiCert Global G2, then the chain that is
returned to the application will be:

DigiCert Global G2 -> (new issuing CA) -> (end entity)

In this case, any application pinned to GeoTrust will fail.

Even if it was a new Root:

GeoTrust Primary Certification Authority -> DigiCert GeoTrust G2 ->
(new issuing CA) -> (end entity)

The same problem will occur if the OS updates the trust store but the
application does not update.

One notable thing is that the server operator, application vendor, OS
vendor, and CA may be four unrelated parties.  If the application is
expected to work with "new" and "old" OS versions, this will take some
careful work if the keys in the built chain change over time.

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

Re: CAs not compliant with CAA CP/CPS requirement

2017-09-22 Thread Richard Moore via dev-security-policy 
On 22 September 2017 at 17:22, Rob Stradling 
wrote:

> On 22/09/17 17:07, Richard Moore via dev-security-policy wrote:
>
>> I see, the one I saw in the wild was issued from the intermediate below
>> and
>> linked to the Gandi document however it was from 2014. That said, I don't
>> see the intermediate in crt.sh though that could just be me failing to use
>> the site properly!
>>
> 
>
> That intermediate is https://crt.sh/?id=931
>
>
​Thanks Rob

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

Re: CAs not compliant with CAA CP/CPS requirement

2017-09-22 Thread Rob Stradling via dev-security-policy 

On 22/09/17 17:07, Richard Moore via dev-security-policy wrote:

I see, the one I saw in the wild was issued from the intermediate below and
linked to the Gandi document however it was from 2014. That said, I don't
see the intermediate in crt.sh though that could just be me failing to use
the site properly!



That intermediate is https://crt.sh/?id=931

--
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: CAs not compliant with CAA CP/CPS requirement

2017-09-22 Thread Richard Moore via dev-security-policy 
I see, the one I saw in the wild was issued from the intermediate below and
linked to the Gandi document however it was from 2014. That said, I don't
see the intermediate in crt.sh though that could just be me failing to use
the site properly!

Cheers

Rich.

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
5a:b6:1d:ac:1e:4d:a2:06:14:c7:55:3d:3d:a9:b2:dc
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=
http://www.usertrust.com, CN=UTN-USERFirst-Hardware
Validity
Not Before: Oct 23 00:00:00 2008 GMT
Not After : May 30 10:48:38 2020 GMT
Subject: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b6:54:3d:a5:db:0d:22:78:50:6a:5a:23:89:3f:
97:a1:d4:07:1a:a9:58:08:9b:a0:15:c3:32:b6:b7:
f1:e8:b9:a5:6f:ad:37:f6:6e:71:1b:b4:75:2d:48:
5e:9f:c6:15:aa:81:ef:e5:c4:88:95:8a:3a:6c:77:
cc:b5:cd:65:e4:67:e5:73:c9:50:52:94:c1:27:49:
3e:a0:6b:41:16:41:b6:94:99:41:ae:3e:cb:e2:06:
46:09:e9:4d:be:c9:4c:55:a9:18:7e:a6:df:6e:fd:
4a:b2:cc:6c:4e:d9:c8:50:15:93:b3:f2:e9:e3:c2:
6a:ad:3a:d5:fb:c3:79:50:9f:25:79:29:b2:47:64:
7c:20:3e:e2:08:4d:93:29:14:b6:34:6e:cf:71:46:
7e:76:10:f4:fd:6c:aa:01:d2:c2:06:de:92:83:cc:
58:90:2e:92:de:1e:65:b7:63:2f:3d:b2:eb:70:8c:
4c:e0:be:15:9d:de:c1:4d:56:f8:0b:c6:8e:07:b9:
5d:df:95:f0:7b:40:1f:1a:2c:d7:9c:2b:4b:76:f4:
59:f5:43:c1:2c:66:10:9e:9e:66:96:60:9d:1c:74:
1b:4e:18:5c:08:b0:6e:6c:ca:69:1a:02:e9:bb:ca:
78:ef:66:2e:e3:32:fd:41:5c:95:74:81:4d:f4:da:
fe:4b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:

keyid:A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45

X509v3 Subject Key Identifier:
B6:A8:FF:A2:A8:2F:D0:A6:CD:4B:B1:68:F3:E7:50:10:31:A7:79:21
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.26

X509v3 CRL Distribution Points:

Full Name:
  URI:http://crl.usertrust.com/UTN-USERFirst-Hardware.crl

Authority Information Access:
CA Issuers - URI:
http://crt.usertrust.com/UTNAddTrustServer_CA.crt
OCSP - URI:http://ocsp.usertrust.com

Signature Algorithm: sha1WithRSAEncryption
 19:53:bf:03:3d:9b:e2:6b:5a:fd:ba:49:1f:4f:ec:e1:c6:82:
 39:3c:d2:03:04:0f:ab:7b:3e:82:a9:85:10:1f:f4:de:32:af:
 58:3f:ff:70:f3:30:1d:97:2d:4c:9a:e2:ec:0c:3e:14:2d:2f:
 98:48:9d:ae:16:6a:ac:2d:42:aa:b5:64:a4:70:bb:eb:73:94:
 7b:46:4c:e7:7a:14:76:5b:4c:1d:84:a1:20:74:1f:2e:4b:5c:
 70:88:dc:bd:f7:19:3d:ed:59:0d:e2:3f:26:e2:9c:ac:a4:3c:
 95:1c:f8:be:8c:03:ae:f0:e5:9c:4d:bc:c7:9b:58:00:bf:af:
 ad:fa:37:6e:71:6d:18:34:0e:c1:ea:6a:f8:0d:df:69:54:56:
 15:f2:28:b3:fe:a4:63:ec:c5:04:64:60:bb:fe:2a:f0:f4:87:
 a1:b0:ae:bd:aa:e4:2f:e3:03:0b:2f:66:5f:85:a4:32:7b:46:
 ed:25:0c:e7:f1:b7:e7:19:fd:60:ba:5f:87:77:de:98:07:96:
 e4:5e:ea:63:7d:a8:de:55:da:61:5c:3c:90:83:43:04:07:3c:
 dd:f3:f8:9f:06:52:0a:de:c7:b6:7b:8f:e1:11:f7:04:7a:35:
 ff:6a:bc:5b:c7:50:49:08:70:6f:94:43:cd:9e:c7:70:f1:db:
 d0:6d:da:8f
-BEGIN CERTIFICATE-
MIIEozCCA4ugAwIBAgIQWrYdrB5NogYUx1U9Pamy3DANBgkqhkiG9w0BAQUFADCB
lzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2Ug
Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho
dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3Qt
SGFyZHdhcmUwHhcNMDgxMDIzMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjBBMQswCQYD
VQQGEwJGUjESMBAGA1UEChMJR0FOREkgU0FTMR4wHAYDVQQDExVHYW5kaSBTdGFu
ZGFyZCBTU0wgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2VD2l
2w0ieFBqWiOJP5eh1AcaqVgIm6AVwzK2t/HouaVvrTf2bnEbtHUtSF6fxhWqge/l
xIiVijpsd8y1zWXkZ+VzyVBSlMEnST6ga0EWQbaUmUGuPsviBkYJ6U2+yUxVqRh+
pt9u/UqyzGxO2chQFZOz8unjwmqtOtX7w3lQnyV5KbJHZHwgPuIITZMpFLY0bs9x
Rn52EPT9bKoB0sIG3pKDzFiQLpLeHmW3Yy89sutwjEzgvhWd3sFNVvgLxo4HuV3f
lfB7QB8aLNecK0t29Fn1Q8EsZhCenmaWYJ0cdBtOGFwIsG5symkaAum7ynjvZi7j
Mv1BXJV0gU302v5LAgMBAAGjggE+MIIBOjAfBgNVHSMEGDAWgBShcl8mGyiYQ5Vd
BzfVhZadS9LDRTAdBgNVHQ4EFgQUtqj/oqgv0KbNS7Fo8+dQEDGneSEwDgYDVR0P
AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEE
AbIxAQICGjBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5j

Re: CAs not compliant with CAA CP/CPS requirement

2017-09-22 Thread Rob Stradling via dev-security-policy 

On 21/09/17 22:56, richmoore44--- via dev-security-policy wrote:

On Thursday, September 21, 2017 at 10:13:56 AM UTC+1, Rob Stradling wrote:

Our CPS has now been updated.


Will you be ensuring that CAs like Gandi who are chaining back to your roots 
also update their CPS?


Gandi are a managed CA.  We are chasing them up and will get them to 
link through to Comodo's legal repository.


https://www.gandi.net/static/docs/en/gandi-certification-practice-statement.pdf 
is a deprecated document.  A different CPS URL (that takes you to 
Comodo's CPS) is being included in new certificates.  See 
https://crt.sh/?Identity=%25=1593 and 
https://crt.sh/?Identity=%25=1575 for examples.


--
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: DigiCert-Symantec Announcement

2017-09-22 Thread Nick Lamb via dev-security-policy 
On Friday, 22 September 2017 05:01:03 UTC+1, Peter Bowen  wrote:
> I realize this is somewhat more complex than what you, Ryan, or Jeremy
> proposed, but it the only way I see root pins working across both
> "old" and "new" trust stores.

I would suggest that a better way to spend the remaining time would be remedial 
work so that your business isn't dependant on a single third party happening to 
make choices that are compatible with your existing processes. Trust agility 
should be built into existing processes and systems, where it doesn't exist 
today it must be retro-fitted, systems which can't be retrofitted are an 
ongoing risk to the company's ability to deliver.

Trust agility doesn't have to mean you give up all control, but if you were in 
a situation where the business trusted roots from Symantec, Comodo and say, 
GlobalSign then you would have an obvious path forwards in today's scenario 
without also needing to trust dozens of organisations you've no contact with.

I know the Mozilla organisation has made this mistake itself in the past, and 
I'm sure Google has too, but I don't want too much sympathy here to get in the 
way of actually making us safer.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

2017-09-22 Thread Nikos Mavrogiannopoulos via dev-security-policy 
On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky  wrote:
> Dear Nikos
>
> On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos 
> wrote:
>>
>>
>> 4. How do you handle extensions to this format?
>>
>> Overall, why not use X.509 extensions to store such additional
>> constraints? We already (in the p11-kit trust store in Fedora/RHEL
>> systems) use the notion of stapled extensions to limit certificates
>> [0, 1] and seems quite a flexible approach. Have you considered that
>> path?
>>
>> regards,
>> Nikos
>>
>> [0].
>> https://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html
>> [1].
>> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html
> I've looked through the specification. It's OK for me, but I do not get
> whether the attached extensions are crypto-protected.

No, as these values are inserted by the administrator of the system,
or us (the distributor of the software), we didn't feel we needed the
introduction of additional PKI.

How do you see the infrastructure on the
draft-belyavskiy-certificate-limitation-policy? Who do you envision
signing these structures? (I assume that distribution of data will be
done by software distributors?)

>> 4. How do you handle extensions to this format?
>>
> Simillary to CRL. Do you have ideas of the extensions?

One problem with that is the fact that the existing CRL extensions are
about extending attributes of the CRL, rather than adding/removing
attributes to the certificate in question.

To bring the stapled extensions to your proposal, you'd need the
Extensions and Extension fields from RFC5280, and
add into limitedCertificates structure (I'll split it on the example
below for clarity) the following field.

LimitedCertificates  ::=   SEQUENCE OF LimitedCertificate

LimitedCertificate ::= SEQUENCE {
userCertificate CertificateSerialNumber,
certificateIssuer   Name,
limitationDate  Time,
limitationPropagation   Enum,
fingerprint SEQUENCE {
fingerprintAlgorithm AlgorithmIdentifier,
fingerprintValue OCTET STRING
 } OPTIONAL,
limitations  SEQUENCE,
   } OPTIONAL,
 };


stapledExtensions Extensions; <- NEW
}


Another difference between this profile and the p11-kit one, is that
the extensions/revocation here is done on the certificate, while in
p11-kit is done on the public key. Both approaches have pros and cons.

Another question. I also noticed the fingerprint field above. Is that
to distinguish between same CAs with different keys? In that case
using the SubjectPublicKeyIdentifier may be sufficient, and more
natural as this is how certificates with matching DNs/serials are
distinguished.

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