Re: [dane] draft-ietf-dane-smime

["Osterweil, Eric" <[e-mail]>]

On Oct 17, 2014, at 11:04 AM, Viktor Dukhovni <[e-mail]> wrote:

> On Thu, Oct 16, 2014 at 05:17:49PM +0200, Jakob Schlyter wrote:
> 
>>> If  X@Y sends S/MIME signed message to  DANE WG on January 20th 2016. 
>>> X@Y leaves Y on Feb 15th 2016. 
>>> 
>>> Is there any value in being able to validate the signature when a document
>>> editor gets around to read the message March 15 2016 while updating the
>>> document referenced in the email to meet the ID deadline for IETF-95  ?
>> 
>> You basically want to know if certificate C was valid at time T. A CRL
>> might tell you when a certificate was revoked, whereas OCSP does not.
>> Neither of the proposals discussed in this group so far would help you
>> with that either.
> 
> Perhaps some of you have seen the recent comments by Jerry Leichter
> on Perry's cryptography list in the thread about HP revoking their
> software signing certificate.  The problem with revocation of
> signing certificates for "data at rest" is rather deep.  We simply
> don't have correct semantics for this at present.
> 
> Revocation that invalidates messages older than the revocation
> event is rather sub-optimal.
> 
> With email, the MUA and/or mailstore should validate messages when
> they first arrive, and record the validity of the signature at that
> point.  With validity frozen at time of arrival, it is largely
> sufficient to remove the ability of obsolete keys to sign new mail
> and delist them as valid keys for receiving new encrypted mail.
> 
>> Paul and I advocate that SMIMEA will only tell you if a given certificate
>> is valid in real time (or in the proximity of). Others say an explicit
>> revoked flag would be useful.
> 
> I concur, subsequent revocation of already received and at the time
> accepted as valid mail is too little too late.  It has in most
> cases already been acted on (for better or for worse) at time of
> arrival.

For what it’s worth, I think the proposed text was exactly inline with what you both are suggesting.  The suggestion was a way to help enterprises express their needs (under some circumstances) a little more cleanly in DNS.  For example, a single DANE TA could be used to authorized all of an organization’s S/MIME users, and selective ``user-no-longer-valid'' (i.e. revocation) entries could override this.  This could definitely allow for the fact that the S/MIME cert of a ``user-no-longer-valid'' employee was once valid, but not at the time of querying DNS.  As you both point out (I believe), this is different than other notions of revocation.

I think we are all on the same page, and perhaps the text was not clear enough?  Maybe it's also possible there was some misunderstanding from the protracted email discussion?  The revocation discussion (IIRC) really had to do with an assertion that TLS did not have revocation needs.

Eric