Re: TSA draft V7

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Michael,

On the gfirst point I answered to quickly.

The idea is to return the relevant certificate in the certificates
field from the SignedData structure.

Here after is the complete fix:

If the certReq field is present and set to true, the TSA's public
key certificate that is referenced by the ESSCertID attribute in the 
response must be provided by the TSA in the certificates field from 
the SignedData structure in that response. That field may also
contain 
other certificates.

If the certReq field is missing, or if the certReq field is present
and set to false then the certificates field from the SignedData 
structure must not be present in the response.

Denis

 
> > 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