Richard Barnes | 20 Nov 23:03 2014

[therightkey] Proposal: ACME list

As some of you may have heard, some of us have been working on a protocol to automate certificate management, including things like registration, enrollment, issuance, and revocation.

There is some similarity to existing CA-proprietary issuance APIs, and to projects like SSLMate.

Would folks be interested in spinning up an IETF mailing list on this topic?  It seems like we could probably get this in shape for a BoF in Dallas.

therightkey mailing list
therightkey <at>
Dr. Massimiliano Pala | 15 Nov 02:42 2014

[therightkey] Proposal for working on PKIX revocation open issues

Dear PKIX Enthusiasts,

Although great work has been done in the past... 20 years.. (?) on 
providing very good protocols in the PKIX work, I think that we all 
agree that we still have some unresolved issues. In particular, the 
revocation is still a hot topic (especially for online environments) 
could use improvement over the current status of things. In particular, 
by looking at current specifications, some work is needed to address 
concerns especially in non-web environments.

For example, current specifications about OCSP stapling do not address 
the case of client authentication (which is a widespread use case 
outside the web environment) or, again, defining some new transport 
protocols for delivering OCSP responses which might reduce operational 
costs for revocation service providers.

After proposing the idea to Stephen Farrell and Kathleen Moriarty, we 
would like to know if there might be interests in participating in 
updating the status of the current revocation mechanisms for PKIX. This 
said, the scope of the work I am proposing is very limited. Specifically:

(a) Defining new transport protocols for revocation information 
availability (e.g., OCSP over DNS or OCSP over LDAP)
(b) (Possibly) defining a more lightweight revocation mechanisms (e.g. 
Lightweight Revocation Tokens)
(c) (Possibly) helping other working groups to revise and update how 
revocation information are provided (e.g., the client authentication case)
(d) (Possibly) introducing privacy consideration when it comes to 
revocation checking

Because of these considerations, I am proposing to start a conversation 
- for now, Stephen and Kathleen suggested we use (or "abuse") the "The 
Right Key" mailing list to see if there might be enough interest in the 
work from implementers to address these issues. I know that we (OpenCA) 
are interested in implementing these features, and we would like that 
the work would be standardized.

At minimal, I would like (a) to happen. This could be achieved in 6 
months (and we might not even need to meet). (b) and (c) are also 
desirable in order to provide better support for non-browsers and small 
devices (AFAIK, some work might be relevant for DICE). (d) is something 
that we should, I think, all be mindful and at least some considerations 
should be provided. The scope of the work, however, will be limited to 

Please, if you are interested and would like to start the discussion, 
post your opinion on therightkey <at> - also, please, circulate this 
proposal to anybody who might be interested in collaborating on this issue.

Please also note that we did decide not to use the pkix <at> mailing 
list because we thought therightkey <at> might provide a more active 
pool of implementors.

Looking forward to receive all your inputs and start working on the topics.

trans issue tracker | 14 Nov 23:04 2014

[trans] #53 (rfc6962-bis): Clarify log entry ordering requirements

#53: Clarify log entry ordering requirements

 All but one of the RFC6962 logs that have so far requested inclusion in
 Chromium seem to list the entries in chronological order.

 Strict chronological order is nice, but it's not a requirement.  As long
 as each new entry gets included within the log's MMD, all is well.

 I think it could be worth stating explicitly that strict chronological
 ordering is not required (for logs) and must not be expected (by clients).


 Reporter:                           |      Owner:  draft-ietf-trans-
  rob.stradling <at>           |  rfc6962-bis <at>
     Type:  enhancement              |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:

Ticket URL: <>
trans <>
trans issue tracker | 10 Nov 16:41 2014

Re: [trans] #24 (rfc6962-bis): Add a section about log metadata

#24: Add a section about log metadata

Comment (by eranm <at>

 MMD should be included in the metadata.
 Ben also suggested: which browsers is the log included in, start date,
 whether the log has been turned down or not.


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

Ticket URL: <>
trans <>
trans issue tracker | 10 Nov 16:25 2014

Re: [trans] #30 (rfc6962-bis): Publish MMD as log metadata

#30: Publish MMD as log metadata

Changes (by eranm <at>

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


 Good point, I'll do it as a part of issue 24.


 Reporter:               |       Owner:  draft-ietf-trans-
  kent <at>           |  rfc6962-bis <at>
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:  duplicate
 Keywords:               |

Ticket URL: <>
trans <>
Salz, Rich | 6 Nov 04:19 2014

Log servers by Feb 2015?

Are any (other) log servers planning on being up and ready in production by Feb 2015, to meet the schedule requirements described by Google?

(See the PDF file attached here:




Principal Security Engineer, Akamai Technologies

IM: rsalz <at> Twitter: RichSalz


Trans mailing list
Trans <at>
Zhangdacheng (Dacheng | 5 Nov 04:17 2014

FW: New Version Notification for draft-zhang-trans-ct-binary-codes-00.txt

Hi, a preliminary document of CT for binaries is published. Any comments or suggestions will be really



> -----Original Message-----
> From: internet-drafts <at> [mailto:internet-drafts <at>]
> Sent: Monday, October 27, 2014 10:57 AM
> To: Zhangdacheng (Dacheng); Zhangdacheng (Dacheng)
> Subject: New Version Notification for draft-zhang-trans-ct-binary-codes-00.txt
> A new version of I-D, draft-zhang-trans-ct-binary-codes-00.txt
> has been successfully submitted by Dacheng Zhang and posted to the IETF
> repository.
> Name:		draft-zhang-trans-ct-binary-codes
> Revision:	00
> Title:		CT for Binary Codes
> Document date:	2014-10-27
> Group:		Individual Submission
> Pages:		8
> URL:
> Status:
> Htmlized:
> Abstract:
>    This document proposes a solution to use CT for publishing softwares/
>    binary codes and their signatuers.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> The IETF Secretariat
Melinda Shore | 30 Oct 04:21 2014

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 Shore | 18 Oct 03:00 2014

IETF schedule

In case you've missed it, the final agenda is out:

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

Linus Nordberg | 17 Oct 14:51 2014

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?

On a minor note, I think that "trusted" in the very first sentence
should be changed to "known. Should I use the issue tracker?
Ben Laurie | 16 Oct 17:09 2014

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>