826640 - addbuiltin -D should not disclose more information than necessary to distrust the affected cert

Status: NEW

(NSS :: Tools, defect, P5)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Here's an example distrust record generated by addbuiltin -D:

# Distrust <label>
# Issuer:  <issuer DN in text form>
# Serial Number: <serial number>
# Subject: <subject DN>
# Not Valid Before: <date>
# Not Valid After : <date>
# Fingerprint (MD5):  <md5 fingerprint>
# Fingerprint (SHA1): <sha1 fingerprint>
CKA_CLASS CK_OBJECT_CLASS CKO_NSS_TRUST
CKA_TOKEN CK_BBOOL CK_TRUE
CKA_PRIVATE CK_BBOOL CK_FALSE
CKA_MODIFIABLE CK_BBOOL CK_FALSE
CKA_LABEL UTF8 "<label>"
CKA_ISSUER MULTILINE_OCTAL
<issuer DN in octal>
END
CKA_SERIAL_NUMBER MULTILINE_OCTAL
<serial number in octal>
END
CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_NOT_TRUSTED
CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_NOT_TRUSTED
CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_NOT_TRUSTED
CKA_TRUST_STEP_UP_APPROVED CK_BBOOL CK_FALSE

Although generally we want to disclose as much information as possible regarding CA mis-issuances, it is also the case that sometimes disclosing some details may make the situation worse. For example, if we disclose the subject DN of a mis-issued intermediate certificate, then third parties may use that information to target the owner of the mis-issued certificate, to steal the private key and the cert so that they can use the mis-issued cert for their own attacks.

The patches for certdata.txt are the public indication we give of any problem, and we generally need to land them ASAP after being notified of a problem. That will likely be before we're comfortable with the security of the private key of the problematic certificate. Consequently, we should limit the amount of information our patches disclose. Namely, we should remove these parts of the distrust record:

# Subject: <subject DN>
# Not Valid Before: <date>
# Not Valid After : <date>
# Fingerprint (MD5):  <md5 fingerprint>
# Fingerprint (SHA1): <sha1 fingerprint>

This would make the end result look like this:

# Distrust <label>
# Issuer:  <issuer DN in text form>
# Serial Number: <serial number>
CKA_CLASS CK_OBJECT_CLASS CKO_NSS_TRUST
CKA_TOKEN CK_BBOOL CK_TRUE
CKA_PRIVATE CK_BBOOL CK_FALSE
CKA_MODIFIABLE CK_BBOOL CK_FALSE
CKA_LABEL UTF8 "<label>"
CKA_ISSUER MULTILINE_OCTAL
<issuer DN in octal>
END
CKA_SERIAL_NUMBER MULTILINE_OCTAL
<serial number in octal>
END
CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_NOT_TRUSTED
CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_NOT_TRUSTED
CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_NOT_TRUSTED
CKA_TRUST_STEP_UP_APPROVED CK_BBOOL CK_FALSE

Also, we should implement bug 734047 and even require that the auto-generated nickname be used, to prevent ourselves from accidentally disclosing sensitive information in the nickname/label part of the record.

Finally, we should avoid adding bug numbers and other comments to these distrust records.

Note that this isn't an attempt to limit public disclosure of these issues permanently (which I am firmly against), but only temporarily during the time between the landing of the path and the time we're sure it is as safe as possible to disclose information about the issue.

Comment 1

[Robert Relyea]

I agree we should have an option which builds only the minimal data needed. We should discuss what the default should be, but we definitely should still have to ability to include the full data in distrust records.

The initial disclosure level should be part of the security response discussion.