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

[Stefan Santesson <[e-mail]>]

Peter,

You have a point there. I missed that, good catch.

/Stefan

From:  Peter Rybar <[e-mail]>
Date:  Monday, October 22, 2012 2:38 PM
To:  Stefan Santesson <[e-mail]>
Cc:  Peter Rybar <[e-mail]>, Carl Wallace <[e-mail]>,
Simon Tardell <[e-mail]>, <[e-mail]>
Subject:  Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

> Stefan,
> 
> You have defined in draft that certificate identified with correct (hash of
> issuer name, hash of  issuer key) and with unknown cert serial number xyz is
> revoked. 
> Correct response must also contains the value of item revocationTime.
> 
> Do you know the correct value of  revocationTime in situation which you have
> described?
> ...
> revoked     [1]     IMPLICIT RevokedInfo,
> ...
> 
>    RevokedInfo ::= SEQUENCE {
>        revocationTime             GeneralizedTime,
>        revocationReason    [0]    EXPLICIT CRLReason OPTIONAL }
> Peter
> 
> 2012/10/19 Stefan Santesson <[e-mail]>
>> 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
>