Ben Laurie | 17 Apr 19:07 2014
Picon

Infrastructure for logs?

My team is considering doing some work on the open source log
implementation to make it less of a reference implementation and more
something that you could consider running in (or adapting for) a
production environment.

It would help guide our thinking of those CAs (and others) who are
considering running logs would give us some hints about the kind of
production environment they would like to run in. In particular:

1. Operating systems.

2. Database managers.

3. Any other constraints you might have on a production environment.

Public discussion would be useful, but if you would rather tell me
privately that is also fine. Bear in mind that what we learn will
probably influence open source code, though that's obviously very
unlikely to reveal anything about anyone in particular.

--

-- 
Certificate Transparency is hiring! Let me know if you're interested.
internet-drafts | 17 Apr 14:47 2014
Picon

I-D Action: draft-ietf-trans-rfc6962-bis-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Public Notary Transparency  Working Group of the IETF.

        Title           : Certificate Transparency
        Authors         : Ben Laurie
                          Adam Langley
                          Emilia Kasper
                          Rob Stradling
	Filename        : draft-ietf-trans-rfc6962-bis-02.txt
	Pages           : 30
	Date            : 2014-04-17

Abstract:
   This document describes an experimental protocol for publicly logging
   the existence of Transport Layer Security (TLS) certificates as they
   are issued or observed, in a manner that allows anyone to audit
   certificate authority (CA) activity and notice the issuance of
   suspect certificates as well as to audit the certificate logs
   themselves.  The intent is that eventually clients would refuse to
   honor certificates that do not appear in a log, effectively forcing
   CAs to add all issued certificates to the logs.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

There's also a htmlized version available at:
(Continue reading)

Rob Stradling | 4 Apr 17:29 2014

Drafting text for 6962bis Issue 1

FYI, we're working on it here...

https://codereview.appspot.com/83200047/

--

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Jon Callas | 1 Apr 14:58 2014

Re: Comments on RFC6962

On Mar 10, 2014, at 5:18 PM, Phillip Hallam-Baker <hallam <at> gmail.com> wrote:

> Adding tags in JSON is straightforward and existing applications SHOULD simply ignore them. But we
should probably make some sort of explicit statement.

The above sounds pretty explicit to me. Who has the pen on the relevant documents?

	Jon
Ben Laurie | 31 Mar 17:35 2014
Picon

Re: RFC6962 BIS Log file encodings.

And to answer the original question...

On 13 March 2014 17:29, Phillip Hallam-Baker <hallam <at> gmail.com> wrote:
> I am trying to make sense of the log file encoding (section 3). this does
> not seem to me to be properly or clearly specified.
>
> RFC6962 punts the encoding question to RFC5246 but this only helps somewhat
> because the description there is atrocious.
>
> In particular it is implicit in the text that digitaly-signed is equivalent
> to the ASN.1 macro. But this isn't actually explained anywhere in section 4
> of 5246. So as a result there is no information on where the signature
> appears in the data stream, does it precede or follow the signed data?
>
> This is quite problematic because in the TLS use the signed data does not
> appear on the wire at all, the construct is used in client auth when the
> prior handshake is signed so there is no need to retransmit the data.
>
>
> It looks to me like the idea here is that the SCT does not need to include
> the certificate or precertificate data because the corresponding signed data
> will always be implicit from the mode of use.

Exactly.

> But that needs to be clearly
> stated.

RFC 5246 seems pretty clear already, from 4.7:

(Continue reading)

Dmitry Belyavsky | 31 Mar 10:21 2014
Picon

Re: Fwd: Certificate Transparency with Russian GOST algorithms

Dear Ben,

Sorry for my late response.

18.03.2014 18:20, Ben Laurie wrote:
On 11 March 2014 18:36, Melinda Shore <melinda.shore <at> gmail.com> wrote:
For some reason Dmitry's mail is not arriving at the
IETF server, so I thought I would forward it myself.

Melinda


-------- Original Message --------
Subject: Certificate Transparency with Russian GOST algorithms
Date: Tue, 11 Mar 2014 22:16:47 +0400
From: Dmitry Belyavsky <beldmit <at> tcinet.ru>
To: trans <at> ietf.org
CC: melinda.shore <at> gmail.com

Hi all!

Here are some thoughts about using CT in Russia with Russian
cryptographic algorithms (GOST). They were discussed with Ben Laurie
during the IETF meeting in London. I am not sure which mailing list is
the right place to post to, so I post it to the WG mailing list.

Laws and practice in Russia requires using of the GOST hash and digital
signature in X.509 certificates for government services. These
certificates are signed by Russians CAs which are not in lists of
trusted CAs in major browsers. It is not a problem to create an
installation of log server in Russia containing the list of Russian CAs.
But Russia-based service should use the GOST hash algorithm in the
Merkle tree and GOST signature algorithm for signing SCT. It seems to be
not a problem because if GOST-based certificates are submitted to
GOST-based log, browsers not understanding the GOST algorithms will not
have to verify GOST-based SCTs. But also it means that the hashing
algorithm of Merkle tree should become the config-time parameter of the
log instance instead of being hardcoded. Also it should be possible to
find out which algorithm is used in this or that log instance and it
should be strictly prohibited to change this algorithm after start of
the log instance. It seems to be a good idea anyway because of the
requirements of cryptographic algorithms agility.
As I mentioned elsewhere, in our view you change algorithm by starting
a new log.
Ok. What about a way to find out the algorithm in use?

The hash/signing algorithms are fixed properties of the log.

It seems to me there shouldn't be any difficulty accommodating GOST
like this - I guess we'd have to add the rule that non-GOST
certificates MUST NOT use GOST logs. Not sure whether we should
require the opposite, though (i.e. GOST certificates MUST NOT use
EC/SHA logs)?


What is expected to be a right behaviour in case when a certificate has SCT from some different log servers, if some of the SCT signatures can't be verified? If they are to be just ignored, I'm not sure we need such a limitation.



--
SY, Dmitry Belyavsky
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Rick Andrews | 28 Mar 17:46 2014

Angle brackets in the PRIVATE option (Ticket #1)

We see another potential issue with the proposed PRIVATE option. Rob’s current proposal would have us replace a domain label with the literal string “<PRIVATE>” (without the quotes). However, we try to encode DN components as PrintableString where possible, and angle brackets are not part of the PrintableString set (the lowercase letters 'a' through 'z', uppercase letters 'A' through 'Z', the digits '0' through '9', eleven special characters ' = ( ) + , - . / : ? and space).
 
As a result, the type of the DN component would be PrintableString in the real cert but utf8String in the pre-certificate, and that would cause problems. I suggest using parentheses instead of angle brackets.
 
-Rick
 
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Melinda Shore | 24 Mar 23:39 2014
Picon

IETF 89 Minutes

I've uploaded minutes from the London meeting to
http://www.ietf.org/proceedings/89/minutes/minutes-89-trans.
Please send comments/corrections/etc. to the mailing list.  Many,
many thanks to Mark Donnelly for his very detailed minute-taking.

Note as well that an audio recording of the session is available
here: http://www.ietf.org/audio/ietf89/ietf89-blenheim-20140305-1520-pm2.mp3

Thanks,

Melinda
Rick Andrews | 19 Mar 22:13 2014

Masking of private subdomains

Rob Stradling has proposed:
"The PreCertificate could contain SAN:dNSName=<PRIVATE>.customer.com (I mean the literal string
"<PRIVATE>"), and the real certificate could contain:
	•SAN:dNSName=top.secret.customer.com 
	•an extension that records the mapping between "top.secret" and "<PRIVATE>". I suggest a SEQUENCE of
INTEGERs, one for each Subject:commonName and SAN:dNSName (and in the same order that they appear in the
cert), indicating how many leftmost domain components are masked."

1) I agree there should be an extension to alert clients to the fact that a subdomain has been masked, but I'm
not sure I see the value in knowing how many leftmost domain components are masked. A monitor will notify
the domain owner that a certificate appeared in the log for their domain, with serial number 1234. The
domain owner will then search through their list of known certificates for one issued by that CA cert with
that serial number. Knowing the number of masked subdomains is of little or no value.

2) Consider a case where a cert contains multiple SANs from the same domain, all of which are to be masked:
	SAN1=foo.example.com
	SAN2=bar.example.com
	SAN3=foo.bar.example.com
All would be replaced with the same masked value. Should the precertificate hold duplicate information,
like this:
	SAN1=<PRIVATE>.example.com
	SAN2=<PRIVATE>.example.com
	SAN3=<PRIVATE>.example.com
Or should it contain only one <PRIVATE>.example.com? What's the value in knowing the number of SANs in the
cert if they're all masked?

-Rick

_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Taylor Hornby | 19 Mar 05:07 2014
Picon

[therightkey] Malicious Exit Nodes

Hi,

Something that's not considered in the DetecTor paper is what happens
when one or more Tor exit nodes are assumed to be malicious. Maybe this
has been discussed on this list before, but a quick search turned up
nothing, so sorry if this is a duplicate.

For example, a malicious Tor node could purposely MITM the SSL
connection, providing an incorrect certificate, to make the client's
actual connection fail (Denial of Service). It's also possible for
a malicious Tor node (or even a legitamete Tor node trying to save
bandwidth) to return cached certificates, hiding an attack.

I don't think this would be a huge problem, but it's something to
consider for future versions of the paper.

--

-- 
Taylor Hornby
Ben Laurie | 18 Mar 17:06 2014
Picon

Re: Updated agenda, etc.

On 11 March 2014 00:45, Hans Kuhn <hans <at> nsrc.org> wrote:
> On 3/3/14 6:28 AM, Ben Laurie wrote:
>
>> Is there some way to get trac to tell me about new tickets? I can't
>> find any options at all...
>
> Is there a reason not to use RSS?
>
> http://tools.ietf.org/wg/trans/trac/report/1?asc=1&format=rss

Not particularly - except my RSS to email convert apparently won't
send to my google.com account.

>
> Hans
>
>
> _______________________________________________
> Trans mailing list
> Trans <at> ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

Gmane