Plan to update CCADB PEM extraction tool

[Kathleen Wilson]

All,

We are working towards updating the tool that we use in the CCADB to
parse PEM data and fill in the corresponding fields in the CCADB. The
new tool is in the TLS Observatory:

https://github.com/mozilla/tls-observatory

Example:
curl https://tls-observatory.services.mozilla.com/api/v1/certificate -F
certificate=@/tmp/certificate.pem

There are some differences in the data that will result when we switch
to the new tool. Please let me know if you foresee problems with any of
these changes.

1) Certificate Serial Number
New value is upper case. (e.g. old: 35def4cf, new: 35DEF4CF)
The new data should be more correct in regards to handling of leading zeros.

2) SHA-1 Fingerprint and SHA-256 Fingerprint
Removing the colons.
OLD:
08:29:7A:40:47:DB:A2:36:80:C7:31:DB:6E:31:76:53:CA:78:48:E1:BE:BD:3A:0B:01:79:A7:07:F9:2C:F1:78
NEW: 08297A4047DBA23680C731DB6E317653CA7848E1BEBD3A0B0179A707F92CF178

3) Certificate ID
OLD: hash(Subject + SPKI), with colons
NEW: hash(SPKI), no colons
OLD:
4F:31:A6:06:59:45:EA:BC:6A:45:CB:AD:72:D8:0A:20:A4:40:0E:55:05:B9:2A:0C:4C:F1:F6:C1:A3:10:92:9F
NEW: FF5680CD73A5703DA04817A075FD462506A73506C4B81A1583EF549478D26476

4) Signature Hash Algorithm

OLD Values:
ecdsaWithSHA256
ecdsaWithSHA384
md5WithRSAEncryption
sha1WithRSAEncryption
sha256WithRSAEncryption
sha384WithRSAEncryption
sha512WithRSAEncryption


NEW Values:
ecdsaWithSHA256
ecdsaWithSHA384
MD5WithRSA
SHA1WithRSA
SHA256WithRSA
SHA384WithRSA
SHA512WithRSA

5) Key Usage

OLD Values:
cRLSign
digitalSignature
nonRepudiation
keyAgreement
keyEncipherment
keyCertSign

NEW Values:
CRL Sign
Digital Signature
Non Repudiation
Key Encipherment
Certificate Sign
Key Agreement


6) Extended Key Usage

OLD Values:
1.3.6.1.5.5.7.3.9
1.3.6.1.5.5.7.3.5
1.3.6.1.5.5.7.3.6
1.3.6.1.5.5.7.3.7
clientAuth
codeSigning
emailProtection
serverAuth
1.2.840.113583.1.1.5
msSGC
nsSGC

NEW Values:
ExtKeyUsageOCSPSigning
ExtKeyUsageIPSECEndSystem
ExtKeyUsageIPSECTunnel
ExtKeyUsageIPSECUser
ExtKeyUsageClientAuth
ExtKeyUsageCodeSigning
ExtKeyUsageEmailProtection
ExtKeyUsageServerAuth
ExtKeyUsageTimeStamping
ExtKeyUsageMicrosoftServerGatedCrypto
ExtKeyUsageNetscapeServerGatedCrypto


7) Technically Constrained
Checkbox will be updated according to Mozilla's current policy (e.g. EKU
*and* Name Constraints)

Thanks,
Kathleen

[Ryan Sleevi]

On Thu, May 31, 2018 at 6:54 PM, Kathleen Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> All,
>
> We are working towards updating the tool that we use in the CCADB to parse
> PEM data and fill in the corresponding fields in the CCADB. The new tool is
> in the TLS Observatory:
>
> https://github.com/mozilla/tls-observatory
>

> 3) Certificate ID
> OLD: hash(Subject + SPKI), with colons
> NEW: hash(SPKI), no colons
> OLD: 4F:31:A6:06:59:45:EA:BC:6A:45:CB:AD:72:D8:0A:20:A4:40:0E:55:
> 05:B9:2A:0C:4C:F1:F6:C1:A3:10:92:9F
> NEW: FF5680CD73A5703DA04817A075FD462506A73506C4B81A1583EF549478D26476
>

Thanks for the heads up. Could you explain why the change to just SPKI?

[Ryan Sleevi]

(For context,
https://github.com/mozilla/tls-observatory/commit/a8124ad65cb6f7ea8aca9648bc8985157a2a84a4#diff-738e6d4c59e010e98c704b9802751ebe
was the change, but it didn't document the motivation)

[Julien Vehent]

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

[J.C. Jones]

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
<https://github.com/mozilla/tls-observatory/issues/144>.

Thanks for catching this!

Cheers,
J.C.

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

[Ryan Sleevi]

Ah, thanks! I was trying to figure out the context if it was a bug or
intentional - sounds like the former, in which case, all is well :)

[Kathleen Wilson]

I would like to replace the old "Certificate ID" field with the
following two fields, because they are useful in different situations,
and the new field names are clear about what the values are.

SPKI SHA256
Subject + SPKI SHA256


Also, I am seeing differences in the following fields for a few certs --
the certs that have multiple values for CN, O, and OU. Please let me
know if you foresee any problems with such deltas.

For example:

Issuer Common Name NEW: Posta CA Root
Issuer Common Name OLD: Configuration

Subject Common Name NEW: Experian Root CA
Subject Common Name OLD: Configuration

Subject Organization Unit NEW: Symantec Trust Network, Class 2 Managed
PKI Individual Subscriber CA
Subject Organization Unit OLD: Symantec Trust Network

Subject Organization NEW: Leidos, PKI
Subject Organization OLD: Leidos


Thanks,
Kathleen