Subject: [pkix] FW: New Time-Stamp (RFC3161 update) draft available

From: "Pope, Nick" <[email-masked]>
Date: Fri, 4 Sep 2009 04:55:49 +0100

Resending post 

-----Original Message-----
From: Pope, Nick 
Sent: 28 August 2009 12:20
To: 'Peter Sylvester'; Pope, Nick
Cc: [email-masked]
Subject: RE: [pkix] New Time-Stamp (RFC3161 update) draft available

Taking a look at RFC 5035 section 1 (intro) its states:

   This document specifies the continued use of ESSCertID to ensure
   compatibility when SHA-1 is used for certificate disambiguation.

And in section 7.  Security Considerations it states:
   To ensure that legacy implementations are provided protection against
   certificate substitution, clients are permitted to include both
   ESScertID and ESScertIDv2 in the same message.  Since these
   attributes are generated and evaluated independently, the contents
   could conceivably be in conflict.  Specifically, where a signer has
   multiple certificates containing the same public key, the two
   attributes could specify different signing certificates.  The result
   of signature processing may vary depending on which certificate is
   used to validate the signature.

   Recipients that attempt to evaluate both attributes may choose to
   reject such a message.

So I suggest all that is needed is adding a note for clarification under the
section 2.6 change:

  "Note: In line with RFC 5035 for backward compatibility both ESSCerID and
ESSCerIDv2 may be present.  Systems may ignore ESSCertIDV2 if RFC 5035 where
has not been implemented."

Nick

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: 28 August 2009 11:07
> To: Pope, Nick
> Cc: [email-masked]
> Subject: Re: [pkix] New Time-Stamp (RFC3161 update) draft available
> 
> Pope, Nick wrote:
> > Ok - this may not be a generic rule.
> >
> > Am I correct in understanding that does not specify whether signed /
> > unsigned attributes may be ignored?
> >
> 'that'? Indeed, the "base" processing/parsing of attributes
> does not say anything about this. Verifying MessageDigest
> or content-type is not basic asn1 parsing but CMS signedData
> "middleware".
> 
> There is no way (like with criticality in extensions) to force
> treatment of an attribut.
> 
> > Is the suggestion then that:
> >  - ESSCertID must be present
> >
> if the TSA wants to maintain compatibility. There
> may be reasons for a TSA not to maintain compatibility,
> now, in the future. 3161upd is a technical spec.
> >  - ESSCertIDv2 may be added
> >
> It may be used alone. See above. I am only saying (according
> with my interpretation of the ESSv2 spec)
> that a TSA must be able to set both,
> >  - ESSCertIDv2 may be ignored
> >
> if not understood.
> > to remain compatible with existing RFC 3161?
> >
> to permit a TSA to remain compatible.

Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 04 Sep 2009 08:58:42 +0200

> has not been implemented."
Looks like a reasonable compromise. 
may ==> MAY ?

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 05 Sep 2009 08:44:57 +0200

This sounds reasonable to me.

/Stefan

On 09-09-04 8:58 AM, "Peter Sylvester" <[email-masked]> wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix