trans issue tracker | 5 Mar 19:22 2015
Picon

Re: [trans] #9 (rfc6962-bis): Security Considerations for number and variety of SCTs

#9: Security Considerations for number and variety of SCTs

Changes (by melinda.shore <at> gmail.com):

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

Comment:

 New text:
 {{{
       <section title="Multiple SCTs">
         <t>
           TLS servers may wish to offer multiple SCTs, each from a
 different log.
           <list style="symbols">
             <t>
               If a CA and a log collude, it is possible to temporarily
 hide misissuance from clients. Incorporating SCTs from different logs
 makes it more difficult to mount this attack.
             </t>
             <t>
               If a log misbehaves, a consequence may be that clients cease
 to trust it. Since the time an SCT may be in use can be considerable
 (several years is common in current practice when the SCT is embedded in a
 certificate), servers may wish to reduce the probability of their
 certificates being rejected as a result by including SCTs from different
 logs.
             </t>
             <t>
(Continue reading)

trans issue tracker | 5 Mar 19:15 2015
Picon

Re: [trans] #9 (rfc6962-bis): Security Considerations for number and variety of SCTs

#9: Security Considerations for number and variety of SCTs

Changes (by benl <at> google.com):

 * status:  closed => reopened
 * resolution:  needs-review =>
 * milestone:   => review

--

-- 
--------------------------------------+------------------------------
 Reporter:  rob.stradling <at> comodo.com  |       Owner:  benl <at> google.com
     Type:  defect                    |      Status:  reopened
 Priority:  minor                     |   Milestone:  review
Component:  rfc6962-bis               |     Version:
 Severity:  -                         |  Resolution:
 Keywords:                            |
--------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/9#comment:3>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 5 Mar 16:25 2015
Picon

Re: [trans] #9 (rfc6962-bis): Security Considerations for number and variety of SCTs

#9: Security Considerations for number and variety of SCTs

Changes (by benl <at> google.com):

 * status:  assigned => closed
 * resolution:   => needs-review

Comment:

 Proposed resolution: https://github.com/google/certificate-transparency-
 rfcs/commit/3f8420990b8a31df7249013e43800b8d3970c9b6.

--

-- 
--------------------------------------+------------------------------
 Reporter:  rob.stradling <at> comodo.com  |       Owner:  benl <at> google.com
     Type:  defect                    |      Status:  closed
 Priority:  minor                     |   Milestone:
Component:  rfc6962-bis               |     Version:
 Severity:  -                         |  Resolution:  needs-review
 Keywords:                            |
--------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/9#comment:2>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 5 Mar 13:45 2015
Picon

[trans] #61 (client-behavior): Precertificates are not proper nouns

#61: Precertificates are not proper nouns

 We should spell it "precertificate" not "Precertificate".

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  benl <at> google.com        |  rfc6962-bis <at> tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  client-      |    Version:
  behavior               |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/61>
trans <http://tools.ietf.org/trans/>
Eran Messeri | 4 Mar 11:41 2015
Picon

Update on recently closed trans trac tickets (Jan-March 2015)

Hi all,


Below is a summary of the activity on all recently-closed trac tickets.

I hope this summary would help other trans participants catch up and surface potential problems with the proposed resolutions.

We marked those tickets as closed as it was the only way for us to track that we’ve dealt with them - we expect them to be re-opened if there are issues with the proposed resolutions.

As Melinda said, in the future a new status will be used to indicate that a ticket has proposed resolution but needs a review.


42: redacted cert dangers

We’ve added a clarification on what can be considered “overly-redacted” precertificate (since there’s no standard for defining too-broad wildcards in X.509 certificates we could not refer to it). We’ve left out the implications for the client, as it’s up to the client to decide what to do when encountering such a Precertificate (and we do not intend to specify client behaviour, based on previous discussion in the last IETF meeting).


37: client gossping

The ticket correctly made the point that gossip is not well defined enough to make any concrete claims about it. Correspondingly, the BIS text was changed to be less prescriptive about how STHs are exchanged and point to the gossip I-D.


40: Auditor behavior

RFC6962 originally described ‘auditors’, but in a very broad way. We’ve realized that stand-alone auditing isn’t likely to happen (and wasn’t the intention of RFC6962 either), so we’ve clarified what additional auditing responsibilities each type of client can take upon itself.


13: Deal with server farm skew

Added text and an API call to address the problem of a log front-end not knowing about a recent STH another log front-end served.


17: Add advice on CNs

How to redact the CN? Non-contentious suggestion was to allow a single CN that matches the first dNSName entry and use the first entry in the redaction list for both.


19: Rejig API for efficiency/correctness

Originally a client had to make up to three calls to get an inclusion proof (get-sth, get-consistency, get-inclusion-proof). A new API has been added to get all three. This ticket was also partially addressed by the changes relevant to ticket 13 (server farm skew).


21: Clarify signature checking purpose and mechanism

The original goal was to clarify that this is a spam mitigation measure. As Stephen Kent pointed out, the way X.509 certificate validity checks are performed must be accurately specified so logs behave consistently. The BIS was changed to indicate that logs MUST accept certificate chains that are valid according to the X.509 verification rules and may accept ones that have expired, not yet valid, etc.



22: Explain why there are three delivery mechanisms for SCTs

Text was added to clarify the motivation for each.


25: Freezing a log's state

As a part of the metadata description for a log, its final valid STH has been added.


26: Precertificates: Find alternative format to X.509

After a lengthy discussion about the pros and cons of using X.509 for Precertificates, the consensus seemed to be using CMS signed-data objects for Precertificates.


27: Signature & hash alg specification

The original concern was that since RFC6962 defines hash and signature algorithms logs must use, clients must support both. Ben’s justification was that only EC signatures would have been fine but since there are IP concerns, RSA is specified as an alternative.


28: Algorithm agility

Concerned both algorithms used by logs and algorithms used for certificates acceptable by logs. The fix was to point out changing algorithms used by log is unnecessary (would require significant changes to all data structures) and a simple alternative would be to freeze a log and start a new one. As for algorithms used for certificates submitted to logs, the relevant RFCs already specify algorithm agility.


29: "what does ""immediately"" mean?"

The section that says this was removed from the draft.


32: algorithm needed for client checks of SCT

The original ticket was about specifying the details of checks a client should do when verifying SCTs. Ben believes that this has been addressed in the changes made to sections 3 and 5.


33: Cert chain length as log metadata

Added to the list of log metadata.


34: use of RFC 5246 syntax to define the SCT

ASN.1 was suggested as a more appropriate format for defining SCTs as they are served in multiple contexts. Rob and Ben argued that RFC5246 does not forbid the use of TLS encoding and that there are good reasons not to have multiple SCT formats (complexity, extra signing overhead).


36: error indications for log/client exchanges

A bunch of error codes were added.


43: key rollover

Log key roll-over is deemed unfeasible because it would add significant complexity to all data structures involved while a simpler way, of freezing the existing log and starting a new log, exists.


45: Incorporate RFC6962 errata

The errata was incorporated.


46: Provide explicit instructions for how log servers should handle already-logged certs

How should log handle certificates that already have SCTs embedded in them? Text was added to clarify that a log should return a different SCTs for a precertificate and its corresponding final X.509 certificate.


47: Clarify how to deal with (minor) DER violations when manipulating a TBSCertificate

Certificates with DER violations would be hard to manipulate by clients for the purpose of SCT checking. Ben suggested logs should log such certificates and return an error rather than issue an SCT (if they can detect the violations).


48: Enforce the rules for Name-constrained Intermediates

Text was added to indicate that client can verify an SCT corresponds to the certificate it arrived - which is the final certificate or a Precertificate that is appropriately name-constrained.

Not included is what the client  should be doing with the result of this check, as we do not specify client behaviour.


49: Explain why OCSP Stapling is acceptable but OCSP Fetching is not

Ben believes the current explanation is adequate.


54: Simplify name redaction

Closed as invalid as we (myself, Ben, Rob) decided not to use Rob’s simplification suggestion (personally I found it introduced different complexities).


56: """*"" domain labels MUST NOT be redacted"

There were no arguments in favour of allowing redaction of “*” domain labels, so the text was changed to reflect that it should not be done.


59: Clarify STH versioning

The STH versioning was rolled-back from V2 to V1 as the only addition, of the CtExtensions field, was not deemed necessary - and could always be added in the future.


35: server SCT transmission restriction is misstated

Small clarification that servers may send SCTs to clients if they are embedded in the certificate or in the stapled OCSP response, even if the client did not indicate it can receive SCTs in the TLS handshake.

_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Stephen Kent | 3 Mar 21:54 2015
Picon

changes to attack analysis

based on comments from Ben, I made changes to the attack model text.

The diffs appear below.

Steve
------

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 can alert the Subject. 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.) Since there is no requirement for a TLS client to reject a certificateIf clients do not reject certificates or otherwise notify users If clients do not reject certificates or otherwise notify users when no SCT is provided, the preferred strategy for an attacker is to not log bogus certificates. (See XX.1.2.2 and 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. Since TLS If clients are do not required to reject a certificate that lacks (certificates or is not accompanied by) an SCT, or even tootherwise notify a user in such situationsusers when no SCT is provided, the preferred strategy for an attacker willis to not be thwarted in this caselog bogus certificates. (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 “gossip” to detect conspiring logs, the bogus certificate will not be detected. BecauseUntil there are no requirementsis a (mandatory to implement) specification for such gossiping, an attack of this sort can succeed based on the current CT design.

 

 

 

 

XX.2.1

 

Since there is no requirement that a If TLS client can be configured to clients do not reject a certificatecertificates that hasdo not appear to have been syntactically checked by a log (as indicated by the SCT), a malicious CA need not worry about failing a log-based check. Similarly,

sinceif there is no requirement for a TLS client to reject a certificate that was logged by an operator that does not perform syntactic checks, the fourth approach noted above will succeed as well. If a client were configured to know which versions of certificate types are applicable to its use of a certificate, the second and third strategies noted above could 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. Since there is no requirement for a TLS client to If clients do not reject a certificate that lacks (certificates or is not accompanied by) an otherwise notify users when no SCT is provided, this form of mis-issuance will succeed. (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 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. A TLS clientsclient that relies on a syntactic checking by a log will believe that the certificate has been syntactically verified in this circumstance.

 

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. Since there is no requirement for a TLS client to If clients do not reject a certificate that lacks (certificates or is not accompanied by) an otherwise notify users when no SCT, there is no motivation is provided, the preferred strategy for an attacker to submit the certificate in this caseis to not log bogus certificates. (See Note 3.)

 

 

 

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 (even a self-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 bogus certificate.

 

The audit function is intended to detect logs that conspire to suppress log entries, based on consistency checking of logs and use of a “gossip” protocol. It is assumed that Monitors will perform the audit functions described in Section <insert #>.

A Monitor performing an audit function could alert its clients if the Monitor detects evidence of malfeasant log operation. This would cause Monitors to avoid using such a log, and clients would reject SCTs generated by such a log. BecauseUntil there is no defined gossip protocola (mandatory to implement) specification for gossiping, CT does not provide the necessary infocannot be relied upon to detect this form of mis-issuance. (See Note 5 below.)

 

Notes:

 

1.           The combination of a malicious CA and one or more conspiring logs motivates the definition of an audit function, 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 an audit) will CT be able to deter use of such logs. Thus the means by which a Monitor performing an audit function detect such logs, and inform TLS clients must be specified for this to be effective. Moreover, if a certificate (or TLS handshake) contains more than one SCT, unless the client verifies all of them if it is to counter the threat posed by conspiring logs.

 

Absent a (mandatory to implement) “gossip” protocol that enables Monitors to verify that data from logs are reported in a consistent fashion, CT does notcannot claim to provide protection against logs that may conspire with, or are 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.

 

<!-- /* Font Definitions */ <at> font-face {font-family:"MS 明朝"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-alt:"Optima ExtraBlack"; 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 Math"; 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:-536870145 1107305727 0 0 415 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:-536870145 1073743103 0 0 415 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:"MS 明朝"; 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:"MS 明朝"; 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:"MS 明朝"; 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:"MS 明朝"; 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:"MS 明朝"; 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;} span.msoIns {mso-style-type:export-only; mso-style-name:""; text-decoration:underline; text-underline:single; color:teal;} span.msoDel {mso-style-type:export-only; mso-style-name:""; text-decoration:line-through; color:red;} .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:"MS 明朝"; 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:62412295; mso-list-type:hybrid; mso-list-template-ids:-1399814162 640319620 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:94.0pt; text-indent:-58.0pt;} <at> list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:1.25in; text-indent:-.25in;} <at> list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:1.75in; text-indent:-9.0pt;} <at> list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:2.25in; text-indent:-.25in;} <at> list l0:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:2.75in; text-indent:-.25in;} <at> list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:3.25in; text-indent:-9.0pt;} <at> list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:3.75in; text-indent:-.25in;} <at> list l0:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:4.25in; text-indent:-.25in;} <at> list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:4.75in; 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
trans issue tracker | 2 Mar 19:19 2015
Picon

Re: [trans] #48 (rfc6962-bis): Enforce the rules for Name-constrained Intermediates

#48: Enforce the rules for Name-constrained Intermediates

Changes (by benl <at> google.com):

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

Comment:

 Closed with https://github.com/google/certificate-transparency-
 rfcs/commit/ef13d6c134911dc4d82816b5f0c45475c6cb2c4f.

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-trans-
  rob.stradling <at> comodo.com           |  rfc6962-bis <at> tools.ietf.org
     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/48#comment:1>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 2 Mar 19:15 2015
Picon

Re: [trans] #47 (rfc6962-bis): Clarify how to deal with (minor) DER violations when manipulating a TBSCertificate

#47: Clarify how to deal with (minor) DER violations when manipulating a
TBSCertificate

Changes (by benl <at> google.com):

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

Comment:

 Closed at https://github.com/google/certificate-transparency-
 rfcs/commit/b2e798e2d40a92989ce9c2855d099465bcea561f.

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-trans-
  rob.stradling <at> comodo.com           |  rfc6962-bis <at> tools.ietf.org
     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/47#comment:5>
trans <http://tools.ietf.org/trans/>
Eran Messeri | 2 Mar 16:06 2015
Picon

Errata for RFC6962 - precertificates_chain

I'm proposing that the reported errata for RFC6962 (here) would be accepted.
The new text:

   "precertificate_chain" is a chain of additional certificates required
   to verify the Precertificate submission.  The first certificate MAY
   be a valid Precertificate Signing Certificate and MUST certify the
   Precertificate.  Each following certificate MUST directly certify
   the one preceding it.  The final certificate MUST be a root
   certificate accepted by the log.

Has 'precertificate' in it rather than 'first certificate' as the first certificate in the precertificate_chain should certify the submitted precertificate, not any other certificate.

Any questions, let me know.
Eran
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
trans issue tracker | 2 Mar 14:58 2015
Picon

Re: [trans] #50 (client-behavior): Ordering of revocation checking and SCT processing by TLS Clients

#50: Ordering of revocation checking and SCT processing by TLS Clients

Changes (by benl <at> google.com):

 * component:  rfc6962-bis => client-behavior

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-trans-
  rob.stradling <at> comodo.com           |  rfc6962-bis <at> tools.ietf.org
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  client-behavior          |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/50#comment:2>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 27 Feb 16:34 2015
Picon

Re: [trans] #46 (rfc6962-bis): Provide explicit instructions for how log servers should handle already-logged certs

#46: Provide explicit instructions for how log servers should handle already-
logged certs

Changes (by benl <at> google.com):

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

Comment:

 Fixed by https://github.com/google/certificate-transparency-
 rfcs/commit/26354c90154c5849eb7c59f8e0b68aadaf8b2b9f.

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-trans-
  rick_andrews <at> symantec.com          |  rfc6962-bis <at> tools.ietf.org
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:  milestone1
Component:  rfc6962-bis              |     Version:  1.0
 Severity:  -                        |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

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

Gmane