Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15

Peter,

The ocsp responder can only act on the information it has.  If the 
responder knows that the certificate was issued, then it wouldn't send a 
response indicating the status it knows about (good/revoked/unknown); if 
it's revoked it won't include the special revovationTime.  If the 
responder doesn't know the certificate was issued before time X, then 
the response will include the revoked with the special revocationTime. 
If the client goes back later and asks again, the responder now can 
respond indicating the status it knows about (good/revoked/unknown); if 
it's revoked it won't include the special revocationTime.

I don't see any requirement in RFC 2560 or 2560bis for clients to order 
requests according to thisUpdate.

spt

On 4/3/13 4:35 AM, Peter Rybar wrote:
> Yes, "revoked" response for certificate serial number that is not associated with issued certificate can confuse validations systems.
>
> When is used the "revoked" response for certificate serial number that is not associated with issued certificate and the OCSP thisUpdate value is actual time X and real certificate was issued in some short time before X then it will be a real confusion for clients ordering responses according to OCSP thisUpdate value when OCSP database will be later updated with a real issued certificate with the same serial number.
>
> To avoid it the value of thisUpdate of not issued cert must be older then thisUpdate of real certificate with the same serial number.
>
> Peter
>
> -----Original Message-----
> From: Martin Rex [mailto:mrex@sap.com]
> Sent: Wednesday, April 03, 2013 10:11 AM
> To: Peter Rybar
> Cc: 'Andris Berzins'; 'Piyush Jain'; 'Stefan Santesson'; sts@aaa-sec.com; pkix@ietf.org
> Subject: Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15
>
> Peter Rybar wrote:
>>
>> When is used the "revoked" response for certificate serial number that
>> is not associated with issued certificate then the OCSP nextUpdate
>> field is not used and OCSP thisUpdate field is better to be set to some
>> strange value or to proposed value of issuer CA cert notBefore.
>
> I strongly disagree and consider this a bad idea.
>
> There is already a special value assigned to the revocationDate.
> Messing around with thisUpdate/nextUpdate is not going to provide
> any additonal value, but will cause confusion, be incompatible with
> the rfc2560-defined semantics of thisUpdate/nextUpdate and may even
> cause problems -- depending on the ordering of the checks performed
> while processing an OCSP response.
>
> -Martin
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>