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

[Carl Wallace <[e-mail]>]

From:  Simon Tardell <[e-mail]>
Date:  Friday, October 19, 2012 7:56 AM
To:  Peter Rybar <[e-mail]>
Cc:  Peter Rybar <[e-mail]>, Stefan Santesson
<[e-mail]>, <[e-mail]>
Subject:  Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

> It seems to me that if you remove information about the revocation status for
> expired certificates you can't be expected to be able to answer the question
> of whether it was ever issued. Or put in reverse: If you keep track of all
> certificates ever issued, then it is reasonable to assume that you keep track
> of all revocations of the same.
> 
> Also: "Electronic signature validation is usually about the signatures created
> in the past and validated now, when the certificate is expired."
> 
> 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?

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

> 
> 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 via SCVP.  This provides for timestamping.

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