Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

[Stefan Santesson <[e-mail]>]

I'm sorry. I fail to the any of the problems you raise.

If you receive a request for a certificate that you know has never been
issued, and you choose to reply revoked, what problems can you cause?
What in your mind is a more appropriate response?

It does not make OCSP more non-deterministic. If you ask status for an
issued cert from a non-broken CA, nothing is non-deterministic.
If you ask for status for a non-issued certificate, or a bad certificate
from a broken CA, then the result is by default non-deteministic and has
always been. However, choosing a revoked response may save the relying
party, at best, but can hurt no-one

What is your problem on the practical ground.

/Stefan

From:  Piyush Jain <[e-mail]>
Date:  Friday, October 19, 2012 7:34 PM
To:  Stefan Santesson <[e-mail]>, 'Peter Rybar' <[e-mail]>,
'Carl Wallace' <[e-mail]>, 'Simon Tardell'
<[e-mail]>
Cc:  'Peter Rybar' <[e-mail]>, <[e-mail]>
Subject:  RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

> Stefan,
>  
> I think some of you interpretations below are twisted to accommodate the new
> provisions for providing revoked responses for unissued certificates.
> Providing responses for expired certificates is within the scope of 2560 using
> archive cutoff extension.
>  
> The original authors of 2560 can correct me if I¹m wrong, but it is my
> understanding that a response from OCSP responder is not supposed to indicate
> if a certificate is good or bad but to indicate if a certificate is revoked or
> unrevoked by the issuing authority. The fact that certificate is issued by the
> CA is checked by the RP by verifying the signature on the certificate.
>  
> This draft introduces the concept of returning revoked responses for unissued
> certificates. There are many unintended consequences of this approach
> -          Revocation statuses become non-deterministic based on who you are
> asking (A responder with access to CA database vs. one without vs. checking
> status off a CRL). If I¹m archiving a signed document with the relevant
> artifacts to determine the validity status of the document, this becomes a
> huge problem. Note that a revoked status implies that certificate was good
> between the time of its issuance and that of its revocation. Any document that
> is signed within that period should still be considered valid.
> 
> -          It would confuse an implementer about what ³non-issued² means. The
> fact that the CA signed the certificate implies it was issued. If a
> certificate is issued fraudulently, based on its security practices, it is up
> to the CA to either revoke the issued certificate, or ask its issuing
> authority to revoke its own certificate.
> 
>  
> -Piyush
>  
>  
>  
>  
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Stefan
> Santesson
> Sent: Friday, October 19, 2012 7:25 AM
> To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell'
> Cc: 'Peter Rybar'; [e-mail]
> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
>  
> 
> Peter,
> 
>  
> 
> An OCSP responder is by default a service providing information about current
> certificates.
> 
> The default response you get from an OCSP responder is "good" unless the cert
> is known to be bad or not a cert the responder can provide status for.
> 
>  
> 
> If you need it to respond about old certificates, and as a client know that
> the responder does this in a way that suits your needs, you will need to add
> an extension.
> 
> Such extension will not be part of the rfc256bis effort.
> 
>  
> 
> Is there any text in the current draft that you think is unclear on this?
> 
>  
> 
> /Stefan
> 
>  
> 
>  
> 
> From: Peter Rybar <[e-mail]>
> Date: Friday, October 19, 2012 3:12 PM
> To: 'Carl Wallace' <[e-mail]>, 'Simon Tardell'
> <[e-mail]>
> Cc: 'Peter Rybar' <[e-mail]>, Stefan Santesson <[e-mail]>,
> <[e-mail]>
> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
> 
>  
>> 
>>> Well, yes, sort of. You can only be sure to validate a signature at the
>>> moment of production.
>> 
>>  
>> 
>> What if the signature key was compromised at the moment of production but is
>> not yet on a revocation list?
>> [PR] According to clause 2.4  -  thisUpdate: The time at which the status
>> being indicated is known to be correct
>> It means when signature time-stamp time is X then any OCSP responses with
>> thisUpdate time X+y are sufficient to validate because the status is correct.
>> Y is in the interval <0, producedAt - X>
>> 
>>  
>>> At any later point in time the signature key may be compromised, or the
>>> algorithms involved may have become to weak. (In which case the time of
>>> revocation in the OCSP response is worth nothing to you). The risk increases
>>> as time passes. And of course, the revocation information may not be kept
>>> around after the expiry of the certificate.
>>> 
>>>  
>>> 
>>> That's why you should validate signatures as soon as possible.
>> 
>>  
>> 
>> For these archival purposes wouldn't it be better to have the final
>> revocation list before removed due to expiry?  In any case, you'd need
>> verification information collected after some grace period following moment
>> of production.
>> 
>> [PR] Grace period is not a fixed value of the time interval.
>> Grace period is changeable because the first OCSP response with thisUpdate
>> time value > than time of signature time-stamp contains correct status.
>>  
>>> 
>>>  
>>> 
>>> If you need to ascertain that a signature was valid at a later time, you
>>> have to trust your system that it performed the validation at the time it
>>> first received the signature. That trust must be established through some
>>> kind of mix of policies and technical measures (such as timestamping).
>> 
>>  
>> 
>> In the dark corner just beyond the dark corner that is SCVP, there's a spec
>> (RFC 5276) that defines a binding of evidence records to artifacts that can
>> be returned viaSCVP.  This provides for timestamping.
>> [PR] The validation is simplified when OCSP response with positive statement
>> as a hash value of requested certificate is used.
>> Positive statement is evidence that OCSP know the status of certificate and
>> also protect the integrity of certificate with a new more secure hash
>> algorithm.
>> 
>>  
>> Peter Rybar
>>  
>>> 
>>> 
>>> 
>>> Simon Tardell, 
>>> 
>>> Technology Nexus.
>>> 
>>> On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <[e-mail]> wrote:
>>> Stefan,
>>> 
>>> I have a question about the present OCSP RFC and at the end of the mail
>>> about the new situation which will happen according to your new proposal.
>>> 
>>> The presence of the positive statement in OCSP response is important for
>>> electronic signature validations, especially for an expired certificate.
>>> Positive statement is the hash value of a certificate whose status is
>>> provided in OCSP response.
>>> 
>>> Electronic signature validation is usually about the signatures created in
>>> the past and validated now, when the certificate is expired.
>>> 
>>> When the certificate expires then revocation is usually removed from CRL and
>>> the revoked certificate can be provided as "good" in OCSP response.
>>> Is it acceptable? I think not.
>>> 
>>> According to your new draft there is not defined a value of revocationTime.
>>> RFC must also define the value of revocationTime when the certificate which
>>> was never issued is as "revoked".
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06
>>> 
>>> Have you also covered the situation when the certificate is expired, REMOVED
>>> FROM CRL and will be provided as revoked with incorrect revocationTime
>>> e.g.with the value before or after the revocationTime which was present in
>>> the removed record from CRL?
>>> Because according to sentence in your draft ""revoked" - This state SHOULD
>>> also be returned if the responder knows that the requested certificate has
>>> never been issued." the following situation can happen: when certificate is
>>> removed from CRL after expiration and CA/OCSP responder is responsible for
>>> this certificate but have not record about expired certificate and for that
>>> reason it is identified as "never been issued".
>>> 
>>> ...
>>> revoked     [1]     IMPLICIT RevokedInfo,
>>> ...
>>> 
>>>    RevokedInfo ::= SEQUENCE {
>>>        revocationTime              GeneralizedTime,
>>>        revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }
>>> 
>>> As you have mentioned in the mail:
>>> 
>>> "On the "revoked" state, the old spec did not even consider the case of a
>>> certificate being requested where the OCSP responder knows that the
>>> certificate was never issued."
>>> 
>>> "It simply recommend a known to be bad certificate to result
>>> in "revoked" in order to prevent damage as far as possible. It also opens
>>> for definition of new extensions through which such knowledge could be
>>> obtained."
>>> Peter Rybar
>>> National Security Authority
>>> Information Security and Electronic Signature Department
>>> Budatinska 30, 850 07 Bratislava 57, Slovak Republic
>>> e-mail: [e-mail]
>>> e-mail: [e-mail]
>>> 
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Stefan Santesson
>>> Sent: Monday, October 15, 2012 1:49 AM
>>> To: [e-mail]
>>> Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06
>>> 
>>> All,
>>> 
>>> I have just posted an update of rfc2560bis (OCSP update) after carefully
>>> reviewing all comments on the list.
>>> 
>>> Some notes about the update:
>>> 
>>> - Added the previous OCSP editors with updated affiliations.
>>> - Added some calcifications on ResponderID as suggested by Simon Josefsson.
>>> - Updated the clarifications on Authorized responders. The requirements
>>> have not changed. I just tried to improve the text.
>>> - Updated a clarification on the "revoked" state to be the preferred
>>> response if a certificate is known by the responder to never have been
>>> issued.
>>> - Some minor editorial nits.
>>> 
>>> 
>>> Regarding backwards compatibility I mean that none of the clarifications
>>> changes RFC 2560.
>>> 
>>> On Authorized responders it has always been the case that a responder
>>> certificate issued with the same key as was used to issue the certificate
>>> being checked for revocation, represents a valid Authorized responder.
>>> There has never been an explicit requirement to support key rollover and
>>> key rollover support has never been in the "spirit" of the original
>>> standard as it clearly attempted to provide direct cryptographic binding
>>> between the responder and the CA.
>>> 
>>> On the "revoked" state, the old spec did not even consider the case of a
>>> certificate being requested where the OCSP responder knows that the
>>> certificate was never issued. It is clearly counterproductive to respond
>>> good when a certificate is known to be bad. A responder must pick one
>>> response and picking "revoked" breaks nothing, but has the desired effect,
>>> that is, to prevent the certificate from being accepted. The current text
>>> makes clear that there is no mechanism in the current standard by which a
>>> client can know how a responder will respond to a request for a not issued
>>> certificate. It simply recommend a known to be bad certificate to result
>>> in "revoked" in order to prevent damage as far as possible. It also opens
>>> for definition of new extensions through which such knowledge could be
>>> obtained.
>>> 
>>> The current updates also clearly opens a path for the CAB forum efforts to
>>> define a suitable solution for server certificates.
>>> 
>>> I have not, even thug suggested, added any requirements on what clients
>>> should do with the checked cert as a result of a particular response. I
>>> don't believe such requirements are suitable as it is policy and not
>>> protocol. We have no right to demand that all systems MUST reject any
>>> certificate for any reason as they may have a local policy that overrules
>>> the OCSP response. This protocol only provides information about the cert
>>> status, it does not mandate validation policy.
>>> 
>>> I have not included any of the substantial changes i the Pinkas draft. I
>>> want to wait for a list of motivation for each change before including any
>>> of them. So there changed may be up for debate before this draft is ready
>>> for WGLC.
>>> 
>>> /Stefan
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> pkix mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pkix
>>> 
>>> _______________________________________________
>>> pkix mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pkix
>>>  
>>> _______________________________________________ pkix mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/pkix