trans issue tracker | 1 Jul 11:56 2015

[Trans] [trans] #92 (rfc6962-bis): get-entries needs to return the whole X509ChainEntry

#92: get-entries needs to return the whole X509ChainEntry

 The "extra_data" returned by get-entries currently says:
   'In the case of an X509ChainEntry, this is the "certificate_chain"'

 This is insufficient.  A client that calls get-entries also needs the
 actual leaf certificate, so that they may verify that the leaf cert really
 was signed by the appropriate CA private key.  (Without this, the client
 would have to trust that the log performed that verification, unless the
 client happens to stumble upon that particular leaf cert some other


 Reporter:                           |      Owner:
  rob.stradling <at>           |  rob.stradling <at>
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:

Ticket URL: <>
trans <>
trans issue tracker | 29 Jun 16:36 2015

[Trans] [trans] #91 (client-behavior): Clarify encoding of fields in the log client messages

#91: Clarify encoding of fields in the log client messages

 In section 4, log client messages, some fields are missing encoding.
 For example, the get-sth message defines the sha256_root_hash to be
 base64-encoded but not tree_head_signature.


 Reporter:  eranm <at>  |      Owner:  eranm <at>
     Type:  defect            |     Status:  new
 Priority:  major             |  Milestone:
Component:  client-behavior   |    Version:
 Severity:  -                 |   Keywords:

Ticket URL: <>
trans <>
Ondrej Mikle | 26 Jun 16:29 2015

[Trans] Verifying inclusion proof

Pardon me if I am asking something obvious, but I'm missing one piece of
information for inclusion proof verification - the "placement" of each
node returned from "get-proof-by-hash" method in audit_path list
(whether it's left subtree or right subtree).

Since the hashing of concatenation of strings is not commutative, the
auditor needs to put the two partial tree hashes in correct order to get
to the correct root hash.

I'd guess the placement of the missing nodes from audit_path could be
derived from leaf_index and tree_size, but can't see a straightforward
way to do it. The reference client does not implement this verification

trans issue tracker | 23 Jun 23:38 2015

[Trans] [trans] #90 (rfc6962-bis): Clarify how to turn a MerkleTreeLeaf into a leaf hash

#90: Clarify how to turn a MerkleTreeLeaf into a leaf hash

 Section 3.5 "Merkle Tree" which is cross-referenced from "Log Client
 Messages" (sections 4.5 and 4.6) describes how 'the "hash" must be

 Section 3.5 first describes the data structure and then finishes with:
 'The leaves of the Merkle Tree are the leaf hashes of the corresponding
 "!MerkleTreeLeaf" structures.'

 At least two client implementers have incorrectly assumed that meant that
 the hash should be calculated as:

 If the implementer noticed the word "leaf" before hash, and carefully read
 section 2.1 they would realize that what they really need is:
 {{{HASH(0x00 || MerkleTreeLeaf)}}}

 I propose we add the following line to the last paragraph in Section 3.5
 to make this clearer:
 {{{Note that leaf hashes are calculated as HASH(0x00 || MerkleTreeLeaf).
 See Section 2.1 for further details.}}}

 Confused users:
 2. Me, independently doing exactly the same, first calling get-entries and
 then hashing the result leaf_input and sending to get-proof-by-hash.


(Continue reading)

Melinda Shore | 17 Jun 06:52 2015

Re: [Trans] direction for article

To be honest I'm not sure exactly who's deployed what
at this point, although we have been tracking implementations
of the protocol (see:

But this is very different from what Amazon is doing.
They're basically creating an additional certification
authority (nit: Bishop's article calls it a "certificate
authority"; it's actually "certification authority").

What CT does is provide an auditing mechanism to detect
bogus certificates in the wild and is a response to known
compromises and operational errors at CAs, broadly known
as "misissuance."  "Misissuance" includes things like
CAs issuing certificates for a domain to another
party without the domain's knowledge (for example,
if I trick someone into issuing me a certificate for, or a rogue or compromised CA issues one).
The Amazon move is probably interesting from a business
perspective but probably not particularly from a technical one.

The IETF is ramping up an effort to automate certificate
management and issuance and there's a parallel implementation
project out of Mozilla, and you might find that
interesting (and possibly relevant).  With the push to
deploy HTTPS everywhere, certificates really need to be
a lot easier to manage.  It seems possible that Amazon
is getting into the CA business for similar reasons -
growth in the certificate business from the drive towards
ubiquitous HTTPS.

(Continue reading)

Cooley, Dorothy E CIV (US | 16 Jun 20:34 2015

Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt



This is my first post on list ever, so be gentle :)



General:  This is actually an attack model with an analysis of detection and consequence.  Perhaps the name could be changed to reflect that.

General:  2.2’s outline should follow 2.1’s outline.  Move ‘Malicious or conspiring third party Monitor’ to section and remove it from and  It may be complete either way, but it is more likely to look complete if it is symmetric.

General:  Remove the references to the Notes in Sections 2 and 3.  They will stand alone.

Section  Change to:
“If a Subject is tracking the log(s) to which a certificate was submitted, and is performing self-monitoring, then it will be able to detect a bogus (pre-) certificate and request revocation. 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 investigate/revoke it.”

Section,,, :  Make the “If there are many logs, it may not be feasible for a Subject to track all of them” a note in Section 4 (it is sort of Note 1 currently).

Section  Change this in a similar manner to, for the same reasons.

Section  How will gossiping detect this?  The Log owner issues the SCT, but doesn’t actually put the certificate into the log.  How is this detectable by gossiping?  Not like an attacker is going to submit that certificate to multiple logs.  He just wants the SCT.

Section 2.1.2:  Does the 3rd party monitor have a role in the case where the certificate isn’t logged?  Should that fact be stated?  Perhaps a sentence to that effect in Section would be in order?

Section  Either remove the last sentence in the parenthetical, or work it into the paragraph without the parenthetical.

Section  Add a section on Self-monitoring Subject and a section on benign third party Monitor.

Section and  Combine these into Section called malicious or conspiring third party monitor.

Section 3, Syntactic checks:  We need to think about whether this makes sense.  This paper gets much simpler w/out it.  Currently not included in rfc6962bis.

Section 4, Notes:  These are issues that will need to be addressed.  I would make a more descriptive name and keep them numbered.

Section 4, Note 1:  Make this two items.  First:  How are new logs discovered by monitors?  Second:  how does a subject know which logs the monitor is checking?


Deb Cooley

dorothy.e.cooley6.civ <at>


Trans mailing list
Trans <at>
Phillip Hallam-Baker | 12 Jun 19:38 2015

Private Key Manager

All, I am currently in the final stages of work on a personal private key manager. At this point I have rough drafts of code for the UI, services and persistence logs. I just thought I would sanity check the design at this point. 

The objective is to have a mechanism that allows for convenient management of personal private keys for any sort of application or device. Secure email requires public key pairs, so does SSH, so do IoT devices. Back in 1995 when OpenPGP and S/MIME were getting started, key generation took minutes. Keys were quite big in relation to machine size. We didn't have protocols for managing them. So we ended up with an approach where we try to share keys between machines and a CA business model based on selling certificates rather than service.

For reasons that will become apparent, it is easiest to describe this approach in PKIX terms and to use PKIX for the management of the personal hierarchy. But remember that this is a personal hierarchy so the only trust relationships are of the form Alice trusts Alice's device. And further we are applying least privilege at each step. The use of PKIX to form the personal hierarchy does not commit us to use the same approach for Alice trusts Bob type trust relationships. These are quite separate. Further we are going to be using OpenPGP style fingerprint type approaches to support direct trust.

This is where I want to end up in 2020

* Every device I own has a unique device key.
* Every device I own uses a separate key for application level authentication-type purposes.
* For applications such as end-to-end email, groups of devices MAY share a common decryption key.
   * End entity Decryption keys MAY be escrowed under a personal recovery key
   * End entity Decryption keys are rotated on a monthy cycle to mitigate consequences of lost devices
* Authorizing a new device is a simple, minimal process requiring no skill or technical knowledge
* All device management processes apart from authorization/deauthorization are automatic

Some nomenclature:

* Principal = Owner of the personal hierarchy, in PKIX terms the 'subject'. the change of nomenclature here is deliberate because the point is to enfranchise every Internet user as a principal in their own right, not a serf or subordinate of another. 

* Device = a computer, mobile phone, light switch, dalek, sous vide, set top box, Han in Carbonite

* Admin Device = a device, typically a computer or tablet reserved for the purpose that is authorized to authorize new devices.
* Host Device = any device that is authorized but not a master device
* Potential Host Device = a device that isn't authorized with a key yet

* Private Key Management Service = An untrusted JSON/HTTP style service that helps manage the keys.

By untrusted, I mean that the degree of trust in the service is strictly bounded. The service never has an unencrypted private key. The service has no means of obtaining an unencrypted private key. The service cannot perform a DoS attack and MAY be changed at any time at the option of the principal, a principal may use multiple services at the same time. The operation of the service is also transparent.

Behind the scenes we have a PKIX style PKI:

* I have one master key signing key that is backed up using offline techniques that make compromise virtually impossible. It has a 150 year lifespan.

* I have an intermediate key signing key that is used to sign or cross sign every one of my end-entity certs with a ten year lifespan.
* I have a personal escrow key that is used to enable recovery of keys used for stored data

* End Entity keys for Authentication
* End Entity keys for personal code Signing
* End Entity Keys for email encryption (update once a month)
* End entity keys for signed email (unique per device, update once a month)

By 'update', I mean generate new keys. 

A mobile phone would typically have:

* A device key used to authenticate interactions with the Key Service
* A device key used to decrypt private keys used in key distribution
* The current month's email signature key for that device
* Email decryption keys for this month and possibly for prior months.

Note that the client can use the same keys for S/MIME and OpenPGP. Though in practice this is probably more interesting for encryption than signature.

Any type of key, public, private or symmetric MAY be represented as a fingerprint. fingerprints may be used with addresses to create a strong address.

So lets say the private key service has a public key with fingerprint MOFWH-O23KM-VTGW4-LXNJU-HEZTM. The config file for a user's master client might specify the use of the JPKM service at as:

This can be automatically expanded to a well known service endpoint and trust anchor:

   Cert chain MUST contain a keyinfo with fingerprint MOFWH-O23KM-VTGW4-LXNJU-HEZTM

OK, can't get fooled by the key service but it isn't trusted. What we do need to trust however is our connection to whatever audit services we might want to contact to see that our data has been registered correctly.

The private keys for the Master and Recovery keys are encrypted under a randomly generated symmetric key which is then split using Shamir's K of N scheme (I have implemented this up to 15 of 16). The encrypted blob is stored in the cloud through the JPKE service using the fingerprint of the symmetric key as an index.

To prevent DoS attack on the key servers, registration may require a proof of work for unauthenticated registrations.

I have not fully defined all the modes of device management yet. It seems to me that these need to be very different for devices with network capability, displays and/or input capability than pure IoT devices where QR codes are likely to be more appropriate.

If I set up my PPH on my desktop, I should be able to enable my phone as a Host Device as follows:

* Start app on my mobile phone, give it my account name and chosen private key manager service.
** App displays key fingerprint of my PPH proving I have bound to the correct hierarchy
** App displays fingerprint of device key
* Go to my desktop, start the app, see that I have a pending request to bind the phone
** Check that the fingerprint matches that of the phone
** Accept it

'Magic happens automatically till the phone is stolen'

* Start app on my desktop
* Deauthorize stolen phone

'Phone is found again'

* Start app on my desktop
* Reauthorize stolen phone

'phone is to be sold'
* Deauthorize phone using app on the phone itself

The operations supported by the PKM are thus:

General Service Management:
1) Request Service Description 
2) Register Client

Key Escrow:
1) Store encrypted private key
2) Recover encrypted private key
3) Verify encrypted key hash

Device Management [Potential Host Device requests]
1) Register device keys
2) Retrieve device certs and decryption keys [as needed]
3) Deregister device

Device Management [Admin Device]
1) Download pending requests
2) Accept/reject requests

A Private Key Manager may be a member of a transparency/fallover cloud.

To make sure the Private Key Manager hasn't defected and has only stored the keys locally, we can contact any member of the cloud and ask them if they have a copy of the encrypted private key. To do this we simply ask them to give us the HMAC of the private key file under a randomly chosen nonce.

Longer than I intended. Does this make sense?
therightkey mailing list
therightkey <at>
trans issue tracker | 12 Jun 19:27 2015

[Trans] [trans] #89 (rfc6962-bis): get-entries: "end" greater than "tree_size" should be allowed

#89: get-entries: "end" greater than "tree_size" should be allowed

 There could be skew between frontends of a log server that uses a
 distributed implementation, which means that a get-sth request could
 return a certain tree size, but that a follow up get-entries request could
 go to another frontend that is slightly behind, and not have all the
 entries necessary.

 At the minimum, this bit of section 4.7 should be removed:

 > The "start" and "end" parameters SHOULD be within the range 0 <= x <
 "tree_size" as returned by "get-sth" in Section 4.3.

 That paragraph already somewhat conflicts with this later paragraph in the
 same section:

 > Because of skew, it is possible the log server will not have any entries
 between "start" and "end".  In this case it MUST return an empty "entries"

 This should be clarified that a log server might not have *all* the
 entries (it might still have some of them). If a subset is returned, I
 feel that the entries should still be sequential and begin with the entry
 specified by "start", of course.

 Looking at some of the new methods designed to work reduce the impact of
 possible skew (like "get-all-by-hash"), one could imagine a new method
 that returns both entries and the latest STH, so that whatever is obtained
 can be verified.

 For example, if "get-sth" gave a tree size of 10, and the client then
 issues a "get-entries" with a "start" of 5, and an "end" of 9, but the
 frontend this request goes to only has a tree size of 8, it could return
 entries 5 to 7, as well as an STH with a tree size of 8, so that those
 entries could be verified.


 Reporter:               |      Owner:  draft-ietf-trans-
  pphaneuf <at>     |  rfc6962-bis <at>
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:

Ticket URL: <>
trans <>
trans issue tracker | 12 Jun 18:36 2015

[Trans] [trans] #88 (client-behavior): get-entries: "end" should be greater-than-or-equal to "start"

#88: get-entries: "end" should be greater-than-or-equal to "start"

 In section 4.7 ("Retrieve Entries from Log"), valid values for "start" and
 "end" are expressed in painstaking details...

 But never is it mentioned that "start <= end". It does seem obvious, but
 should be written down, I think.


 Reporter:               |      Owner:  draft-ietf-trans-
  pphaneuf <at>     |  rfc6962-bis <at>
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  client-      |    Version:
  behavior               |   Keywords:
 Severity:  -            |

Ticket URL: <>
trans <>
trans issue tracker | 11 Jun 17:47 2015

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

#4: Should we sign TBS for Certificates?

Changes (by melinda.shore <at>

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


 Reporter:  eranm <at>  |       Owner:  rob.stradling <at>
     Type:  defect            |      Status:  closed
 Priority:  major             |   Milestone:  review
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:  fixed
 Keywords:                    |

Ticket URL: <>
trans <>
trans issue tracker | 11 Jun 17:44 2015

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

#4: Should we sign TBS for Certificates?

Changes (by rob.stradling <at>

 * owner:  benl <at> => rob.stradling <at>
 * status:  new => assigned
 * milestone:   => review




 Reporter:  eranm <at>  |       Owner:  rob.stradling <at>
     Type:  defect            |      Status:  assigned
 Priority:  major             |   Milestone:  review
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:
 Keywords:                    |

Ticket URL: <>
trans <>