internet-drafts | 21 Jul 12:06 2016
Picon

[Trans] I-D Action: draft-ietf-trans-rfc6962-bis-17.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  of the IETF.

        Title           : Certificate Transparency
        Authors         : Ben Laurie
                          Adam Langley
                          Emilia Kasper
                          Eran Messeri
                          Rob Stradling
	Filename        : draft-ietf-trans-rfc6962-bis-17.txt
	Pages           : 55
	Date            : 2016-07-21

Abstract:
   This document describes a 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 certification
   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/

(Continue reading)

trans issue tracker | 19 Jul 17:27 2016
Picon

Re: [Trans] [trans] #111 (to-be-decided): Consider using the cached-info TLS extension

#111: Consider using the cached-info TLS extension

Comment (by rob.stradling <at> comodo.com):

 cached-info is now an RFC...

 https://www.rfc-editor.org/info/rfc7924

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rob.stradling <at> comodo.com           |  rob.stradling <at> comodo.com
     Type:  enhancement              |      Status:  new
 Priority:  minor                    |   Milestone:
Component:  to-be-decided            |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/111#comment:5>
trans <https://tools.ietf.org/trans/>
Melinda Shore | 18 Jul 18:21 2016
Picon

[Trans] Reminder, tonight

This is just a reminder that we will be meeting tonight
for an informal discussion of the gossip draft.  We have
reserved Köpenick III at 8pm.

Melinda

_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
internet-drafts | 8 Jul 22:04 2016
Picon

[Trans] I-D Action: draft-ietf-trans-gossip-03.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  of the IETF.

        Title           : Gossiping in CT
        Authors         : Linus Nordberg
                          Daniel Kahn Gillmor
                          Tom Ritter
	Filename        : draft-ietf-trans-gossip-03.txt
	Pages           : 56
	Date            : 2016-07-08

Abstract:
   The logs in Certificate Transparency are untrusted in the sense that
   the users of the system don't have to trust that they behave
   correctly since the behavior of a log can be verified to be correct.

   This document tries to solve the problem with logs presenting a
   "split view" of their operations.  It describes three gossiping
   mechanisms for Certificate Transparency: SCT Feedback, STH
   Pollination and Trusted Auditor Relationship.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-trans-gossip-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-gossip-03
(Continue reading)

"IETF Secretariat" | 30 Jun 19:44 2016
Picon

[Trans] trans - Requested session has been scheduled for IETF 96

Dear Melinda Shore,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

trans Session 1 (1:00:00)
    Wednesday, Morning Session I 1000-1230
    Room Name: Charlottenburg I size: 80
    ---------------------------------------------

Special Note: CANCELED

Request Information:

---------------------------------------------------------
Working Group Name: Public Notary Transparency 
Area Name: Security Area
Session Requester: Melinda Shore

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: dane curdle dnsop tls
 Second Priority: ipsecme saag

Special Requests:

---------------------------------------------------------
(Continue reading)

"IETF Secretariat" | 24 Jun 18:00 2016
Picon

[Trans] trans - Requested session has been scheduled for IETF 96

Dear Melinda Shore,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

trans Session 1 (1:00:00)
    Wednesday, Morning Session I 1000-1230
    Room Name: Charlottenburg I size: 80
    ---------------------------------------------

Special Note: 10:00-11:00

Request Information:

---------------------------------------------------------
Working Group Name: Public Notary Transparency 
Area Name: Security Area
Session Requester: Melinda Shore

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: dane curdle dnsop tls
 Second Priority: ipsecme saag

Special Requests:

---------------------------------------------------------
(Continue reading)

Steve | 21 Jun 18:26 2016
Picon
Gravatar

Re: [Trans] Suggesting an alternative mechanism for name redaction

So a real world situation has been brought forward that requires CT to care about visibility of subdomains when ownership of name property is granted from ICANN at the level of the visible content in a redacted name?


On Tue, Jun 21, 2016, 9:16 AM Eran Messeri <eranm <at> google.com> wrote:
FYI proposed text for this change (unreviewed) is in https://github.com/google/certificate-transparency-rfcs/pull/175

On Tue, Jun 21, 2016 at 4:56 PM, Steve <steve.medin <at> gmail.com> wrote:

If a client can un-redact, what's the point of redaction?

A  monitor of the log which observes a certificate with redacted dNSName fields and has a list of subdomains for that domain (for example, because it is operated by the legitimate domain owner who knows about all the subdomains registered under this domain) can distinguish between a redacted cert for one of the known subdomains and a redacted cert for an unknown subdomain.
TLS clients have to receive the un-redacted certificate, but having the redacted dNSNames alongside the unredacted ones allows clients to apply a policy for determining whether the redaction is acceptable or not.

Kind regards,
Steve


On Tue, Jun 21, 2016, 12:35 AM Andrew Ayer <agwa <at> andrewayer.name> wrote:
Hi Rob,

On Mon, 20 Jun 2016 14:39:00 +0100
Rob Stradling <rob.stradling <at> comodo.com> wrote:

> 1. When redacting a LABEL in the "redacted SAN" extension, the issuer
> replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of
> just "?".
>
> 2. If the client desires stronger SCT matching, it checks that each
> redacted label in the redacted SAN extension matches the
> corresponding label in the SAN extension, by computing HASH
> (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of
> the certificate.

I'm a little uneasy about using the serial number, because of
the ways that serial numbers can be, and are, incorrectly encoded (e.g.
not minimally encoded, or a "positive" integer with the MSB set).  I
think it's simpler and more robust for the client to take the salt out
of an extension, so it can be treated as an opaque blob and therefore
be unaffected by the vagaries of parsers.
Per this feedback, the proposed text requires the use of all bytes used to encode the serial number, including the tag and length bytes.

> - Provides a (partial) technical solution to 'un'redaction (which is
> something that needs to be addressed before Chrome will ever support
> redaction [1]): If a domain owner's certificate team observes an
> unexpected precertificate, they can calculate HASH(SERIAL_NUMBER||
> LABEL) for all of the LABELs they manage.

Another way to support "un-redaction" is to just leave the salt
extension in the pre-certificate instead of removing it.  I'd prefer
that approach if this style of un-redaction is desired.
The reason I'm uneasy with the salt as a separate extension is it adds some complications (another extension to remove, another thing to get right when matching the redacted labels with unredacted ones). As far as I can tell, the serial number could serve the same purpose. 

Regards,
Andrew

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

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

_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Eran Messeri | 17 Jun 13:02 2016
Picon

[Trans] Suggesting an alternative mechanism for name redaction

This is a proposal for an alternative mechanism to redact domain names such that would shift most of the implementation complexity from the client to the issuer, while being functionally equivalent to the redaction mechanism in the current draft.

In short: Rather than describe how the client should modify the labels in SAN extension to get to the redacted form that was logged, the issuer will generate the redacted SAN extension and log it, as a part of the TBSCertificate submitted to the log.

Details:
- The issuer, when generating a TBSCertificate for submission to the log, will add a "redacted SAN" X.509v3 extension with what the current draft specifies should be in the SAN extension (i.e. dNSNames with redacted labels, ?.example.com).
- The TBSCertificate to be submitted will *not* have a SAN extension (thanks Rob for this suggestion).
- The log will issue an SCT that covers the submitted TBSCertificate (+ issuer key hash as currently described).
- The issuer then can issue the unredacted certificate by adding a SAN extension with the unredacted names (and potentially embedding the obtained SCTs).
- The client, when receiving the unredacted certificate, simply removes the SAN extension (and the embedded SCTs extension, if present), then validates the signature from the SCT over it.
- Then client can then extract the redacted domain names from the "redacted SAN" extension, compare them to the unredacted domain names from the SAN extension and apply a policy to determine if the redaction was appropriate. 

Benefits:
- The only manipulation clients have to do to validate an SCT is to remove another X.509 extension, which it already has to do for embedded SCTs (eliminating both the error-prone process of reconstructing the redacted labels and the need to re-assemble a TBSCertificate).
- Clients have both the redacted and unredacted domain names and can still choose to apply any desired policy.

Disadvantages:
- The commonName in the subject field cannot be redacted this way.
- monitors will have to go through another hoop to make sense of the logged entry (likely by assigning the value of the "redacted SAN" extension to the SAN extension before using a standard parser to parse the TBSCertificate).

Assuming this mechanism is technically sound, I would not object to keeping redaction in 6962-bis if implemented this way.

Eran
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Andrew Ayer | 16 Jun 06:31 2016

[Trans] Redacted Labels extension with zero elements

There is an annoying edge case where a certificate with no DNS- or
CN-IDs can have a Redacted Labels extension with zero elements and not
be invalid according to 6962-bis.

This means you can't immediately reject a certificate if the Redacted
Labels extension has fewer than one element.  Combined with the
requirement that the last integer implicitly repeats, this made my
TBSCertificate reconstruction implementation more complicated than it
would be otherwise.  Considering that this code involves indexing an
array, which carries a risk of invalid memory access in memory unsafe
languages, I think it's important to make it possible to detect and
reject bad input as easily and as early as possible.

If redaction is not removed, could we specify that the Redacted
Labels extension MUST NOT be present if no labels are redacted?

Regards,
Andrew
Salz, Rich | 15 Jun 14:15 2016

Re: [Trans] Name redaction - stay or go?


> I think redaction should stay.

Same here.  Strongly in favor
Rob Stradling | 15 Jun 10:33 2016

Re: [Trans] Name redaction - stay or go?

On 15/06/16 06:53, Peter Bowen wrote:
> On Tue, Jun 14, 2016 at 9:03 PM, Melinda Shore <melinda.shore <at> gmail.com> wrote:
>> As we approach the end of working group last call on 6962-bis,
>> it looks like we have an unresolved question about whether
>> name redaction should stay or go.  I just went through the
>> mailing list archive and it looks like we have squishy
>> agreement that it should go (for example, Rob's comment:
>> "Regarding fixing it: I'd rather nuke the redaction
>> option than add further complexity.").  So, if anybody has
>> particularly strong feelings about this, or disagrees
>> about removing name redaction, please weigh in.
>
> I disagree with removing name redaction.  There is value in having
> redacted certificates and it isn't questionable that having some info
> is better than none.  For example, a CA could choose to log every
> certificate but redact some.  This would make it very clear if a
> "rogue" certificate should up that didn't match any certificate on
> record.
>
> Symantec has also shown there is customer demand for redacted
> certificates -- they swapped their default to "log full certificate" a
> couple of weeks ago and have had several hundred certificates
> explicitly opt for redaction.  From the domains, it seems that it is a
> number of different customers spanning multiple countries and types of
> organizations (commercial, government, non-profit, etc).
>
> I think redaction should stay.

Melinda, I think there are three potential ways forward...

1. (Stay) Keep the redaction mechanism in 6962-bis.

2. (Defer) Move the redaction mechanism into a separate I-D, so that 
TRANS can continue to work on defining redaction without holding up 
6962-bis from progressing to RFC.

3. (Go) Kill the redaction mechanism entirely.

Are you asking "Stay or Defer" or "Stay or Go" or "Stay or Defer or Go"?

--

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

Gmane