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

[Simon Tardell <[e-mail]>]

On Mon, Oct 22, 2012 at 5:57 PM, Stefan Santesson <[e-mail]>wrote:

I could live with a wording saying that a responder MAY respond "unknown"
> to a request for a known fraudulent (or not never issued) cert if the
> responder possess such knowledge of course..
>

I think it is unfortunate to reopen this discussion now.

I suggest that we use your current text plus that, if "revoked" is used to
say "never issued/not in database", the revocationReason should be
certificateHold and that revocationTime should be set to midnight Jan 1
1950 (or some other time before the rise of PKI).

On the other hand, I think we should consider Denis' comment:

*Saying that the certificate has not been issued is not fully appropriate.*
> The text should be modified in the following way:
>    "The "revoked" state indicates that the certificate has been revoked
>    (either permanently or temporarily (on hold)).  This state SHOULD
>    also be returned if the responder *has an access to the database
>    of
> **   of ** issued certificates and if the serial number of the target
> **   certificate is not present in that database. *
>   * In this case, the "revoked" state indicates either that the
> **   certificate has never been issued or that it has been issued but
> **   subsequently removed (by an attack or by accident) from the
> **   database **of issued certificates.*
>    Response extensions may be used  to convey additional information
>    on assertions made by the OCSP  responder regarding the state of the
>    certificate such as *an **indication that the OCSP responder has
>    a direct access to the
> **   a direct access to the **database of issued certificates*, validity,
> etc ... "


It should be difficult for the responder to tell the difference by itself,
but I think, given the kind of hair-splitters we are, it is best to be as
clear as possible. ;)

/Simon

Note that this does not have to mean that the CA is broken, is may also be
> due to an error in the request from the client.
>
> /Stefan
>
>
> From: Piyush Jain <[e-mail]>
> Date: Monday, October 22, 2012 5:32 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
>
> I’m sorry but definition of not issued is still unclear to me if you say
> that that a certificate can be cryptographically bound to the CA and still
> not-issued.****
>
> The ambiguity is introduced because now I can do everything that 5280 asks
> me to validate a certificate and still cannot be sure if the certificate
> was ever issued.****
>
> ** **
>
> Here are the scenarios where meaning of not issued is unclear to me.****
>
> 1)      A genuine certificate issued by the CA, present in the CA database
> ****
>
> 2)      A genuine certificate issued by the CA, removed from the CA
> database by the CA****
>
> 3)      A genuine certificate issued by the CA, removed from the CA
> database by an attacker****
>
> 4)      A fraudulent certificate issued by an attacker, present in the CA
> database****
>
> 5)      A fraudulent certificate issued by an attacker, removed from the
> CA database****
>
> 6)      A fraudulent certificate containing an AIA pointing to a
> fraudulent OCSP responder (also cryptographically bound to the CA), issued
> by an attacker, removed from the CA database.****
>
> ** **
>
> If the CA can differentiate among these cases, it can mark the fraudulent
> certificates as revoked and we won’t need an overloaded definition of
> not-issued. Also not that if an attacker can carry out ‘4’ it can also
> carry out ‘5’ and ‘6’****
>
> ** **
>
> The people who are convinced that this is the way to go have not addressed
> the issues raised in this WG. The little extension does not hurt anyone but
> it does not provide any value in general except to a few implementations
> which are compromised. But it does take you down a slippery slope when you
> start promising that an OCSP responder can do much more than it is supposed
> to.****
>
> I don’t think that it is unreasonable for a smart implementer to stop
> signature checking if his responder claims that it checks issuance. ****
>
> ** **
>
> As for the diginotor case, for some people who say that security breach
> could’ve been detected early if this practice was in place, there is
> another set of people who believe that attacker could’ve circumvented these
> measures quite easily with the kind of access he had.****
>
> ** **
>
> If you and other folks in the group feel that this text should be added, I
> think at the minimum we also need to do the following****
>
> -          Provide explicit guidance on what the revocation time should
> be. Such certificates are different from ‘normal’ revoked certificate and
> their revocation time should probably be set to something before the
> validity of issuing CA. This distinction is important for time based
> validations and long term archiving applications****
>
> -          I think it will be useful to indicate in the security
> considerations section, that in such a scenario, CA is compromised and that
> there is a high chance that RP is interacting with a compromised responder.
> ****
>
> ** **
>
> ** **
>
> *From:* Stefan Santesson [mailto:[e-mail] <[e-mail]>]
> *Sent:* Sunday, October 21, 2012 11:03 AM
> *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
> *Cc:* 'Peter Rybar'; [e-mail]
> *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
> ** **
>
> In line;****
>
> ** **
>
> *From: *Piyush Jain <[e-mail]>
> *Date: *Sunday, October 21, 2012 7:42 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****
>
> ** **
>
> So what is “not-issued” - not signed by the CA or not present in CA
> database?****
>
> ** **
>
> Not issued means it has never been issued. What's unclear about that?****
>
> ** **
>
> Of course it is not present in the database if it is not issued.****
>
> If you delete things from your database and don't know if this one has
> been deleted, then you don't know that it has never been issued and can't
> reply revoked.****
>
> ** **
>
> ** **
>
> It is unclear to folks who have been using signature verification as a way
> to check issuance. Isn’t it a fair conclusion that I do not need to perform
> signature checks if the responder can check issuance for me?****
>
> ** **
>
> No that is not a fair conclusion. These are entirely different things.****
>
> ** **
>
>  ****
>
> You said that the possibility to send revoked reply only applies when the
> responder ’knows’ that requested certificate has never been issued. ****
>
> Please note that the responder will encounter this kind of request only in
> two situations. First in which the RP sends a request for a certificate
> without checking the signature and second in which the responder itself is
> compromised by virtue of its issuing authority being compromised. In either
> case what the responder responds with does not matter.****
>
>  ****
>
> ** **
>
> Some people are pretty convinced it does (from CAB forum), they are so
> convinced that they are prepared to break compatibility with OCSP. By this
> little extension that hurst no-one, they don't have to.****
>
> ** **
>
> I’ve no problem with your proposal to respond with ‘revoked’ in this
> situation.****
>
> ** **
>
> Good.****
>
> ** **
>
> I’ve fundamental problem with the introduction of ‘non-issued’ concept in
> OCSP, which seems to provide additional security in this exceptional
> scenario without actually providing any.****
>
> ** **
>
> It provides some, but not much. People keep coming back to that fact that
> if this had been the practice of Diginotar, the security breach would have
> been discovered a lot earlier. So there might be some gain with no pain.**
> **
>
> ** **
>
> However, in combination with an extension that adds information, this
> might actually be increasingly valuable.****
>
> If an OCSP responder starts receiving status requests for certs it knows
> it has not issued, it can actually give explicit information about this
> using an extension and it can take adequate measures.****
>
> But in order to respond to the user, it need to pick one of the responses.
> Either good + extension or revoked+extension.****
>
> ** **
>
> This proposal is not meant to require any OCSP responder to deal with the
> concept of "non-issued" certs. It merely allows an OCSP responder to
> respond to such request.****
>
> ** **
>
>  ****
>
> It’ll be very helpful if I can see at least one practical scenario where
> this additional text would add value.****
>
> ** **
>
> Stated in my previous comments.****
>
> ** **
>
> /Stefan****
>
> ** **
>
>  ****
>
> -Piyush****
>
> *From:* Stefan Santesson [mailto:[e-mail] <[e-mail]>]
> *Sent:* Sunday, October 21, 2012 8:52 AM
> *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
> *Cc:* 'Peter Rybar'; [e-mail]
> *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
>  ****
>
> I don't think the "not issued" is unclear.****
>
>  ****
>
> The possibility to send a revoked reply only applies then the responder
> "knows" that the requested certificate has never been issued.****
>
> How the responder knows this is totally irrelevant, but unless the
> responder knows this, it can't choose this option and has to reply "good".
> ****
>
>  ****
>
> It does not make revocation checking non-deterministric. ****
>
> "good" still means what is declared in the standard (The cert is not known
> to be revoked, but it may never have been issued).****
>
> "revoked" still have a deterministic meaning, that is, don't trust this
> cert. The old exact semantics was "the cert IS revoked". The new semantic
> is "the cert is revoked or possibly might never been issued"****
>
>  ****
>
> The new response semantic of revoked is backwards compatible and not less
> deterministic than the good, response.****
>
>  ****
>
> So, I still don't see any practical problems here.****
>
>  ****
>
> /Stefan****
>
>  ****
>
>  ****
>
> *From: *Piyush Jain <[e-mail]>
> *Date: *Saturday, October 20, 2012 5:48 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****
>
>  ****
>
> Please see inline****
>
>  ****
>
> *From:* Stefan Santesson [mailto:[e-mail] <[e-mail]>]
> *Sent:* Friday, October 19, 2012 7:23 PM
> *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
> *Cc:* 'Peter Rybar'; [e-mail]
> *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06****
>
>  ****
>
> 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?****
>
> *[Piyush] It depends on how you define “never been issued”, which btw
> becomes unclear after introduction of the new text. There are two
> interpretations*****
>
> 1)      *Certificate is not signed by the CA or*****
>
> 2)      *Certificate is not present in the database of issued
> certificates that CA maintains.*****
>
> *One unintended consequence of first interpretation will be that RPs
> would stop performing signature checks if their responder/CA publicizes
> that it returns revoked for “non-issued” certificates.*****
>
> *If the interpretation is 2, then this scenario is not possible unless
> the CA is compromised.*****
>
>  ****
>
> What in your mind is a more appropriate response?****
>
> *[Piyush] I would say the appropriate response is good (if the
> certificate is not marked as revoked), because that is what the RP will see
> if it consults a CRL or a responder detached from the CA. *****
>
> *Revoked for “not issued” adds no value because the only case in which an
> RP would send a query for a “non-issued” certificate is when the CA is
> compromised.*****
>
>  ****
>
> 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.****
>
> *[Piyush] It does not make OCSP non-deterministic but it makes revocation
> checking non-deterministic. The goal of OCSP is to address operational
> limitations of CRLs, not functional limitations.  The fact that you’ll get
> different answers from two sources, both of which are authorized by the
> same CA makes revocation checking 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****
>
> *[Piyush] I agree that a revoke response does not hurt anyone. But the
> point is that it provides a false sense of additional security to the RP
> without providing any. As an RP, I won’t trust what my responder says if
> the authority that certified it is compromised.*****
>
>  ****
>
> What is your problem on the practical ground.****
>
> *[Piyush] * Let’s say that we still need to address this scenario and
> revoked is the appropriate response. In that case****
>
> -          The text needs to be explicit about the revocation time in
> this situation. Revoked implies good until a certain date and this
> distinction is important for long term archiving applications. For unissued
> certificate the revocation time should probably be set to –infinity.****
>
> -          It needs to call out that in this particular scenario it is
> addressing a functional limitation of CRLs (ability to detect CA
> compromise) not an operational limitation.****
>
> -          I think we need additional text in security considerations to
> indicate that RP is communicating with a responder certified by a
> compromised CA in this scenario.****
>
>  ****
>
>  ****
>
> /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]<[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****
>
>