trans issue tracker | 21 May 17:27 2015
Picon

[Trans] [trans] #84 (rfc6962-bis): Clarify that root certs have empty certificate_chain

#84: Clarify that root certs have empty certificate_chain

 Suggested new text for 3.1 Log Entries in bis:

 {{{{
 "certificate_chain" is a chain of additional certificates required to
 verify the end-entity certificate.  If present, the first certificate
 MUST certify the end-entity certificate.  Each following certificate
 MUST directly certify the one preceding it.  The final certificate
 MUST either be, or be issued by, a root certificate accepted by the
 log.  A root certificate has an empty certificate_chain.
 }}}}

 See thread "Empty extra_data" for details.

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  linus <at> nordu.net        |  rfc6962-bis <at> tools.ietf.org
     Type:  enhancement  |     Status:  new
 Priority:  minor        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/84>
trans <http://tools.ietf.org/trans/>
Stephen Farrell | 18 May 16:50 2015
Picon
Picon

[Trans] question: short lived certs

(All those issue tracker mails reminded me of a question
I'd meant to and had forgotten to ask...)

At the acme BoF there was some talk of short lived certs.
The thought was that if acme succeeds then it'd be more
practical to use certs with a lifetime of a day or so. And
that might raise a question as to how that'd affect CT or if
there's an elegant way to support such.

I don't think this is something that has to be part of the
current bis RFC necessarily but it'd probably be good to
get the collective wisdom of the list on the topic.

So, what do we think of CT when faced with 1 day duration
certs or similar?

Ta,
S.
Linus Nordberg | 12 May 12:35 2015
Picon

[Trans] Empty extra_data

Hi,

I'd like to doublecheck that our reading of RFC6962 is correct regarding
how to store a submitted root cert.

--8<---------------cut here---------------start------------->8---
3.1.  Log Entries
...
   "leaf_certificate" is the end-entity certificate submitted for
   auditing.

   "certificate_chain" is a chain of additional certificates required to
   verify the end-entity certificate.  The first certificate MUST
   certify the end-entity certificate.  Each following certificate MUST
   directly certify the one preceding it.  The final certificate MUST be
   a root certificate accepted by the log.
--8<---------------cut here---------------end--------------->8---

In the case of a root certificate, our implementation treats the (only)
certificate as the leaf_certificate and sees certificate_chain as
empty.

v1/get-entries accordingly returns the cert in leaf_input and nothing in
extra_data.

Do you think that this is conformant with the specification?
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

Gmane