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

From: Peter Sylvester <[email-masked]>
Date: Thu, 27 Aug 2009 16:44:53 +0200

Pope, Nick wrote:
> Peter,
>
> Talking to our implementers any old time-stamp validation seeing the new
> ESSCertV2 would reject it anyway as it contains unrecognised syntax.  Also,
> if there are two hash values and the standard would have to say how to
> handle it if one is correct but the other isn't.  Does an implementation
> have to check both?
>   
Hi Nick,

Most implementations of things of ANY DEFINED by are build
in such a way that if they dont know the content,
it remains as a blob, and that you only attempt to parse when
an application does it for a particular attribut, or does
some default blob.
People have added all kinds of attributes AVAs in RDNs
and you can use (and even display) such DNs everywhere.

An existing implementation does not even "see" ESSCertV2
because it doesn't look for it.

Thus SMIME implementations that do not recognize an attribute,
do not fail during parsing as far as I can tell.
One (well?-)known TSA adds a security label to a signature
since years, the syntax for parsing is not generally implemented
in most parsers as far as I know. Never heard any complaints so far.

A TSA that sets one correct and another incorrect value is broken.
If a client checks both values, it will be detected, if it only checks
the bad one, it is rejected.

So, there may be still other arguments for the exclusive OR.
But forcing a TSA to choose ...

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 28 Aug 2009 12:07:27 +0200

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.