Stephen,

2.2.2. Certificate not logged

   Because the CA is presumed malicious, it may choose to not submit a
   (pre-)certificate to a log. This means there is no SCT for the
   certificate.
  ...
2.2.2.1. Self-monitoring Subject

   A Subject performing self-monitoring will be able to detect the lack
   of SCT and notify the CA about the bogus certificate and request
   revocation. 

[Rick] Since the certificate is not logged, how will the self-monitoring
Subject detect the lack of SCT? The CA could mis-issue the cert but not send
it to the Subject. You need a Careful Browser detecting the lack of SCTs and
notifying the Subject for the Subject to be aware of this case. Likewise, I
think this sentence in 2.2.2.2 is incorrect: "If, when an SCT is not
provided, clients do not reject certificates and do not notify the CA or the
Subject, this form of mis-issuance will succeed unless the Subject is
self-monitoring (See 2.2.2.1 and Note 3.)"


3.1. Non-malicious Web PKI CA context

   This section analyzes the scenario in which the CA has no intent to
   issue a syntactically incorrect certificate. Throughout the
   remainder of this document we refer to a syntactically incorrect
   certificate as ''erroneous''.
[Rick] In the sections below, you also refer to certificates as "malformed".
I think "erroneous" could/should be used in those cases instead of
"malformed".


3.1.1.1. Benign log

   ...
    . If a (pre-)certificate is submitted by a third party, that party
      might contact the Subject or the issuing CA, but because the
      party is not the Subject of the certificate it is not clear how
      the CA will respond.
[Rick] I think you should remove "(pre-)", because pre-certificates cannot
be submitted by third parties, only by the CA.


3.1.2. Certificate not logged

   If a CA does not submit a certificate to a log, there can be no
   syntactic checking by the log. Detection of syntactic errors will
   depend on Subjects or Monitors performing the requisite checks.
[Rick] Detection could also be done by Careful Browsers (though I agree with
your caveat in 3.1.1.4). If you think that Careful Browsers should be added
to this Section, then they should also be added to 3.2.1.3. But I'm guessing
you intentionally didn't add Careful Browsers because to date, any checking
they have performed generally did not result in notification to Subjects or
Issuing CAs. So I'm ok if you leave them out of both Sections.

-Rick

-----Original Message-----
From: Trans [mailto:[email protected]] On Behalf Of Melinda Shore
Sent: Wednesday, June 03, 2015 2:22 PM
To: [email protected]
Cc: Stephen Kent
Subject: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt

The initial draft of the threat analysis document is out.
Please give it a careful read and post comments to the mailing list.

Steve, if you could highlight issues that need particular attention, that
can get working group discussion off to a strong start.

Melinda


-------- Forwarded Message --------
Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt
Date: Wed, 03 Jun 2015 14:00:30 -0700
From: [email protected]
To: [email protected]
CC: [email protected]


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Public Notary Transparency  Working Group
of the IETF.

        Title           : Threat Analysis for Certificate Transparency
        Author          : Stephen Kent
        Filename        : draft-ietf-trans-threat-analysis-00.txt
        Pages           : 18
        Date            : 2015-06-02

Abstract:
   This document describes a threat model for the Web PKI context in
   which security mechanisms to detect mis-issuance of web site
   certificates will be developed. The threat model covers both
   syntactic and semantic mis-issuance, using a taxonomy of threats
   starting with whether the mis-issuance was done by the CA
   maliciously or not; then whether or not the certificate was logged;
   and then whether the log(s) or monitor(s) are benign or malicious,
   whether the certificate subject is self-monitoring and whether a
   client is doing any checks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans


_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Reply via email to