Updating Production Common CA Database

[Kathleen Wilson]

All,

Starting Sunday afternoon (PDT), we will be updating the production instance of the Common CA Database (a.k.a. CA Community in Salesforce). This work will continue into Monday. The system will still be available during that time, but depending on when you access it or the corresponding reports, you may find some delays or inconsistencies.

Summary of changes:

- 'Signature Hash Algorithm' will have new drop down list: md2WithRSAEncryption, md5WithRSAEncryption, sha1WithRSAEncryption, sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption, ecdsaWithSHA256, ecdsaWithSHA384. ecdsaWithSHA521
- 'Public Key Algorithm' will have new drop down list: RSA 1024 bits, RSA 2048 bits, RSA 4096 bits, EC secp256r1, EC secp384r1, EC secp521r1
- 'Signature Algorithm' & 'Signing Key Parameters' will be deprecated
- 'Certificate ID' a new field will be added and auto populated. It identifies same logical certificate in different CA Hierarchies. SHA-256(der(subject) + der(spki)).
- 'Certificate Serial number' new field on root page will be added and auto populated
- 'CRl URl(s)' will be populated by urls ending with .crl only
- Minor rearrangements of fields will be made to root and intermediate page layouts
- A batch process will re-run PEM->JSON tool for all intermediate certs and populate PEM fields
- Another batch process will add PEM info to root certs and all PEM fields will be populated by the values returned by x509certChecker utility (PEM->JSON)
- 'Add/Update PEM info' button will be made available to root store managers who have write-access (currently only Mozilla and Microsoft)
- Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' will show the new fields instead.
- CSV Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' will show the new fields instead.

I apologize for any inconvenience caused during our upgrade, but I look forward to having these changes and the updated certificate fields for root and intermediate certs in production.

Kathleen

[Gervase Markham]

Hi Kathleen,

This generally all looks excellent, but:

On 25/09/16 00:02, Kathleen Wilson wrote:
> - 'CRl URl(s)' will be populated by urls ending with .crl only

There is no standard, AFAIK, which requires CRL URLs to end in ".crl".
File extensions indicating the file type were originally a Windows thing
and are a convenience, but they are not mandatory. What happens if a CA
is using a URL for their CRL which doesn't end in .crl? Will they not be
able to add it?

Gerv

[Kathleen Wilson]

The PEM data will get added, but the CRL field in Salesforce will be empty. We are using that field to aid in processing related to OneCRL.

Anyone who needs to get the CRL data directly (so they can get to the other CRL info), can use the CSV report that include the PEM data and can extract it themselves. (more info on the reports with PEM data coming soon)

Kathleen

[Kathleen Wilson]

> Summary of changes:
>
> - 'Signature Hash Algorithm' will have new drop down list: md2WithRSAEncryption, md5WithRSAEncryption, sha1WithRSAEncryption, sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption, ecdsaWithSHA256, ecdsaWithSHA384. ecdsaWithSHA521
> - 'Public Key Algorithm' will have new drop down list: RSA 1024 bits, RSA 2048 bits, RSA 4096 bits, EC secp256r1, EC secp384r1, EC secp521r1
> - 'Signature Algorithm' & 'Signing Key Parameters' will be deprecated
> - 'Certificate ID' a new field will be added and auto populated. It identifies same logical certificate in different CA Hierarchies. SHA-256(der(subject) + der(spki)).
> - 'Certificate Serial number' new field on root page will be added and auto populated
> - 'CRl URl(s)' will be populated by urls ending with .crl only
> - Minor rearrangements of fields will be made to root and intermediate page layouts
> - A batch process will re-run PEM->JSON tool for all intermediate certs and populate PEM fields
> - Another batch process will add PEM info to root certs and all PEM fields will be populated by the values returned by x509certChecker utility (PEM->JSON)
> - 'Add/Update PEM info' button will be made available to root store managers who have write-access (currently only Mozilla and Microsoft)

The changes listed above have been completed.

> - Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' will show the new fields instead.
> - CSV Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' will show the new fields instead.

The reports are still being updated. Some additional changes to the reports:
- Replacing SHA1 Fingerprint with SHA256 Fingerprint
- Adding Cert Serial Number and CertID

Kathleen

[Rob Stradling]

Hi Kathleen.

"Certificate ID" seems like entirely the wrong name for this field,
given that it [SHA-256(der(subject) + der(spki))] doesn't actually
identify a unique certificate! Indeed, the whole point of having this
field seems to be to identify _multiple_ related certificates.

Why not call it "SHA-256(Subject + SPKI)" instead?

On 26/09/16 18:01, Kathleen Wilson wrote:
>> Summary of changes:
>>
>> - 'Signature Hash Algorithm' will have new drop down list: md2WithRSAEncryption, md5WithRSAEncryption, sha1WithRSAEncryption, sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption, ecdsaWithSHA256, ecdsaWithSHA384. ecdsaWithSHA521
>> - 'Public Key Algorithm' will have new drop down list: RSA 1024 bits, RSA 2048 bits, RSA 4096 bits, EC secp256r1, EC secp384r1, EC secp521r1
>> - 'Signature Algorithm' & 'Signing Key Parameters' will be deprecated
>> - 'Certificate ID' a new field will be added and auto populated. It identifies same logical certificate in different CA Hierarchies. SHA-256(der(subject) + der(spki)).
>> - 'Certificate Serial number' new field on root page will be added and auto populated
>> - 'CRl URl(s)' will be populated by urls ending with .crl only
>> - Minor rearrangements of fields will be made to root and intermediate page layouts
>> - A batch process will re-run PEM->JSON tool for all intermediate certs and populate PEM fields
>> - Another batch process will add PEM info to root certs and all PEM fields will be populated by the values returned by x509certChecker utility (PEM->JSON)
>> - 'Add/Update PEM info' button will be made available to root store managers who have write-access (currently only Mozilla and Microsoft)
>

> The changes listed above have been completed.
>
>

>> - Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' will show the new fields instead.
>> - CSV Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' will show the new fields instead.
>
>

> The reports are still being updated. Some additional changes to the reports:
> - Replacing SHA1 Fingerprint with SHA256 Fingerprint
> - Adding Cert Serial Number and CertID

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Kathleen Wilson]

> "Certificate ID" seems like entirely the wrong name for this field,
> given that it [SHA-256(der(subject) + der(spki))] doesn't actually
> identify a unique certificate!
> Indeed, the whole point of having this
> field seems to be to identify _multiple_ related certificates.

Correct

> Why not call it "SHA-256(Subject + SPKI)" instead?

That doesn't leave room for changing the algorithm if we decide it needs to be changed to better identify the same logical certs.

I'm open to suggestions on a better name.

Kathleen

[Peter Bowen]

How about CA ID?

On Sep 26, 2016 16:26, "Kathleen Wilson" <kwi...@mozilla.com> wrote:

> > "Certificate ID" seems like entirely the wrong name for this field,
> > given that it [SHA-256(der(subject) + der(spki))] doesn't actually
> > identify a unique certificate!
> > Indeed, the whole point of having this
> > field seems to be to identify _multiple_ related certificates.
>

> Correct

>
> > Why not call it "SHA-256(Subject + SPKI)" instead?
>

> That doesn't leave room for changing the algorithm if we decide it needs
> to be changed to better identify the same logical certs.
>
> I'm open to suggestions on a better name.
>
> Kathleen

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

[Jakob Bohm]

Just a fact correction:

File extension usage was very present in UNIX and VAX/VMS early on.
For example the original UNIX make command used file extensions to
determine how to process files, while VAXen used the file extensions at
least to identify shell scripts. (This is mostly from anecdotal
evidence, as I have not studied those systems in enough detail to be
sure).

Microsoft Windows may or may not have been the first system that
extended general extension-linked handling rules to the end user
interface from technical uses such as make.

These days, file extension keyed file type handling is standard
behavior of web servers, web browsers (for files not received with a
mime-type, like ftp: and file: URLs) and many other software systems.


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

[Kathleen Wilson]

> > - Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' will show the new fields instead.
> > - CSV Reports which use 'Signature Algorithm'/ 'Signing Key Parameters' will show the new fields instead.
>
>
> The reports are still being updated. Some additional changes to the reports:
> - Replacing SHA1 Fingerprint with SHA256 Fingerprint
> - Adding Cert Serial Number and CertID
>

The reports have been updated, and new reports added:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReportPEMCSV
https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReportPEMCSV
https://mozillacaprogram.secure.force.com/CA/UpcomingRootRemovalsReportPEMCSV

The wiki pages https://wiki.mozilla.org/CA:IncludedCAs and https://wiki.mozilla.org/CA:RemovedCAcerts have been updated with links to these new reports.

Will look into changing "Certificate ID" to "CA ID".

Kathleen

[Rob Stradling]

On 27/09/16 00:26, Kathleen Wilson wrote:
>> "Certificate ID" seems like entirely the wrong name for this field,
>> given that it [SHA-256(der(subject) + der(spki))] doesn't actually
>> identify a unique certificate!
>> Indeed, the whole point of having this
>> field seems to be to identify _multiple_ related certificates.
>

> Correct

>
>> Why not call it "SHA-256(Subject + SPKI)" instead?
>

> That doesn't leave room for changing the algorithm if we decide it needs to be changed to better identify the same logical certs.
>
> I'm open to suggestions on a better name.

How about "CA Fingerprint"?

Peter's "CA ID" suggestion is definitely better than "Certificate ID".
However, since crt.sh already has an integer "CA ID" field, I'd prefer
to call this Salesforce field "CA Fingerprint" to avoid potential
confusion for folks who use both systems.

[Kathleen Wilson]

On Tuesday, September 27, 2016 at 3:12:20 AM UTC-7, Rob Stradling wrote:
> How about "CA Fingerprint"?
>
> Peter's "CA ID" suggestion is definitely better than "Certificate ID".
> However, since crt.sh already has an integer "CA ID" field, I'd prefer
> to call this Salesforce field "CA Fingerprint" to avoid potential
> confusion for folks who use both systems.

I've added to our to-do list: Change "Certificate ID" to "CA Fingerprint".

Thanks,
Kathleen