Johannes Merkle wrote:
Limitations
- Works only if attacker fraudulently issued a certificate with a serial
that is not associated with a good certificate.
This can be remedied by using an extension in which a server providing
white-list information conveys a hash of the
On Apr 13, 2013, at 4:24 PM, Stefan Santesson ste...@aaa-sec.com wrote:
These are the three possible states of a serial number. It must always
be in ONE of these states.
As long as you assume that a certificate signed by the CA cannot be
non-issued i.e. CA knows what certificates it issued.
Limitations
- Works only if attacker fraudulently issued a certificate with a serial
that is not associated with a good certificate.
This can be remedied by using an extension in which a server providing
white-list information conveys a hash of the
(genuine) certificate having this
On Apr 11, 2013, at 10:37 PM, Stefan Santesson ste...@aaa-sec.com wrote:
To put it simply. Given how OCSP is designed, the only way to allow good
to represent a white-list, is if revoked can be returned for everything
else.
I realize it's unfair of me to take this quote out of context.
An extension may differentiate which serial number that results in a
revoked response, that is actually issued and revoked, or if there is
any
other particular reason for responding revoked.
In my universe a syntactically valid serial number can only be good,
revoked
or non-issued. But
[Piyush] From an RP's perspective finding status of serial numbers
serves no purpose unless they can associate that serial number with a
certificate.
Absolutely, that is the client's perspective of this.
Great. We agree
When an OCSP client extracts the serial number from a certificate
, April 13, 2013 4:24 PM
To: Piyush Jain; 'Henry B. Hotz'
Cc: p...@ietf.org; ietf@ietf.org
Subject: Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509
Internet Public Key Infrastructure Online Certificate Status Protocol -
OCSP)
to Proposed Standard
On 4/13/13 8:56 PM, Piyush Jain
On 4/13/13 2:53 AM, Henry B. Hotz h...@jpl.nasa.gov wrote:
You've just said that there are only two valid responses from an OCSP
server which has access to a white list. In other words such a server
inherently cannot provide any information about the actual revocation
status of a cert, and its
On 4/13/13 6:51 PM, Piyush Jain piy...@ditenity.com wrote:
An extension may differentiate which serial number that results in a
revoked response, that is actually issued and revoked, or if there is
any
other particular reason for responding revoked.
In my universe a syntactically valid
On 4/13/13 8:56 PM, Piyush Jain piy...@ditenity.com wrote:
[Piyush] From an RP's perspective finding status of serial numbers
serves no purpose unless they can associate that serial number with a
certificate.
Absolutely, that is the client's perspective of this.
Great. We agree
When
On Apr 10, 2013, at 3:02 AM, Stefan Santesson ste...@aaa-sec.com wrote:
Nothing has changed in this regard.
The good response is pretty clear that it by default provides information
that the cert is not on a black-list (is not know to be revoked).
However, it is also made clear that
Henry B. Hotz wrote:
Stefan Santesson ste...@aaa-sec.com wrote:
Nothing has changed in this regard.
The good response is pretty clear that it by default provides information
that the cert is not on a black-list (is not know to be revoked).
However, it is also made clear that
On 4/12/13 1:31 AM, Henry B. Hotz h...@jpl.nasa.gov wrote:
What I would find helpful, and what I think some people really would
like, is for OCSP to be able to provide white-list information in
addition to the previous black-list information. When I read through
2560bis, I could not tell if
Nothing has changed in this regard.
The good response is pretty clear that it by default provides information
that the cert is not on a black-list (is not know to be revoked).
However, it is also made clear that extensions may be used to expand this
default information about the status.
This is
Actually, what I get from this and all the other discussions is that it's
unclear if the updated OCSP satisfies the suitability for the intended
purpose test. Or at least it fails the KISS principle w.r.t. that.
Rephrasing: an OCSP client should be able to tell from an OCSP response if:
a)
+1.
-Original Message-
From: pkix-boun...@ietf.org [mailto:pkix-boun...@ietf.org] On Behalf Of
Henry B. Hotz
Sent: Monday, April 08, 2013 1:35 PM
To: Sean Turner
Cc: p...@ietf.org; ietf@ietf.org
Subject: Re: [pkix] Last Call: draft-ietf-pkix-rfc2560bis-15.txt (X.509
Internet
On 3/27/13 5:35 PM, Denis wrote:
First of all, this is an announcement: I am retiring from Bull at the
end of this week, this why I am now using a new email address.
Hopefully, you'll still find time in your retirement to keep on PKIXing!
The second announcement is that I am taking one full
Martin,
I went all the way to Sam's original message about his discuss on the
draft that became RFC 5019:
https://www.ietf.org/mail-archive/web/pkix/current/msg03627.html
and reviewed the 60 or so messages in the thread.
Aside: I think when you're referring to updating RFC 5019 you're
On 3/27/13 10:11 PM, Martin Rex m...@sap.com wrote:
It was the Security co-AD Russ Housley who indicated _early_ during
the discussion of that draft (2.5 years after it had been adopted
as a WG item) that he considered some of the suggested abuses of
existing error codes unacceptable
For the
Stefan Santesson wrote:
Martin Rex m...@sap.com wrote:
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible.
It is risky to assume that existing clients would work appropriately if
you send them a new never seen before error code.
I'm not willing to assume that unless a big pile of current implementers
assures me that this is the case.
/Stefan
On 3/27/13 3:14 PM, Martin Rex m...@sap.com wrote:
Stefan
Stefan Santesson wrote:
It is risky to assume that existing clients would work appropriately
if you send them a new never seen before error code.
I'm not willing to assume that unless a big pile of current implementers
assures me that this is the case.
As I wrote: As long as the spec is
Sam Hartman wrote:
Martin Rex wrote:
Oh, here is a message from the Security AD back then (Sam
Hartman), commenting on requirements for rfc2560bis (the I-D
under last call right now!):
http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html
To be clear, I didn't comment on
Unfortunately what you suggest would not be backwards compatible, and
can't be done within the present effort.
Responders using 5019 need to work in foreseeable time with legacy clients
that knows nothing about the update you suggest.
This group and the IETF made a decision when publishing 5019,
Stefan Santesson wrote:
Unfortunately what you suggest would not be backwards compatible,
and can't be done within the present effort.
I'm sorry, I can not follow your arguments.
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8),
On 3/26/13 12:13 PM, Martin Rex m...@sap.com wrote:
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible.
Of course
Following up to myself:
The real discussion seemed to have started in 2006...
Some folks had a pretty reasonable opinion at some point of the discussion,
e.g. Russ Houseley:
http://www.ietf.org/mail-archive/web/pkix/current/msg03570.html
and then there is lots of real dirty horse-trading in
Stefan Santesson wrote:
On 3/26/13 12:13 PM, Martin Rex m...@sap.com wrote:
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly
What OCSP client are you using that behaves like this?
On 3/26/13 1:09 PM, Martin Rex m...@sap.com wrote:
I would no longer get a popup from my OCSP client that tells my
that I'm unauthorized to submit OCSPRequests to that server, and that
the server has been moved to a blacklist
Stefan Santesson wrote:
What OCSP client are you using that behaves like this?
On 3/26/13 1:09 PM, Martin Rex m...@sap.com wrote:
I would no longer get a popup from my OCSP client that tells my
that I'm unauthorized to submit OCSPRequests to that server, and that
the server has been moved
I take it that the answer to my question is none.
Which is what I suspected. The semantics of unauthorized does not give
you the basis for such functionality.
And 5019 is very widely deployed.
I'm going to sep down from this discussion and see how it goes.
It is not me you have to convince. It's
Stefan Santesson wrote:
I take it that the answer to my question is none.
Why would an rfc5019 client have a problem with a (7) instead of (6)
OCSPResponseStatus?
And what about an error code for only a single request that rfc5019
fails to specify.
Which is what I suspected. The semantics
Martin == Martin Rex m...@sap.com writes:
Martin Oh, here is a message from the Security AD back then (Sam
Martin Hartman), commenting on requirements for rfc2560bis (the I-D
Martin under last call right now!):
Martin
Sam Hartman wrote:
Martin Rex m...@sap.com writes:
Martin http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html
To be clear, I didn't comment on which error codes were overloaded to do
what. My point was simply that there needs to be a minimal set of
client behavior that is
Martin,
Whether we like it or not. This is the legacy.
There is no way for a client to know whether the OCSP responder implements
RFC 2560 only or in combination with RFC 5019.
So therefore, the update that was introduced in 5019 must be expected by
all clients from all responders. Therefore it
Stefan Santesson wrote:
Whether we like it or not. This is the legacy.
There is no way for a client to know whether the OCSP responder implements
RFC 2560 only or in combination with RFC 5019.
So therefore, the update that was introduced in 5019 must be expected by
all clients from all
The IESG wrote:
The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol - OCSP'
draft-ietf-pkix-rfc2560bis-15.txt as Proposed Standard
The
37 matches
Mail list logo
