Subject: [Trans] Log Monitoring API

From: Rob Stradling <[email-masked]>
Date: Thu, 11 Jun 2015 12:16:02 +0100

6962-bis notes that:
   "Those who are concerned about misissue can monitor the logs, asking
    them regularly for all new entries, and can thus check whether
    domains they are responsible for have had certificates issued that
    they did not expect."

If you act as a monitor yourself, you can be sure that the logs you're 
monitoring aren't misbehaving.  You don't have to trust the logs.

However, if you use the services of a third-party monitor instead (which 
I expect most domain owners would prefer to do), then you have to trust 
that that third-party monitor isn't hiding any certs from you.

Therefore, ISTM that some domain owners might want to be able to use the 
services of multiple independent monitors simultaneously.

To facilitate this, it would be useful to define a standard API for 
querying a monitor.  This API would allow callers to search for certs 
issued to a particular domain name/space, setup notifications of 
(mis-)issuance, etc.

Matt Palmer and I are planning to start work on a -00 draft soon.  If 
anyone else would like to get involved, please let us know.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Matt Palmer <[email-masked]>
Date: Thu, 11 Jun 2015 22:17:58 +1000

On Thu, Jun 11, 2015 at 12:16:02PM +0100, Rob Stradling wrote:
> However, if you use the services of a third-party monitor instead (which I
> expect most domain owners would prefer to do), then you have to trust that
> that third-party monitor isn't hiding any certs from you.
> 
> To facilitate this, it would be useful to define a standard API for querying
> a monitor.  This API would allow callers to search for certs issued to a
> particular domain name/space, setup notifications of (mis-)issuance, etc.
> 
> Matt Palmer and I are planning to start work on a -00 draft soon.  If anyone
> else would like to get involved, please let us know.

Speaking for myself, I'm coming at this largely from the perspective of
someone who is implementing a monitor (OSS code release imminent).  It would
be good to get one or more "typical users" of a third-party monitor on board
this effort, to ensure that the spec provides a solid set of endpoints for
users of a monitor to work with.

- Matt

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 11 Jun 2015 11:30:54 +0000

Hi,

It is not surprising to see a member of a CA propose to expand the 
business market around CA's.  (CAs and CA monitors).  

The suggestion is reasonable, though I hazard to suggest that a 
copylefted reference implementation of log monitoring for some set of 
domain names would be a valuable contribution.  

Indeed the new CA monitors could use it to make a nice profit/offer a useful service:
Comodo monitors Verisign who monitor GoDaddy who monitor ...  You get the idea.

--
Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk
________________________________________
From: Trans [[email-masked]] on behalf of Rob Stradling [[email-masked]]
Sent: Thursday, 11 June 2015 13:16
To: [email-masked]
Cc: Matt Palmer
Subject: [Trans] Log Monitoring API

6962-bis notes that:

_______________________________________________
Trans mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trans

---

From: Matt Palmer <[email-masked]>
Date: Thu, 11 Jun 2015 23:55:06 +1000

> business market around CA's.  (CAs and CA monitors).  

Not a CA here.

> domain names would be a valuable contribution.  

It's on its way.

> Comodo monitors Verisign who monitor GoDaddy who monitor ...  You get the idea.

Or, one or more independent monitors keep an eye on *everyone*...

- Matt

-- 
Java. The elegant simplicity of C++. The blazing speed of Smalltalk.
		-- From http://c2.com/cgi/wiki?SmalltalkMinusMinus

---

From: Jeremy Rowley <[email-masked]>
Date: Thu, 11 Jun 2015 15:20:41 +0000

Hi Rob - we'd like to get involved as we already have an API for our cert monitoring software. 

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Rob Stradling
Sent: Thursday, June 11, 2015 5:16 AM
To: [email-masked]
Cc: Matt Palmer
Subject: [Trans] Log Monitoring API

6962-bis notes that:

If you act as a monitor yourself, you can be sure that the logs you're monitoring aren't misbehaving.  You don't have to trust the logs.

However, if you use the services of a third-party monitor instead (which I expect most domain owners would prefer to do), then you have to trust that that third-party monitor isn't hiding any certs from you.

Therefore, ISTM that some domain owners might want to be able to use the services of multiple independent monitors simultaneously.

To facilitate this, it would be useful to define a standard API for querying a monitor.  This API would allow callers to search for certs issued to a particular domain name/space, setup notifications of (mis-)issuance, etc.

Matt Palmer and I are planning to start work on a -00 draft soon.  If anyone else would like to get involved, please let us know.

---

From: Jeremy Rowley <[email-masked]>
Date: Thu, 11 Jun 2015 15:27:47 +0000

Also, both monitoring services already out there (DigiCert and Comodo) are both free...

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Matt Palmer
Sent: Thursday, June 11, 2015 7:55 AM
To: [email-masked]
Subject: Re: [Trans] Log Monitoring API

Not a CA here.

It's on its way.

- Matt

---

From: Rob Stradling <[email-masked]>
Date: Thu, 11 Jun 2015 16:28:54 +0100

>> business market around CA's.  (CAs and CA monitors).

Business market?  Not my area of expertise.  I just sit in the corner 
and write code.  :-)

I'm not sure if it'll be viable to monetize a monitoring service 
directly, especially if there are free monitoring services available.  I 
wouldn't be surprised to see CAs choosing to bundle monitoring for free 
with their certificate products.

But anyway, this list probably isn't the right place to discuss business 
models.  :-)

>> domain names would be a valuable contribution.

Ditto (hopefully).

<snip>

---

From: Rob Stradling <[email-masked]>
Date: Thu, 11 Jun 2015 16:32:57 +0100

On 11/06/15 16:20, Jeremy Rowley wrote:
> Hi Rob - we'd like to get involved

Great.  I thought you might.  Thanks Jeremy.

> as we already have an API for our cert monitoring software.

Can you share any documentation?  This would be a useful input to our 
initial discussions.

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 11 Jun 2015 15:33:16 +0000

From: Trans [[email-masked]] on behalf of Jeremy Rowley [[email-masked]]
Sent: Thursday, 11 June 2015 17:27
To: Matt Palmer; [email-masked]
Subject: Re: [Trans] Log Monitoring API

# Okay.  I shut up now.  But, the reference implementation is important because it enables other services to be gratis if those deployed change their status.
#
# Hats off to all for their efforts in this essential area/service/work.
#
# With respect,  Hugo Connery

[snip].

---

From: Jeremy Rowley <[email-masked]>
Date: Thu, 11 Jun 2015 15:35:12 +0000

Yes - the API isn't public yet, but I'll see if I can share the documentation. 

Thanks Rob!

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Thursday, June 11, 2015 9:33 AM
To: Jeremy Rowley; [email-masked]
Cc: Matt Palmer
Subject: Re: [Trans] Log Monitoring API

> as we already have an API for our cert monitoring software.

Can you share any documentation?  This would be a useful input to our initial discussions.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jun 2015 17:40:55 -0400

Rob,

> monitoring aren't misbehaving.  You don't have to trust the logs.
I'm not sure I follow your argument above. If I act as my own monitor, I 
will see the cert
issued to me, I can verify that it has one or more SCTs, and I could go 
to each log for which
there is an SCT, to verify that the entry in in the log. But, how do I 
know that the logs
that I contact are not misbehaving? They could show me entries other 
than ones that might
conflict with my name space. Detection of that behavior is the job of 
the audit function,
not a Monitor, right?
> However, if you use the services of a third-party monitor instead 
> (which I expect most domain owners would prefer to do), then you have 
> to trust that that third-party monitor isn't hiding any certs from you.
agreed, but that's not the same as log misbehavior; it's Monitor 
misbehavior.
> Therefore, ISTM that some domain owners might want to be able to use 
> the services of multiple independent monitors simultaneously.
sure.
> issued to a particular domain name/space, setup notifications of 
I'm always in favor of interface standards, but this is not the sort of 
API I would have imagined.
I've thought that one might want a standard way for a client of a 
Monitor to submit the info needed
for the Monitor to "protect" the client: a set Subject names/SANs, a set 
of public keys associated
with each Subject/SAN, and a way to inform the client when a cert is 
logged that does not match
the supplied info.  One also should be able to include an indication of 
what cert profile these
certs are supposed to match, e.g., DV, EV, SMIME, IPsec, ...

Consider this my contribution to your draft.

Steve

---

From: Matt Palmer <[email-masked]>
Date: Fri, 12 Jun 2015 19:05:07 +1000

Hi Stephen,

> API I would have imagined.  I've thought that one might want a standard
> way for a client of a Monitor to submit the info needed for the Monitor to
> "protect" the client: a set Subject names/SANs, a set of public keys
> associated with each Subject/SAN, and a way to inform the client when a
> cert is logged that does not match the supplied info.  One also should be
> able to include an indication of what cert profile these certs are
> supposed to match, e.g., DV, EV, SMIME, IPsec, ...

I believe that comes under Rob's very general point of "setup notifications
for (mis-)issuance".  I certainly intend to try and provide means for
specifying as much detail as possible to assist in detecting misissuance.

> Consider this my contribution to your draft.

Thanks for your input.  It's good to know that someone else thinks it would
be useful to be able to manipulate notifications programmatically.

- Matt

-- 
"The user-friendly computer is a red herring. The user-friendliness of a
book just makes it easier to turn pages. There's nothing user-friendly about
learning to read."
		-- Alan Kay

---

From: Rob Stradling <[email-masked]>
Date: Fri, 12 Jun 2015 10:49:45 +0100

On 12/06/15 10:05, Matt Palmer wrote:
> for (mis-)issuance".

Yep.  Thanks Matt.

> I certainly intend to try and provide means for

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 12 Jun 2015 10:57:41 +0100

On 11/06/15 22:40, Stephen Kent wrote:
> I'm not sure I follow your argument above.
<snip>

Hi Steve.  I was aiming for a quick summary rather than a 
fully-specified problem statement.  You're correct that the audit role 
is vital too.

If the CT ecosystem is functioning as intended, then a monitor can be 
sure that they've seen every logged cert, without having to trust the log.

But a client of a monitor has to trust the monitor.

Is that any clearer?

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Jun 2015 13:34:44 -0400

Rob,

> sure that they've seen every logged cert, without having to trust the 
yes.
> But a client of a monitor has to trust the monitor.
agreed.
> Is that any clearer?
yes.