|
From: Markus K. <ma...@pr...> - 2015-08-27 14:44:29
|
On 08/27/2015 02:37 PM, Martin Rublik wrote: > On 27. 8. 2015 16:06, Markus Kilås wrote: >> Yes, I think this is the expected behaviour. The rational is that you >> would only sign the time-stamp according to the policies you have >> decided to support. If a request comes in with a policy that you have >> not listed as a policy that you support (and thus claim to fulfil), then >> the request is rejected. If the request contains a policy OID then this >> must be the policy used in the token as explained in RFC#3161: >> >> "The policy field MUST indicate the TSA's policy under which the >> response was produced. If a similar field was present in the >> TimeStampReq, then it MUST have the same value, otherwise an error >> (unacceptedPolicy) MUST be returned. " >> >> >> Let me know if you think I missed something. >> >> Cheers, >> Markus > > > Hi, > > thank you for your response, I think this is correct behaviour. > > I was just a little confused. The confusion was because if ACCEPTEDPOLICIES are > null then even requests that contain DEFAULTTSAPOLICYOID are rejected. > > Perhaps more explicit text would be fine in documentation: > > ACCEPTEDPOLICIES = A ';' separated string containing accepted policies, can be > null if it shouldn't be used. When not used, time stamp request MUST NOT include > a policy identifier. (OPTIONAL, Recommended) > > Thanks > > Martin > Thanks Martin, I updated the documentation with the following explanation: A ';' separated string containing accepted policies. Note that only policies listed in this property are allowed to be requested. If the property does not contain any policies then no policy can be requested. Requests not including any policy would use the default policy regardless of this property but requests explicitly requesting the default policy would still not be allowed unless it is listed in this property. (OPTIONAL, Recommended) Cheers, Markus PrimeKey Solutions |