Re: [lamps] Review comment from the AD

That would only be true if you checked the most recent CA rather than the
one issued at the time in the message.

Jim

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Thursday, September 28, 2017 7:32 AM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: SPASM <spasm@ietf.org>
> Subject: Re: [lamps] Review comment from the AD
> 
> Jim:
> 
> The CA that issued the certificate to the TSA should revoke that
certificate if
> the TSA is compromised.  So, I think that the revocation checking on the
TSA
> certification path is enough.
> 
> Russ
> 
> 
> > On Sep 27, 2017, at 6:04 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> >
> > Yes, but if the time-stamp authority has been compromised, then it is
> > no longer a good authority.  So perhaps some extra guidance is needed
> > about doing two checks or something.
> >
> > Jim
> >
> >
> >
> >> -----Original Message-----
> >> From: Russ Housley [mailto:housley@vigilsec.com]
> >> Sent: Wednesday, September 27, 2017 11:56 AM
> >> To: Jim Schaad <ietf@augustcellars.com>
> >> Cc: SPASM <spasm@ietf.org>
> >> Subject: Re: [lamps] Review comment from the AD
> >>
> >> I think this text was supposed to say that SigningTime is the clock
> >> value
> > of the
> >> signer, which might be very wrong.  One might rely on a time-stamp
> >> authority [RFC3161], if there is a valid attribute from one in the
> > message.
> >> Otherwise, the time that the message arrived in your mailbox is the
> >> best guess that you have.
> >>
> >> Russ
> >>
> >>
> >>> On Sep 27, 2017, at 2:40 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
> >>>
> >>> I have one review comment from EKR on rfc5750bis that I am not sure
> >>> what to do with.
> >>>
> >>> The following paragraph from Section 6 - Security Considerations
> >>>
> >>> When determining the time for a certificate validity check, agents
> >>> have to be careful to use a reliable time.  Unless it is from a
> >>> trusted agent, this time MUST NOT be the SigningTime attribute found
> >>> in an S/MIME message.  For most sending agents, the SigningTime
> >>> attribute could be deliberately set to direct the receiving agent to
> >>> check a CRL that could have out-of-date revocation status for a
> >>> certificate, or cause an improper result when checking the Validity
> >>> field of a certificate.
> >>>
> >>> The problem is two-fold:
> >>> 1. Should the definition of trusted agent be expanded to be more
> >>> clear, and 2. Should that sentence just be deleted because, even if
> >>> it is a trusted agent, a compromised key is going to be able to lie
> >>> about
> > the
> >> time anyway.
> >>>
> >>> My memory was that this text was supposed to deal with things like
> >>> time-stamp agents where the time was significant, but it could be
> wrong.
> >>>
> >>> Jim
> >>>
> >>>
> >>> _______________________________________________
> >>> Spasm mailing list
> >>> Spasm@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/spasm
> >
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> > https://www.ietf.org/mailman/listinfo/spasm