Closed Bug 1465613 Opened 6 years ago Closed 5 years ago

Add ability to distrust certificates issued after a certain date for a specified root cert

Categories

(NSS :: CA Certificates Code, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: marcus.apb)

References

Details

Attachments

(2 files)

Please add the ability to distrust new certificates issued after a certain date for a specified root cert and trust bit.

We regularly have the problem of a CA wanting to retire a root certificate by not issuing certs after a specified date, yet the existing certs are still valid for a year or more. The problem is that we require annual audits for any root certificate to remain in the NSS root store, but CAs and auditors don't want to get/do the required audit statements when no certs have been issued within a CA hierarchy during the audit period.

It would be best if this ability is directly in NSS, so that all users of NSS can benefit from it. And so we don't have to add such roots to https://wiki.mozilla.org/CA/Additional_Trust_Changes
Assignee: nobody → marcus.apb
Status: NEW → ASSIGNED
QA Contact: kwilson

Hi,

It was developed two new fields for the builtins certificates:
CKA_NSS_SERVER_DISTRUST_AFTER
CKA_NSS_EMAIL_DISTRUST_AFTER

This fields are mandatory for all entries and should receive a timestamp encoded in DER format.

  • It was added a new parameter (-d) in addbuiltin to facilitate the definition of the content in this fields.
    When not defined, this field should be a CK_BBOOL CK_FALSE.
    When defined the value for this field should be stored in OCTAL format.

This new fields should be defined in the “Certificate” entry of certdata.txt. This area is less susceptible to changes when compared with the “Trust” area and there are more functions to work with it among the components, reducing the necessary effort to adopt this new feature by the clients.

certutil -L also received a small improvement to permit visualise this fields, when set.

Thanks,

Depends on: 1568886
No longer depends on: 1568886
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 3.47
Depends on: 1589810

Hello Marcus,

Thank you for implementing this; I'm trying to port it to p11-kit so ca-certificates package in Fedora can preserve those attributes.
One difficulty doing this is that those attributes don't have a consistent type (CK_BBOOL or CK_BYTE[]) from PKCS #11 point of view. Why not define them as CK_DATE, which allows an empty value if it is not set?

Hi Daiki,

Nice. As we put in the documentation, these chosen was based in compatibility with other existing functions, to read dates, for instance.
The CK_BBOOL is used only where the data is not set and can be ignored.

The are some comments and documentations about this here:
https://searchfox.org/mozilla-central/source/security/nss/lib/certdb/certt.h#145
https://searchfox.org/mozilla-central/source/security/nss/lib/ckfw/builtins/README#67

Thank you for the explanation, Marcus. So if I understand correctly, the value can be either a single byte ("\x00") or a UTCTime string in the 13-digit format. I've proposed changes for p11-kit upstream and ca-certificate package in Fedora:
https://github.com/p11-glue/p11-kit/pull/265
https://src.fedoraproject.org/rpms/ca-certificates/pull-request/4

It would be great if you could take a quick look at them.

I've been trying to run down an issue I've been having, and I think this bug is the source. Whenever I build ('gmake' build), I get the following untracted files:
? lib/ckfw/builtins/testlib/anchor.o
? lib/ckfw/builtins/testlib/bfind.o
? lib/ckfw/builtins/testlib/binst.o
? lib/ckfw/builtins/testlib/bobject.o
? lib/ckfw/builtins/testlib/bsession.o
? lib/ckfw/builtins/testlib/bslot.o
? lib/ckfw/builtins/testlib/btoken.o
? lib/ckfw/builtins/testlib/ckbiver.o
? lib/ckfw/builtins/testlib/constants.o

This is because of the way lib/ckfw/builtins/testlib works, it uses the sources from the directory below, and explicitly reference them with ../{source_name}.c. The object file then becomes lib/ckfw/builtins/testlib/{OBJDIR}/../{source_name}.o.

The simple fix would be to paper over the issue and just add these to .hgignore, but that would break our ability to build multiple platforms on a single source directory. I'll include a patch that fixes this issue.

bob

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: