Melinda Shore | 30 Oct 04:21 2014
Picon

Gossip drafts

You all may have noticed that Linus has uploaded three
drafts on gossip protocols for CT.  Please give those
a read.  In the short term we need something we can
publish as an experimental standard, so please give some
thought about how to move this work forward.  Once
there's been some discussion we can adopt a draft as
a working group deliverable.

Melinda
Melinda Shore | 18 Oct 03:00 2014
Picon

IETF schedule

In case you've missed it, the final agenda is out:
https://datatracker.ietf.org/meeting/91/agenda.html

We're meeting on Monday afternoon from 3:20 to 6:30.

Melinda
Linus Nordberg | 17 Oct 14:51 2014
Picon

Certificate verification

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) and 2) encouraging logging and publishing of
all other certificates?

(Continue reading)

Ben Laurie | 16 Oct 17:09 2014
Picon

Precertificate format

We (the 6962-bis editors) would like to propose that we replace the existing precertificate formats with a TBSCertificate wrapped in PKCS#7. This lays to rest, we think, any possible confusion with X509v3 certs, whilst allowing a simple mapping between the final cert and the pre-cert.


Obviously there are details to be nailed down, but before we do so, we'd like to hear any discussion on the general idea.
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Stephen Kent | 14 Oct 18:42 2014
Picon

attack analysis, revised

The text below is my current take on an attack analysis for CT, revised to
reflect the goal of a broader, long-term scope, but emphasizing the current,
Web PKI-centric focus of the charter. It also has been changed based on several
comments from folks over the past week or so.  I think this analysis belongs in
6962-bis. It raises some questions that need to be answered as revisions proceed,
and suggests some topics that should be discussed in the security considerations section.

Comments (especially revised text) welcome,

Steve
-------

XX. Attack Model and Discussion of Detection and Mitigation Options

 

Certificate mis-issuance may arise in one of several ways. The ways that CT enables a Subject (or others) to detect and redress mis-issuance depends on the context and the entities involved in the mis-issuance. This attack model applies to the Web PKI context. If CT is applied to other contexts, each will require its own attack model, although most of the model described here is likely to be applicable.

 

Certificates are issued by CAs, so the top level differentiation is whether the CA that mis-issued a certificate did so maliciously or not. If not, then the next point of differentiation is whether the mis-issuance was the result of an accident or an attack. In the case of an attack, it is necessary to consider whether the certificate was logged, and if so, whether the log conspired with the attacker.

 

If the CA acted maliciously, it is necessary to ask whether it logged a mis-issued certificate. If so, then one must consider whether the CA conspired with one or more log operators, or conspired with one of more Monitors (for not self-monitoring Subjects).

 

The following sections examine each of these cases, for both syntactic and semantic mis-issuance. As noted above, the focus here is on the Web PKI context, although most of the analysis is applicable to other PKI contexts.

 

 

XX.1 A non-malicious Web PKI CA

 

If a certificate is submitted to a log, either prior to issuance (a pre-certificate), or post-issuance, syntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted (pre-) certificate. A (pre-) certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance. If syntactic validation fails, this will be noted in the SCT returned to the CA, and because the CA is non-malicious, it will remedy the syntactic problem and re-submit the (pre-) certificate to a log again.

 

Thus syntactic mis-issuance can be avoided by a CA if it makes use of logs that are capable of performing these checks for the types of certificates that are submitted, assuming that it acts on the feedback it receives. If a CA uses a log that does not perform such checks, or if the CA requests checking relative to criteria not supported by the log, then syntactic mis-issuance will not be detected.

 

XX.1.1 A CA may issue the certificate to an unauthorized party (semantic mis-issuance), as a result of an error or because it was the victim of a social engineering attack. We will refer to such a certificate as “bogus”. In this case the CA has a record of the bogus certificate and it is prepared to revoke the bogus certificate once it has confirmed its error. If the CA is submitting (pre-) certificates for logging, there will be evidence of the mis-issuance in one or more logs. If a Monitor is “protecting” the targeted Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, it should revoke the bogus certificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence of an embedded SCT in the bogus certificate, or an SCT accompanying the bogus certificate is irrelevant to the mitigation procedure in this case. (See Note 1 below.) Because the mis-issuance was not malicious, there is no notion of a log operator or a Monitor conspiring with the CA.

 

XX.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar [cite]) which results in semantic mis-issuance of a certificate. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content.

 

XX.1.2.1 The mis-issued certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor that is protecting the targeted Subject will detect the bogus certificate and alert it. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA will make use of the log entry (supplied by the Subject) to determine the serial number of the mis-issued certificate, and revoke it (after investigation). (See Notes 1 + 2.) If TLS clients reject a certificate when no SCT is provided, this might motivate the attacker to log the bogus certificates, which helps justify such client behavior. (See Note 3.)

 

XX.1.2.2 The bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If TLS clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3.)

 

XX.1.2.3 The bogus certificate may have been submitted to logs that are conspiring with the attacker. In this case, Monitors will not detect the bogus certificate because the logs will suppress a bogus certificate log entry. TLS clients will not reject a bogus certificate in this case, because it is accompanied by an SCT. In this scenario, unless Monitors or Auditors “gossip” to detect conspiring logs, the bogus certificate will not be detected.

 

 

XX.2 A Malicious Web PKI CA

 

XX.2.1 If a (pre-) certificate is submitted to a (non-conspiring) log, syntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted certificate. A (pre-) certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance.

 

Because the CA is presumed to be malicious, the CA may cause the log to not perform checks, in one of two ways. The CA may assert that the certificate is being issued w/o regard to any guidelines (the “no guidelines” reserved CCID), or it may assert a CCID that has not been registered. In this fashion the CA can prevent the log from performing checks, and the SCT and log entry will not contain an indication of a failed check. Alternatively, the CA may submit a (pre-) certificate to a log that is known to not perform syntactic checks, and thus avoid syntactic checking.

 

If a client rejects a certificate that has not been syntactically checked (as indicated by the SCT), the first approach to subverting syntax checking will fail. If a client rejects a certificate that was logged by an operator that does not perform syntactic checks, the third approach noted above will fail. If a client is configured to know which versions of CABF guidelines exist, the second approach to avoiding syntactic checking also can be thwarted.

 

XX.2.2 Because the CA is presumed malicious, it may choose to not submit a certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case. (See Note 3.)

 

XX.2.3 A malicious CA may submit a certificate to one or more logs that collude with this CA to not perform syntactic checks, even though they claim to do so. In this case the syntactic mis-issuance will not be detected by logs.  The log entry and the SCT for a syntactically invalid certificate will assert that the certificate syntax was verified. Unless Monitors also perform syntactic checks, this form of mis-issuance will not be thwarted in this case. TLS clients will believe that the certificate has been syntactically verified.

 

XX.2.4 A malicious CA may semantically mis-issue a certificate that is syntactically valid. Because it is syntactically valid, logs will not reject the bogus certificate. This situation might result because the CA was bribed or was compelled to issue the bogus certificate. A CA might be compelled to issue a bogus certificate by a government agency or a criminal organization.  This CA might be one or more tiers below a trust anchor (aka root CA).

 

XX.2.4.1 A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3.)

 

XX.2.4.2 A bogus certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a standalone SCT. In either case, a Monitor protecting the targeted Subject will detect a bogus certificate and alert the targeted subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc. In this case, the CT mechanisms have detected mis-issuance, but the information logged by CT does not help remedy the problem. (See Note 4.)

 

XX.2.5 A bogus certificate may have been submitted to one or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any Monitor from which the log is hiding data will not detect the bogus certificate, even if it is trying to protect the targeted Subject. If a client accepts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the semantically mis-issued certificate.

 

Auditors are intended to detect logs that conspire to suppress log entries, based on consistency checking of logs and use of a “gossip” protocol. Until such checks are clearly defined and a gossip protocol is defined and deployed, CT does not provide the necessary info to detect this form of mis-issuance.  When Auditors can detect a conspiring log, Monitors and clients can be alerted to it (how?). This would cause Monitors to avoid using such a log, and clients would reject SCTs generated by such a log. (See Note 5 below.)

 

Notes:

 

1. If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide “sufficient” coverage. If a Subject acts as its own Monitor, this problem is solved for that Subject. It is not clear how a Monitor becomes aware of all (relevant?) logs, including newly added logs. The means by which Monitors become aware of new logs MUST accommodate self-monitoring by a potentially very large number of web site operators.

 

2. A CA being presented with evidence of a bogus certificate, in the form of a log entry, will need to examine its records to determine if it has knowledge of the certificate in question. It also will likely require the targeted Subject to provide assurances that it is the authorized entity representing the Subject name (subjectAltname) in question. Thus a Subject should not expect immediate revocation of a contested certificate. The time frame in which a CA will respond to a revocation request usually is described in the CPS for the CA. Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus, based on applicable criteria. The SCT and log entry, because each contains a timestamp from a third party, is probably valuable for forensic purposes (assuming a non-conspiring log operator).

 

3. If a TLS client is to reject a certificate that lacks an embedded SCT, or is not accompanied by an SCT transported via the TLS handshake, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules. Until a mechanism is defined that accommodates incremental deployment of this capability, attackers should not be expected to submit bogus certificates to (non-conspiring) logs.

 

4. A targeted Subject might request the parent of a malicious CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage. A browser might be configured to reject all certificates issued by the malicious CA, e.g., using a CA hot list distributed by a browser vendor. However, if the malicious CA has a sufficient number of legitimate clients, treating all of them as bogus still represents serious collateral damage. If one can configure a browser to reject a specific, bogus certificate identified by a Monitor, then the bogus certificate could be rejected in that fashion. This mitigation strategy calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication has not been specified, i.e., there no standard ways to configure a browser to reject individual bogus certificates based on info provided by a Monitor. Moreover, the same or another malicious CA could issue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) fashion. Thus, for now, CT does not seem to provide a way to mitigate this form of attack, even though it provides a basis for detecting such attacks.

 

5. The combination of a malicious CA and one or more conspiring logs motivates the use of Auditors, to detect conspiring logs. If a Monitor protecting s Subject does not see mis-issued certificates, it cannot alert the Subject. If one or more SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if Monitors and clients reject certificates that contains SCTs from conspiring logs (based on info from Audotirs) will CT be able to deter use of such logs. Thus the means by which Auditors detect such logs, and inform TLS clients and Monitors must be specified. Moreover, if a certificate (or TLS handshake) contains more than one SCT, it appears that the client MUST verify all of them if it is to counter the threat posed by conspiring logs.

 

Absent a “gossip” protocol that enables Auditors to verify that data from logs are reported in a consistent fashion to many (all?) Monitors, CT does not provide protection against logs that may conspire with, or be victims of, attackers effecting certificate mis-issuance. When a gossip protocol is defined and deployed, it will be necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log. Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection of mis-issuance.

 

Monitors play a critical role in detecting semantic certificate mis-issuance, for Subjects that have requested monitoring of their certificates. A monitor (including a Subject performing self-monitoring) examines logs for certificates associated with one or more Subjects. It must obtain a list valid certificates for the Subject being monitored, in a secure manner.  A Monitor must not rely on a CA or RA database for this information or use certificate discovery protocols; this information must be acquired by the Monitor based on reference certificates it has obtained and installed. If a Monitor were to rely on a CA or RA database (for the CA that issued a targeted certificate), the Monitor would not detect mis-issuance due to malfeasance on the part of that CA or the RA, or due to compromise of the CA or the RA.  If a CA or RA database is used, it does detect mis-issuance by an unauthorized CA.  A Monitor must not rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms might result in mis-issued certificates being added to the list.

 

Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting that Subject. This suggests that a Subject SHOULD request certificate monitoring from multiple sources to guard against such failures. Operation of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors, but the burden of Monitor operation may be viewed as too great for many web sites, and thus this mode of operation ought not be assumed to be universal when evaluating protection against Monitor compromise.

 

Now that certificate pinning has been approved as a standard, it is appropriate to factor in its use by TLS clients. It would appear that pinning will dramatically reduce the set of TLS clients that are vulnerable to mis-issuance; a client that pins a certificate for a web site would reject a bogus certificate even without use of any CT mechanisms. The security considerations section of 6962-bis needs to note this, as it suggests that deployment of pinning reduces the need for CT.

<!-- /* Font Definitions */ <at> font-face {font-family:"&#65325;&#65331; &#26126;&#26397;"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:"&#65325;&#65331; &#26126;&#26397;"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 0 0 0 1 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} <at> page WordSection1 {size:8.5in 792.7pt; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} /* List Definitions */ <at> list l0 {mso-list-id:1291060163; mso-list-type:hybrid; mso-list-template-ids:164768244 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Paul Wouters | 14 Oct 00:20 2014
Picon

Agenda for IETF-91


Below is our draft agenda for IETF-91. If you wish to add something,
please let us know as soon as possible.

Paul & Melinda

IETF-91 trans agenda
15:20 - 17:20 Monday 10 Nov 2014

     Agenda
     Issue tracker status
     Requirements for entry into the log
     6962-bis update
     Gossip protocol document
     Client/monitor protocol document
     CT for DNSSEC
     CT for executables
     Compressed CRLs [Phillip]
     Any other business?

Agenda
     administrivia (~5 minutes)
         blue sheets, scribes, agenda-bashing

Status update (~15 minutes)
     milestone review
     quickie overview of draft status
     open trac issues run-down (Eran)

Requirements for entry into the log (~20 minutes)
     discussion

6962-bis (Ben, ~10 minutes)
     current state
     what needs to be done between now and working group last call

Gossip protocol (Linus?, Daniel?, ~10 minutes)
     current state

Client/monitor protocol document (~5 minutes)
     Looking for volunteers

CT for DNSSEC (Dacheng, ~15 minutes)

CT for executables (Dacheng, ~15 minutes)

Compressed CRLs (Phillip, ~10 minutes)

Any other business?
Stephen Kent | 9 Oct 23:20 2014
Picon

Goals and generic mis-issuance fgramework

In response to some of the issues Paul and others have raised, I have generated
some text that tries to characterize the goal of CT, establishes a generic framnework
for defining checks for mis-issuance, and sets the stage for references to two RFcs
that will define syntactic and semantic checks for Web PKI certs claiming to conform to
CABF DV or EV guidelines.

Note that this text do not require a log to perform any checks; it allows a log to
indicate if has performed applicable checks, and the results of such checking.

Steve
-------

1. Certificate Transparency Goals and Mechanisms

 

The goals of Certificate Transparency (CT) are threefold: detection, deterrence, and enabling remediation of mis-issuance of certificates. The initial focus of CT is the Web PKI context, (The Web PKI context refers to the use of a set of Certification Authorities (CAs) that issue X.509 certificates to web servers to enable TLS-protected access by clients [cite WPKOPS?].) In the future, it is anticipated that addition operational contexts may be supported. As a result, mis-issuance is defined in an fashion that accommodates a range of types of certificates used in a range of contexts.

 

CT supports detection of mis-issuance using logs of certificates, populated by the CAs that issue them or by the Subjects of certificates. Monitors (described in Section X) are the primary elements of the CT system that check certificates for syntactic and semantic mis-issuance, on behalf of Subjects. A Monitor may be operated by a third party on behalf of Subjects, or may be operated by a Subject on its own behalf. (The latter is referred to as “self-monitoring”.) Logs may optionally perform syntactic checks for some classes of certificates, but a log is not required to offer certificate checking.

 

A certificate mis-issued by a CA, and detected by the CT system, is presumed to damage the reputation of the CA. Thus it is anticipated that CT will deter mis-issuance via monitoring of logs. It also is anticipated that CT also will help remedy mis-issuance, in two ways. When a mis-issued certificate is detected as such, the Subject will be notified. The Subject can contact the issuer and request revocation of the bogus certificate, using information from the log.

 

A certificate is characterized as mis-issued if the certificate does not conform to requirements established for the class of certificate in question. The term “class” refers to certificates used in different application contexts and issued under different sets of syntactic and semantic guidelines. Thus, for example, most certificates used in the Web PKI context are issued by CAs under guidelines published by the CA Browser Forum (CABF). (If a new version of guidelines is created for a class of certificates, a new certificate class ID (CCID) will be assigned. This allows certificates issued under old and new sets of guidelines to be checked appropriately, without introducing ambiguity.) Certificates used with IPsec, S/MIME, or other security protocols each constitute a different class. A certificate that is not issued in accordance with any published set of requirements is assigned a reserved CCID.

 

To enable Monitors (and, optionally, logs) to perform an appropriate set of checks, the (pre-) a CCID MUST be provided to a log when a certificate is submitted by a CA or Subject. This CCID MUST appear in the log entry and in the SCT generated by the log. By providing the CCID in logs and SCTs, both Monitors and clients are empowered to perform applicable checks based on the certificate class asserted by the CA or Subject.

 

This document establishes an IANA registry of CCIDs (see Section Y) to enable CT to deal with additional classes of certificates in the future. The registry is initially populated with CCIDs deemed appropriate for the Web PKI context (see Section Y). Every registry entry lists the RFC (or analogous document) that specifies the checks applicable to the registered certificate class. One entry is established to indicate a CCID for which no applicable checks have been defined.

 

Mis-issuance

 

Mis-issuance takes two primary forms: syntactic mis-issuance and semantic mis-issuance.

 

1. A certificate may fail to meet the syntactic constraints established for a specified certificate class. Such failure can have serious security implications, e.g., a failure to include the basicConstrainst extension in a Web PKI certificate can allow the holder of an EE certificate to issue subordinate certificates that may be accepted by browsers. Most syntactic constraints can be checked via examination of a certificate chain, without reference to Subject-specific or CA-specific data. This means that these constraints can be verified by logs without access to Subject-specific data.

 

2. A certificate may fail to meet the semantic constraints established for a specified certificate class. The usual (though not universal) semantic constraint is that a certificate is issued only to an entity that is authorized to represent the Subject name (subjectAltName) in the certificate. This constraint can be verified by comparing a certificate against the set of “reference” certificates supplied by a Subject. In the Web PKI context, the Subject (subjectAltName) represents a web server, and the entity to which the certificate is issued is presumed to be authorized by the owner of the corresponding DNS name. For other classes of certificates, the relevant name might be an IP address, an e-mail address, or some other identifier appropriate to the application context in which the certificate is used.

 

A log MAY perform the syntactic checks consistent with the certificate class asserted by the CA or Subject that submits a (pre-) certificate to the log. This behavior is RECOMMENDED to provide timely feedback to CAs and Subjects when certificates are submitted to logs. For a CA it can detect potential syntactic mis-issuance before a certificate is issued. For a Subject, it provides an indication of whether its certificate conforms to the asserted criteria. A log MUST include the asserted certificate class ID in the log entry.

 

A log MUST generate a Syntax Verification Value (SVV) for the certificate, and include the SVV in the log entry and in the SCT.

The LVV is value specified by this document (see Section Z) that indicates whether or not the log performed applicable syntactic checks, and whether the (pre-) certificate passed of failed the checks. Although it is anticipated that new certificate classes will arise over time, the set of log actions with respect to syntax checking appears to be well-defined and thus need not be represented in an IANA registry. Each SCT issued by a log MUST include an SVV. 

 

A Monitor also may perform syntactic checks of certificates. It may do so because a certificate was not checked by a log (as indicated in the log entry), or as a way to detect logs that have been compromised or that are deficient or malicious.

 

Detection of semantic mis-issuance requires access to one or more “reference” certificates associated with a specified Subject. (For purposes of this discussion, a reference certificate is a valid certificate issued to a specified Subject, consistent with the guidelines specified by the certificate class ID.) As noted above, the primary attack addressed by detection of semantic mis-issuance is issuance of a certificate to an entity that is not authorized to represent the host (web server) named in the certificate Subject field (or subjectAltName extension).

 

 

Section Y. IANA Registry for Certificate Class Identifiers (CCIDs)

 

The name of the registry shall be " Certificate Class Identifiers for use with Certificate Transparency",

 

This is a “Standards Action” registry.  Each registry entry consists of a positive integer (16-bit) and a reference to the RFC that defines the syntactic and semantics checks applicable to the certificate class identified by the integer. The first entry “0” designates a certificate class for which no syntactic or semantic checks are defined.

 

The following initial entries are created by this RFC:

 

Value       RFC

0                 N/A

1                 XXXX (certificate checks derived from [CABF-DV])

2                 XXXX (certificate checks derived from [CABF-EV])

  

 

Section Z. Syntax Verification Value (SVV) Definitions

 

The following integer (8-bit) values are defined for the Syntax Verification Values (SVVs) generated by a log.

 

Value     Interpretation

0                 The CCID value was 0, so not checks were performed

1                 This log does not perform syntax checks

2                 This log does not support syntax checks for the asserted CCID

3                 This log performed the syntax checks for the asserted CCID, and the certificate passed

4                 This log performed the syntax checks for the asserted CCID, and the certificate failed

 

No other SVV values are defined by this RFC.

<!-- /* Font Definitions */ <at> font-face {font-family:"&#65325;&#65331; &#26126;&#26397;"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:"&#65325;&#65331; &#26126;&#26397;"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 0 0 0 1 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} /* List Definitions */ <at> list l0 {mso-list-id:669524176; mso-list-type:hybrid; mso-list-template-ids:-817483238 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1 {mso-list-id:1080181145; mso-list-type:hybrid; mso-list-template-ids:-1761437698 920835532 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l1:level1 {mso-level-start-at:0; mso-level-text:%1; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:1.25in; text-indent:-1.0in;} <at> list l1:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l1:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l1:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l2 {mso-list-id:2029480311; mso-list-type:hybrid; mso-list-template-ids:-1659981776 766513888 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l2:level1 {mso-level-start-at:0; mso-level-text:%1; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:1.0in; text-indent:-1.0in;} <at> list l2:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:.75in; text-indent:-.25in;} <at> list l2:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:1.25in; text-indent:-9.0pt;} <at> list l2:level4 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:1.75in; text-indent:-.25in;} <at> list l2:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:2.25in; text-indent:-.25in;} <at> list l2:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:2.75in; text-indent:-9.0pt;} <at> list l2:level7 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:3.25in; text-indent:-.25in;} <at> list l2:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:3.75in; text-indent:-.25in;} <at> list l2:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:4.25in; text-indent:-9.0pt;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Stephen Kent | 8 Oct 22:50 2014
Picon

Re: Misissuance vs auditing/monitoring

Paul,

It seems the discussion about misissuance is going into far too
many different policy decisions favoured by different people. That
makes it obvious that it does not belong in the base specification
document.
I agree that the specs for syntactic and semantic mis-issuance should be
in a separate document, to better accommodate other types of certs beyond
the Web PKI, evne though they are out of scope for the current doc, as per the
TRANS charter, which specifies the scope of the first RFC:

Publish an update to RFC 6962 as a standards-track mechanism to
apply verifiable logs to HTTP over TLS.

I do not agree that 6962-bis duck the question of what constitutes mis-issuance.
I believe its possible to define the term in a way that will accommodate other
cert types (even though that is NOT required for 6962-bis), and to include pointers
to an RFC that describes how CAs, Subjects, logs, Monitors and clients can know
what they're getting wrt mis-issuance checking.

One RFC will describe syntactic and semantic requirements, derived from CABF specs,
omitting parts that cannot be checked without Subject or CA-specific info. That seems
to be the appropriate set of checks for the Web PKI.

The goal is to provide a distributed logging infrastructure that people
can use with their clients and monitors. Consumers and providers can
pick those that match their operational expectations and policies.
This characterization omits mention of the context that is used to justify
CT, i.e., the Web PKI. The charter later says:

As DANE (RFC6698) provides an alternative keying infrastructure to that used
in the current web PKI, the working group should consider appropriate client
behavior in the presence of both DANE-based keying and current web PKI when
standardising CT.

The charter also says that the WG could be re-chartered to address certs used with
other security protocols. The approach I'm describing will accommodate certs used
in other contexts, so if we pursue logs for DANE in the future, it will still work.
Logs will have different policies on which kind of certificates they will
accept into the log or not. But we should not come up with policies for
people running the logs in different commercial or legal systems. Each
will develop their own rules.
I find these statements a bit confusing. First, under the current charter we're talking
about just one type of cert, an X.509 cert issued to a web serer, right? We're
not talking about code signing certs, certs for e-mail, certs for IPsec, etc. Those
can come later, if the WG is re-chartered and elects to pursue them.

My proposal for syntactic checking can accommodate certs issued for other purposes, easily.
All we need to do is establish an IANA registry that specifies the type of cert that
is being logged, as asserted by a CA or Subject. For each cert type there will be
a matching RFC that defines what checks are to be performed. (Each new version of
a cert spec receives a new registry entry, so that one knows which version is being
asserted. Thus the scheme can accommodate new CABF guideline versions, etc.)

The registry also should include a set of responses for a log to assert relative to the
cert type asserted by the CA or Subject. For example, "I don't do checks", "I don't
check this cert type/version", "I checked it and it passed" and "I checked it and it
failed" or "the submitted said no criteria exists, so I didn't check."

A log, if it elects to perform checks, will know which checks to perform based on the
value asserted in the log request. A Monitor that performs checks can make use of this info,
because it will be part of the log entry. A Client that wants to accept SCTs from a log
based on its ability (and willingness) to perform checks van learn what is and is not
checked by the logs that generated the SCTs that the client encounters.

This is a powerful mechanism for CT. One does need separate RFCs to define each set of
checks, but the log interface and SCT format have to accommodate expressing the CA/Subject
and log assertions if this capability is to be enabled. Thus the base doc needs to
include such specifications.

For the Web PKI context, the policies that exist are ones defined by the CABF,
as profiles of RFC 5280 and RFC 3279. These policies apply to ALL CAs issuing EV certs,
by definition, across all jurisdictions, AFAIK. I am not aware of any legal system
differences that have arisen at the level of the specification that we are discussing.
CABF members include CAs from North American, Europe, and Asia, and several of these
CAs offer services in other parts of the world, e.g., Africa, via local RAs.
Do you have some examples of the differences that are of concern, at the level of
specification that we're discussing?

More to the point, recall that my revised proposal does not require a log to perform
any syntactic checks; it allows a log to do so, and to advertise the result of what it
did, which provides for grater "transparency" wrt log operation.
The focus should be on what the minimum requirements are for inclusion
into the log in such a way that the log is able to fulfill its function.
Again, if you have read my revised proposal, the syntactic checks do not preclude
inclusion of ANY cert into a log. Syntactic checking by a log is an optional
service. I believe that Monitors ought to be required to perform syntactic
checks, as well as semantic checks, so that clients know what services they
get from Monitors, in a uniform, easy to understand fashion. But, that is a
separate debate, right?
Being resistant to spam/dos attacks is an important factor. But should we
just mention it in the security sections and leave it open for everyone to
decide on? Someone might want _only_ self signed certificates in their log
server and it would be wrong if the base specification would forbid that.
Two comments here:
    - 6962-bis mandates path checking (not well specified)  to address one form
of dos attack against logs.
     - you mention self-signed certs, but they (and DANE "certs") are explicitly
excluded by 6962 and 7962-bis, based on the anti-dos mechanism noted above.
So, your two observations above seem to be in conflict. Are you suggesting a
change of scope in that respect?  Is your comment here a direction issued as
WG co-chair to the document editors?
The serial number seems to be a hard requirement, as it is needed to
uniquely identify the certificate. CABF policy is not. I'm sure there
will be logs that will only allow EV certs. That's fine. Those policies
do not belong in our document.
I presume your comment about serial numbers is saying that a log entry needs to
include a cert serial number, but that checking syntax (beyond the path validation
requirement), is not essential to the function of a log. I agree.

But, enabling a log to perform this function, by requiring the log interface and
log entry and SCT formats to accommodate a simple assertion about cert type,
and whether a log elected to perform syntax checks, does seem very valuable.
This is especially true if one wants to expand logs to accommodate other forms
of certs in the future, as you suggested above.

Also, to be precise, my proposed does not impose a requirement that a cert be
evaluated against DV or EV requirements, by a log. A CA or Subject can submit
a (pre-) cert and assert that it does NOT purport to comply with any criteria.
Using the IANA registry model I described above, other cert types can be
accommodated cleanly, and need I say, transparently, while making it easy for
Monitors and clients to know what type of cert has been logged.

For the base document, we need to focus only on the requirements needed
for self-preservation of the log.
A log is one element of CT. We also need to describe the security functions
of Monitors, clients, and Auditors (if this last one survives). I also think we
need to include an attack analysis.
If someone is interested in writing a separate policy document for a
specific type of log, that would be great. For instance a log that only
takes in CABF members issued certificates.
I don't think you meant exactly what you said; a non-CABF member might assert
that they issue DV or EV certs.

In summary, what I propose is that 6962-bis be revised to:

    - include an attack analysis

    - accommodate an assertion by a CA or Subject about a cert submitted to a log
      in the log submission, log entry, and SCT formats

    - accommodate an assertion by a log of what checks it performed, if any, and
      what was the outcome, in the log entry and SCT formats

    - refer to a separate RFC that creates the IANA registry for these assertions,
      and establishes the range of log assertions

Yet another RFC will define CA/Subject assertions values for DV and EV certs,
and the associated syntactic and semantic checks for these types of Web PKI certs.
Since the focus of the initial doc being produced by TRANS is Web PKI certs, I think
it is appropriate to cite this last RFC as consistent with that focus.

Steve

_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Stephen Kent | 8 Oct 17:03 2014
Picon

Re: defining "mis-issuance"

Ben,
> On 3 October 2014 20:25, Stephen Kent<kent <at> bbn.com>  wrote:
>> Ben,
>>
>>> ...
>>> I have a suggested solution:
>>>
>>>       - require a CA submitting a pre-cert to assert one of the following:
>>>           1. no assertion is made wrt syntactic conformance to CABF
>>> guudelines
>>>           2. the cert conforms to DV Guidelines <insert guideline version>
>>>           3. the cert conforms to EV guidelines <insert guideline version>
>>>
>>>       - require a log to include the CA assertion in its SCT, along with
>>> one
>>> of the following:
>>>           1. this log does not check cert syntax
>>>           2. this log cannot check the specified CABF Guidelne version
>>> asserted by the CA
>>>           3. this log checked the cert against the CA's assertion and it
>>> passed
>>>           4. this log checked the cert against the CA's assertion and it
>>> failed
>>> Presumably this would apply to certs as well as precerts, which is the
>>> other reason rejecting isn't particularly helpful (certs are already
>>> issued by the time they're logged!).
>> I'm confused by your comment. There is no "rejection" of a cert in the text
>> above.
>> That was the change I made to address the valid concerns that Rob and Rick
>> raised.
> I was adding another valid concern to Rob and Rick's, it was not meant
> to be a criticism of the above proposal.
Sorry, I didn't realize the intent of your comment. But, in any case,
my revised proposal addresses this concern as well.
>> If the cert failed checking it would still be logged, and an SCT issued,
>> but the fact that the syntax failed the checks would be noted in the SCT and
>> the log entry.
> Sure, but the language proposed does not cover certs - they may not be
> submitted by a CA and obviously they are not pre-certs.
Good point. I will revise the proposal to cover certs, as well as 
pre-certs.

Steve
trans issue tracker | 3 Oct 16:29 2014
Picon

Re: [trans] #51 (rfc6962-bis): Test, please disregard

#51: Test, please disregard

Changes (by henrik <at> levkowetz.com):

 * status:  new => closed
 * resolution:   => fixed

--

-- 
----------------------------------+---------------------
 Reporter:  henrik <at> levkowetz.com  |       Owner:  henrik
     Type:  defect                |      Status:  closed
 Priority:  major                 |   Milestone:
Component:  rfc6962-bis           |     Version:
 Severity:  -                     |  Resolution:  fixed
 Keywords:                        |
----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/51#comment:3>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 3 Oct 16:19 2014
Picon

Re: [trans] #51 (rfc6962-bis): Test, please disregard

#51: Test, please disregard

Comment (by henrik <at> levkowetz.com):

 Test after SIGHUP'ing postconfirmd

--

-- 
----------------------------------+---------------------
 Reporter:  henrik <at> levkowetz.com  |       Owner:  henrik
     Type:  defect                |      Status:  new
 Priority:  major                 |   Milestone:
Component:  rfc6962-bis           |     Version:
 Severity:  -                     |  Resolution:
 Keywords:                        |
----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/51#comment:2>
trans <http://tools.ietf.org/trans/>

Gmane