[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    [TLS] new TLS-OBC revision
From:       Dirk Balfanz <balfanz () google ! com>
Date:       2011-11-14 18:13:58
Message-ID: CADHfa2DKH4z62r9oWkJ3VRYR4S-x=srBEXzAKDVLDGsQ2QMzLA () mail ! gmail ! com
[Download RAW message or body]

Hi guys,

I uploaded revision 01 of the TLS-OBC draft. It's available at
http://tools.ietf.org/html/draft-balfanz-tls-obc-01.

Since the discussion here has been mostly neutral to favorable, there are
very few changes:

- a couple of editorial changes along the lines of changing a SHOULD to
MUST, fixing typos in OIDs, etc.
- some more explanation about the web origin that's embedded in the client
cert.
- fixed the reference to the Encrypted Client Certificates TLS extension
- added key length recommendations in security considerations section.

The full diff can be seen here:
http://tools.ietf.org/rfcdiff?url2=draft-balfanz-tls-obc-01

What didn't change, although it was brought up during the discussion here:

- the web origin in the client cert is still a IA5String. This is in line
with encoding of URIs in other standards, for example RFC 5280.

- I didn't talk about cookie hardening through channel binding in the
abstract, since I didn't want to conflate layers in the "normative" part of
the spec. (I left it in the security considerations section).

As always, comments are welcome! Wan-Teh will be talking about the new
revision at IETF 82 on Thursday.

Dirk.

[Attachment #3 (text/html)]

<div>Hi guys, </div><div><br></div><div>I uploaded revision 01 of the TLS-OBC draft. \
It&#39;s available at <a \
href="http://tools.ietf.org/html/draft-balfanz-tls-obc-01">http://tools.ietf.org/html/draft-balfanz-tls-obc-01</a>.</div>
 <div><br></div><div>Since the discussion here has been mostly neutral to favorable, \
there are very few changes:</div><div><br></div><div>- a couple of editorial changes \
along the lines of changing a SHOULD to MUST, fixing typos in OIDs, etc.</div> <div>- \
some more explanation about the web origin that&#39;s embedded in the client \
cert.</div><div>- fixed the reference to the Encrypted Client Certificates TLS \
extension</div><div>- added key length recommendations in security considerations \
section.</div> <div><br></div><div>The full diff can be seen here: <a \
href="http://tools.ietf.org/rfcdiff?url2=draft-balfanz-tls-obc-01">http://tools.ietf.org/rfcdiff?url2=draft-balfanz-tls-obc-01</a> \
</div><div><br></div><div>What didn&#39;t change, although it was brought up during \
the discussion here:</div>

<div><br></div><div>- the web origin in the client cert is still a IA5String. This is \
in line with encoding of URIs in other standards, for example RFC \
5280.</div><div><br></div><div>- I didn&#39;t talk about cookie hardening through \
channel binding in the abstract, since I didn&#39;t want to conflate layers in the \
&quot;normative&quot; part of the spec. (I left it in the security considerations \
section).</div>

<div><br></div><div>As always, comments are welcome! Wan-Teh will be talking about \
the new revision at IETF 82 on \
Thursday.</div><div><br></div><div>Dirk.</div><div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread]