Paul Wouters | 12 Apr 21:46 2015
Picon

Threat Analysis for CT adopted by the working group


Hi,

The call for adoption of a working group deliverable providing a threat
analysis has closed and there is a clear consensus for adoption.

Steve, can you submit a document as draft-ietf-trans-threat-analysis ?

It's also never to early to commit to reviewing a document, so if
you'd like to review this document, please let us now, and we will
send you reminders for your review.

Thanks,

Melinda & Paul
Tony Arcieri | 2 Apr 21:21 2015
Picon

Open source CT log implementations

Please let me know if it's way too early to consider this, but...

We run many in-house CA services, and I thought it would be interesting if they all reported to an in-house CT log each time they signed a CSR which we could use for record-keeping and auditing purposes.

I saw Google has the appropriate client code to do this (ostensibly hardcoded to report to Google's CT log), however AFAIK that log implementation isn't open source.

Are there any open source ones worth using? Are changes to the specification happening so quickly that this isn't advisable yet?

--
Tony Arcieri
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Phillip Hallam-Baker | 2 Apr 19:46 2015

[therightkey] Principle of least privilege...

CNNIC is an opportunity to learn from mistakes.

One conclusion I draw is that PKIX and OpenPGP have very different
expectations of trust providers. We could express OpenPGP key signings
as PKIX certificates but this would be a mistake. They are better
understood to be 'endorsements' rather than 'certificates'.

Another conclusion is that there is a lot of infrastructure in the
PKIX world that should not be abandoned or ignored lightly. Mistakes
are not evidence of a flawed system unless there is no adaptation. In
the wake of DigiNotar the Web PKI has changed significantly and we are
also in the process of adding TRANS.

A possible model for future PKI is to think in terms of a victorian
skyscraper. There is a steel structure and a brick exterior. Both are
necessary for the structure to stand up.

I think we need to rethink how the principle of least privilege
applies here and make sure we are doing everything we can to minimize
risk.

As a matter of policy, no cert should ever issue for a private key
that is not under the direct control of a CA unless one of the
following apply to the corresponding cert:

1) The other party has CP, CPS and full audit for operating a CA.
2) There is a name constraint.
3) It is an end entity certificate.

Further no private key should ever be in a network accessible device
unless the following apply:

1) There is a path length constraint that limits issue to EE certs.
2) It is an end entity certificate.
trans issue tracker | 1 Apr 16:50 2015
Picon

[trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA

#83: CT should mandate the use of deterministic ECDSA

 RFC:6979 describes how to do deterministic ECDSA.

 certificate transparency logs should be required to use this mechanism,
 for two reasons:

  * using non-deterministic ECDSA with a predictable source of randomness
 means that each signature can potentially leak the secret material of the
 signing key.

  * a log that produces two separate valid STHs with the same timestamp and
 same data but with different signatures should be considered dubious
 (though i don't have a concrete attack i can describe for this scenario
 yet) -- ensuring the use of deterministic ECDSA means that in normal
 operation, regular logs won't produce this behavior.

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  dkg <at> fifthhorseman.net  |  rfc6962-bis <at> tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/83>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 31 Mar 17:50 2015
Picon

[trans] #82 (client-behavior): add integrity validation to get-entries (and fetching SCTs?)

#82: add integrity validation to get-entries (and fetching SCTs?)

 When monitoring a log, get-entries provide no assurance against in-flight
 corruption. It will get caught once verifying the entries against an STH,
 but that makes it hard to act upon (can't tell which exactly entry is
 corrupted, for example).

 Also, the question of how to fetch the SCT for a logged entry has been
 asked a few times.

 One way to solve both problems at once would be to return the SCT
 signature in get-entries. The rest of the data for the SCT is already
 there, and since it's done over all this data and the entry's digest, it
 should provide a way to check the integrity of the entry.

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  pphaneuf <at> gmail.com     |  rfc6962-bis <at> tools.ietf.org
     Type:  enhancement  |     Status:  new
 Priority:  major        |  Milestone:
Component:  client-      |    Version:
  behavior               |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/82>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 31 Mar 12:03 2015
Picon

[trans] #81 (rfc6962-bis): OIDs and IANA Considerations

#81: OIDs and IANA Considerations

 We currently use various OIDs for certificate extensions and OCSP response
 extensions that have been allocated under Google's private OID arc.

 We could switch to using OIDs allocated under an IETF/IANA OID arc.

 Melinda noted that, regardless of which OID arc we ultimately settle on,
 the IANA Considerations section will need to be updated.

--

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

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/81>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 31 Mar 11:24 2015
Picon

[trans] #80 (client-behavior): Re-introduce the issuer key hash into the Precertificate

#80: Re-introduce the issuer key hash into the Precertificate

 In the current draft (07), when the entry_type in the
 SignedCertificateTimestamp is precert_entry_V2, the only thing included in
 the signature is the TBSCertificate.
 The issuer key identifier is not included - the implication being that an
 SCT for a precertificate would be valid regardless of who the final issuer
 will be, so the submitter of the precertificate is may not be bound to it
 in the SCT.
 (The Authority Key Identifier,
 https://tools.ietf.org/html/rfc5280#section-4.2.1.1, should uniquely
 identify the issuer but AIUI this could be the key or the issuer name and
 serial number and Rob Stradling pointed out that on some platforms the
 requirement this matches the issuer may not be enforced, as the stated
 goal of this extension is to facilitate path building).

 I propose re-introducing the issuer key hash and using it for X.509
 certificates in case ticket #4 is accepted (signing TBSCertificate for
 X.509 certificates as well).

--

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

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/80>
trans <http://tools.ietf.org/trans/>
Melinda Shore | 30 Mar 22:38 2015
Picon

Minutes uploaded

The minutes from our session at IETF 92 have been uploaded.
Many, many thanks to Rich Salz for recording these.  Please
send any corrections, comments, etc. to the mailing list.

Note that we currently have a call out for adoption of a
working group deliverable providing a threat analysis for
CT.  There's been some feedback but not much - please take a
look at http://www.ietf.org/proceedings/92/slides/slides-92-trans-0.pdf
as well as:
http://www.ietf.org/mail-archive/web/trans/current/msg00965.html
http://www.ietf.org/mail-archive/web/trans/current/msg00894.html
http://www.ietf.org/mail-archive/web/trans/current/msg00805.html

and the threads in which they appear.  The call for adoption closes
Friday, April 10.

Thanks,

Melinda
trans issue tracker | 27 Mar 17:08 2015
Picon

[trans] #79 (rfc6962-bis): Precertificate signature must be over something other than just the TBSCertificate

#79: Precertificate signature must be over something other than just the
TBSCertificate

 If I understand the CMS spec correctly, then we're currently defining a
 Precertificate to be a CMS structure that contains a TBSCertificate and a
 signature over just that TBSCertificate.
 That means that the components of a Precertificate can be trivially
 rearranged into an X.509 certificate with a valid signature!

 To fix this, we need to either...

 1. Require the SignedData.encapContentInfo.eContent field to contain
 "something || TBSCertificate" or "TBSCertificate || something".
 or
 2. Require a signed attribute to be present in
 SignedData.signerInfos[0].signedAttrs.  This is essentially equivalent to
 "TBSCertificate || something" in terms of what gets signed.

 I think 2 is the cleaner solution, unless there's a cryptographic reason
 to prefer "something || TBSCertificate" (e.g. to protect against chosen
 prefix collisions?)

--

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

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/79>
trans <http://tools.ietf.org/trans/>
Eran Messeri | 27 Mar 13:45 2015
Picon

AIA/cRL for logged certificates

I'd like to get opinions from the list on solutions to the following problem, which Ben originally pointed out. It applies to Precertificates currently, but would apply to X.509 certificates if ticket #4 is accepted.

An "undesirable" certificate is issued and logged (without including Authority Information Access / CRL distribution point) and upon discovery is revoked - the CRL distribution point in the issuer or one of the intermediate certs will list it as revoked.
That certificate would be signed a second time with the same issuer key, but not logged a second time (as the SCT produced for the first certificate is valid for the second one). When it is served, it is served together with a chain that is different than the one logged, and the issuer or intermediates in this chain point to a different AIA/CRL that does *not* show list this certificate as revoked (The implied assumption is that the attacker controls the private key of the issuer).

Implication: A client believes it has a legitimate certificate by validating the SCT and performing an online revocation check.

Potential mitigations:
- Require that the client only use the AIA/CRL distribution point from the chain logged in the CT log (which forces the client to fetch it online, before completing the connection).
- Require the presence of AIA/CRL distribution point in the end-entity certificate.

Any other suggestions?
Eran
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
trans issue tracker | 27 Mar 12:34 2015
Picon

Re: [trans] #4 (rfc6962-bis): Should we sign TBS for Certificates?

#4: Should we sign TBS for Certificates?

Comment (by rob.stradling <at> comodo.com):

 Eran, don't the existing PrecertChainEntryV2/X509ChainEntry structs
 already hold the original submission?

 Can't we resolve this ticket just by changing
 !SignedCertificateTimestamp.signed_entry and
 !TimestampedEntry.signed_entry from...
                select(entry_type) {
                    case x509_entry: ASN.1Cert;
                    case precert_entry_V2: TBSCertificate;
                } signed_entry;
 ...to...
                select(entry_type) {
                    case x509_entry: TBSCertificate;
                    case precert_entry_V2: TBSCertificate;
                } signed_entry;

 I think it makes sense to retain a different struct for each
 !LogEntryType, rather than try to unify them.  New !LogEntryType values
 might be defined in future that aren't unifiable with the existing two.

--

-- 
------------------------------+------------------------------
 Reporter:  eranm <at> google.com  |       Owner:  benl <at> google.com
     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/4#comment:4>
trans <http://tools.ietf.org/trans/>

Gmane