W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

Re: [keyassure] dane-04 trust anchors

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 21 Feb 2011 23:01:31 +0100
Cc: keyassure@ietf.org, WebID Incubator Group WG <public-xg-webid@w3.org>
Message-Id: <BC0D8063-0AD3-4861-A50F-50C72EA7DE89@bblfish.net>
To: Scott Schmit <i.grok@comcast.net>

On 20 Feb 2011, at 06:35, Scott Schmit wrote:

> On Sun, Feb 13, 2011 at 02:58:29PM -0500, Paul Wouters wrote:
>> On Fri, 11 Feb 2011, Yaron Sheffer wrote:
>>> The client MUST obey any constraints included in the trust anchor,
>>> including but not limited to:
>>> - Validity period.
>> 
>> What to do if that period does not match the DNS TTL/RRSIG period?
> 
> The DNS TTL should be used to determine when the client MUST forget the
> certificate association and refetch the TLSA record if it needs it
> again.  I think that's the DANE equivalent to revocation (if the TLSA
> record is replaced, the old cert was revoked).

<webid parallel="cool" thread="http://www.ietf.org/mail-archive/web/keyassure/current/msg01877.html">

 1. the DNS Time To Live (TTL) is in WebID the HTTP Expires header
 2. In WebID if the public key is no longer listed at the WebID Profile then the client certificate is revoked. In Dane when the key is removed from DNSsec the same happens.
 3. In WebID there is an interesting twist: the client certificate not-before, not-after time constraints can be very useful for end users that are perhaps on less trusted machines and wish to create themselves a time limited certificate. Those people should get their Social Web server to create them a 1 hour certificate so that misuse of the certificate can only last so long.

</webid>

> 
> The RRSIG period serves a similar role to the Validity period in X.509,
> though it'll be much shorter than we're used to for PKIX. I would think
> that the most restrictive value wins. The notAfter field can always be
> set to be never to avoid needing to regenerate the certificate.
> 
> You could probably argue that what I'm saying to use the TTL for is what
> the RRSIG period is for, but in my experience with DNSSEC tools, it's a
> lot more obvious to me how I'd control (without affecting the period for
> other records) the rate a client rechecks the certificate validity via
> the TTL.
> 
> -- 
> Scott Schmit
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure

Social Web Architect
http://bblfish.net/
Received on Monday, 21 February 2011 22:02:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC