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

["Piyush Jain" <[e-mail]>]

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