Re: TSA draft V7

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

> A few more remarks:
 
> The draft says:

> "If the certReq field is present and set to true, the TSA's public key
> certificate that is referenced by the ESSCertID attribute must be provided
> by the TSA in the Certificate Values attribute and incorporated in the
> response. The certificate Values attribute may also contain other
> certificates.
> If the certReq field is missing, or if the certReq field is present and set
> to false then no Certificate Values attribute shall be present."
 
> Q1. "Certificate Values attribute". What is it? Was it meant to be the
> signedData::Certificates field?

You are right. It is "Signing Certificate" instead of "Certificate
Values". Good catch.

> Q2. If the certReq field is missing in the request, should it be up to the
> TSA to decide whether to include the cert of not?

The text is pretty explicit on this. The TSA does not decide : No
certificate sahll be present.
 
> Q3. somehow it seems more reasonable to default the certReq to TRUE. This
> way TSA would be well-behaving with no extra efforts.

The answer should be as short as possible in the general case. If
you really want the certificate back, then you have to ask for it.

> General comments:
> 
> C1. The draft uses both id-ad-timeStamping and id-pkix-ad-timestamping OIDs.
> I'd prefer "pkix" to be preserved as part of the name.

They come from two different arcs (SMIME and PKIX).

> C2. PKIXTSP is defined but never referenced.

The name is there so that *other* ASN 1 modules may reference it and
use what is exported.

Denis

> 
> Regards
> 
> M