Ben Laurie <[email protected]> wrote
Mon, 20 Oct 2014 12:09:48 +0000:
| On Fri Oct 17 2014 at 1:51:01 PM Linus Nordberg <[email protected]> wrote:
|
| > Hi list,
| >
| > 6962bis-4 says that logs may log and publish invalid certificates as
| > long as the chain ends in a known cert. It then lists three examples of
| > what can be accepted, all related to time.
| >
| > Logs MUST verify that the submitted end-entity certificate or
| > Precertificate has a valid signature chain leading back to a trusted
| > root CA certificate, using the chain of intermediate CA certificates
| > provided by the submitter. Logs MAY accept certificates that have
| > expired, are not yet valid, have been revoked, or are otherwise not
| > fully valid according to X.509 verification rules in order to
| > accommodate quirks of CA certificate-issuing software. However, logs
| > MUST refuse to publish certificates without a valid chain to a known
| > root CA. If a certificate is accepted and an SCT issued, the
| > accepting log MUST store the entire chain used for verification,
| > including the certificate or Precertificate itself and including the
| > root certificate used to verify the chain (even if it was omitted
| > from the submission), and MUST present this chain for auditing upon
| > request. This chain is required to prevent a CA from avoiding blame
| > by logging a partial or empty chain. (Note: This effectively
| > excludes self-signed and DANE-based certificates until some mechanism
| > to limit the submission of spurious certificates is found. The
| > authors welcome suggestions.)
| >
| > Since the purpose of the log is to put light on bad certificates, would
| > it make sense to instead have text 1) specifying a minimum of checks to
| > be done (i.e. the chain)
|
|
| Since checking is for spam limitation, and different logs may have
| different views on what is spam, I am not convinced this is a good idea -
| for example, any chain check would appear to automatically rule out logging
| self-signed certs, and it seems to me that should be left open to log
(Depends on how you define "trusted/known root CA certificate", but OK
that might be a stretch.)
But the current text _does_ require a chain check, doesn't it?
Logs MUST verify that the submitted end-entity certificate or
Precertificate has a valid signature chain leading back to a trusted
root CA certificate, using the chain of intermediate CA certificates
provided by the submitter.
and
However, logs
MUST refuse to publish certificates without a valid chain to a known
root CA.
My intention was to make the specification less restrictive by changing
Logs MAY accept certificates that have
expired, are not yet valid, have been revoked, or are otherwise not
fully valid according to X.509 verification rules in order to
accommodate quirks of CA certificate-issuing software.
to something indicating that anything more than a chain check is either
forbidden or discouraged.
| operators to think about (e.g. Microsoft would appear to have sufficient
| information to do spam limitation through use measurement:
|
http://blogs.technet.com/b/pki/archive/2014/02/22/a-novel-method-in-ie11-for-dealing-with-fraudulent-digital-certificates.aspx)
|
|
| > and 2) encouraging logging and publishing of
| > all other certificates?
| >
|
| That seems like a good plan :-)
|
|
| >
| >
| > On a minor note, I think that "trusted" in the very first sentence
| > should be changed to "known. Should I use the issue tracker?
| >
|
| Yes, please.
Is this the right place?
https://github.com/google/certificate-transparency-rfcs/pull/7
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
