Subject: [pkix] Previous attempt to update OCSP

From: "David A. Cooper" <[email-masked]>
Date: Mon, 02 Aug 2010 17:52:09 -0400

All,

During my search of the PKIX mail list archives last week I came across
a previous attempt to update RFC 2560
(http://www.ietf.org/mail-archive/web/pkix/current/msg14541.html).  I
don't think this was ever posted as an Internet-Draft (at least I could
find no evidence of it), but there are likely changes in that draft
that should be incorporated into the current update.

So, here is a list of the changes, along with my initial thoughts on
them.  Please provide your thoughts on these changes, particularly
those that for which information about current implementations is
required.

Thanks,

Dave

-----------------------------------------------------------------------

1) Rewording of the "good" and "unknown" certificate status response
values:

OLD:

The "good" state indicates a positive
response to the status inquiry.
At a minimum, this positive response indicates that the certificate is
not revoked, but does not necessarily mean that the certificate was
ever issued or that the time at which the response was produced is
within the certificate's validity interval.  Response extensions may be
used to convey additional information on assertions made by the
responder regarding the status of the certificate such as positive
statement about issuance, validity, etc.

The "unknown" state indicates that the responder doesn't know about the
certificate being requested.

NEW:

The "good" state indicates that the
certificate has not been revoked.
It does not indicate that the certificate was ever issued or is in
its validity interval.

The "unknown" state indicates that the responder does not know, or is
unwilling to tell, the requestor the status of the certificate.  A
client may be able to get a definitive response later, or at another
responder.

Response extensions may be used to convey additional information on
assertions made by the responder regarding the status of the
certificate such as positive statement about issuance, expiry, etc.

DC's opinion: I think the revised text for "good"
is an improvement.  I would be concerned about adding "or is
unwilling to tell" to "unknown".  Why wouldn't the server return an
"unauthorized" error code in this case?

2) Meaning of nextUpdate:

OLD:

If nextUpdate is not set, the responder is
indicating that newer revocation information is available all the time.

NEW:

If nextUpdate is not set, the responder is
indicating that it is does
not know when newer revocation information will be available (examples
of why a responder might not know when new revocation information is
likely to be available are that the CA hasn't told it, or because newer
information is available all the time).

DC's opinion: Suggest no change unless someone
argues for a need for this change.

3) Transports for OCSP:

NEW:

While OCSP can be used over many transports,
for interoperability, all
OCSP clients and responders MUST support the use of HTTP [HTTP] as the
transport.

DC's opinion: Would be a change to the standard,
and thus would fall outside of the scope of this update.  However, this
may be an acceptable change if all existing implementations already
support the requirement.

4) Allowance for partial responses:

Current text:

Prior to accepting a signed response as
valid, OCSP clients SHALL confirm that:

1. The certificate identified in a received response corresponds to
that which was identified in the corresponding request;

NEW:

NOTE: The first criteria does not imply that
a client should reject an
OCSP response from a server that contains statuses of a superset or
subset of the certificates whose statuses were requested i.e. it is all
right for a server to, in an OCSP response provide the statuses of only
some of the certificates requested, and some other certificates whose
statues were not requested. For example, if a client requests the
status of certificates with serial numbers 1 and 2 and gets a response
which has the statuses of certificates with serial numbers 1 and 3, the
client can accept that response for the status of the certificate with
serial number 1, assuming the rest of the response acceptance criteria
were met.

DC's opinion: The update already allows the
response to include a superset of the certificates whose statuses were
requested, based on RFC 5019.  Servers that provide fresh responses to
requests should never return responses that only include a subset of
the certificates whose statuses were requested, since they can respond
"unknown" for the certificates whose statuses they don't know.  If a
server that provides pre-generated responses receives a request that
asks for information about multiple certificates should it return a
pre-generated response for one of the certificates or return an
"unauthorized" response?

5) Minor ASN.1 change to avoid encoding ambiguity:

OLD:

certs               [0] EXPLICIT SEQUENCE OF
Certificate OPTIONAL

NEW:

certs               [0] EXPLICIT Certificates
OPTIONAL

Certificates    ::=     SEQUENCE SIZE(1..MAX) of Certificate

DC's opinion: This would be a change in the
protocol and would be inconsistent with the ASN.1 in RFC 5912.
However, a sentence could be added stating that if no certificates are
included then the certs field SHOULD be absent rather than being
present and containing an empty SEQUENCE.

6) Computing hash of public key:

OLD:

issuerKeyHash is the hash of the Issuer's
public key. The hash shall be
calculated over the value (excluding tag and length) of the subject
public key field in the issuer's certificate.

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)

NEW:

issuerKeyHash is the hash of the Issuer's
public key. The hash shall be
calculated over the value of the BIT STRING subjectPublicKey field
(excluding the tag, length and number of unused bits) in the issuer's
certificate.

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key

-- (i.e. the SHA-1 hash of the value of the BIT STRING subjectPublicKey

-- [excluding the tag, length and number of unused bits] of the

-- responder's certificate).

DC's opinion:  This appears to be a change, but
it should be made if this is how current implementations actually
compute the hash of a public key.

7) OCSP requests over HTTP:

OLD:

HTTP based OCSP requests can use either the GET
or the POST method to
submit their requests.  To enable HTTP caching, small requests (that
after encoding are less than 255 bytes), MAY be submitted using GET.
If HTTP caching is not important, or the request is greater than 255
bytes, the request SHOULD be submitted using POST.  Where privacy is a
requirement, OCSP transactions exchanged using HTTP MAY be protected
using either TLS/SSL or some other lower layer protocol.

An OCSP request using the GET method is constructed as follows:

GET {url}/{url-encoding of base-64 encoding of the DER encoding of the
OCSPRequest}

where {url} may be derived from the value of AuthorityInfoAccess or
other local configuration of the OCSP client.

An OCSP request using the POST method is constructed as follows: The
Content-Type header has the value "application/ocsp-request" while the
body of the message is the binary value of the DER encoding of the
OCSPRequest.

NEW:

HTTP based OCSP requests MUST use the POST
method to submit their
requests.  Where privacy is a requirement, OCSP transactions exchanged
using HTTP MAY be protected using either TLS/SSL or some other lower
layer protocol.

An OCSP request using the POST method is constructed as follows: The
Content-Type header has the value "application/ocsp-request" while the
body of the message is the binary value of the DER encoding of the
OCSPRequest.

DC's opinion:  This change should not be made.
It is inconsistent with RFC 5019, which requires the use of the GET
method for requests that are less than 255 bytes.

---

From: Kyle Hamilton <[email-masked]>
Date: Mon, 02 Aug 2010 17:18:14 -0700

On 8/2/10 2:52 PM, David A. Cooper wrote:
> So, here is a list of the changes, along with my initial thoughts on them. 
> Please provide your thoughts on these changes, particularly those that for which 
> information about current implementations is required.
>
> Thanks,
>
> Dave
Thank you, very much, for scanning the archives.
> 1) Rewording of the "good" and "unknown" certificate status response values:
>
>     OLD:
> >     The "good" state indicates a positive response to the status inquiry. At a
> >     minimum, this positive response indicates that the certificate is not
> >     revoked, but does not necessarily mean that the certificate was ever
> >     issued or that the time at which the response was produced is within the
> >     certificate's validity interval. Response extensions may be used to convey
> >     additional information on assertions made by the responder regarding the
> >     status of the certificate such as positive statement about issuance,
> >     validity, etc.
> >
> >     The "good" state indicates that the certificate has not been revoked. It
> >     does not indicate that the certificate was ever issued or is in its
> >     validity interval.
> >
> >     unwilling to tell, the requestor the status of the certificate. A client
> >     may be able to get a definitive response later, or at another responder.
> >
> >     assertions made by the responder regarding the status of the certificate
> >     such as positive statement about issuance, expiry, etc.
>
> DC's opinion: I think the revised text for "good" is an improvement. I would be 
> concerned about adding "or is unwilling to tell" to "unknown". Why wouldn't the 
> server return an "unauthorized" error code in this case?
KH: Seriously, I'm considering the status of "good" and wondering why a
large part of that doesn't get moved to "unknown".  (RFC 5019 makes
changes to OCSP behavior for scalability -- why can't this be considered
a scalability issue, and allow only "unknown" when the certificate's not
known to have ever been issued?)

I also agree with your observation and assessment of the new "unknown"
text.  That *should* be an "unauthorized" return code.
> >     If nextUpdate is not set, the responder is indicating that newer
> >     revocation information is available all the time.
>
>     NEW:
> >     If nextUpdate is not set, the responder is indicating that it is does not
> >     know when newer revocation information will be available (examples of why
> >     a responder might not know when new revocation information is likely to be
> >     available are that the CA hasn't told it, or because newer information is
> >     available all the time).
>
> DC's opinion: Suggest no change unless someone argues for a need for this change.

KH: If nextUpdate is not set, expect that there will not be an update
until the next CRL issuance.  However, we can't exactly codify how to
check that, so... I would recommend an alternative:

"If nextUpdate is not set, the responder is indicating that it wishes
its responses not to be cached, and to always be checked when evaluating
the certificate.  NOTE: This may be a SEVERE private-information (known
association) leakage."

> 3) Transports for OCSP:
>
>     NEW:
> >     While OCSP can be used over many transports, for interoperability, all
> DC's opinion: Would be a change to the standard, and thus would fall outside of 
> the scope of this update. However, this may be an acceptable change if all 
> existing implementations already support the requirement.
KH: My addition would be this:

While OCSP can be used over many transports, it is vital that the OCSP
responder not need its own certificate's status to be looked up -- i.e.,
it MUST NOT be offered over a channel which, by convention or standard,
requires evaluation of any additional X.509 certificates that the OCSP
responder in question would be authoritative for.

It would be insane to require that https be used for OCSP, since the
OCSP responder's certificate would need to be looked up at... the OCSP
responder, which would return the certificate that would need to be
looked up at... ad nauseum, ad stackoverfloweum.

Especially since OCSP responses are signed independently of the
transport layer.

> >     Prior to accepting a signed response as valid, OCSP clients SHALL confirm
> >     that:
> >
> >     1. The certificate identified in a received response corresponds to that
> >     which was identified in the corresponding request;
>
>     NEW:
> >     NOTE: The first criteria does not imply that a client should reject an
> >     OCSP response from a server that contains statuses of a superset or subset
> >     of the certificates whose statuses were requested i.e. it is all right for
> >     a server to, in an OCSP response provide the statuses of only some of the
> >     certificates requested, and some other certificates whose statues were not
> >     requested. For example, if a client requests the status of certificates
> >     with serial numbers 1 and 2 and gets a response which has the statuses of
> >     certificates with serial numbers 1 and 3, the client can accept that
> >     response for the status of the certificate with serial number 1, assuming
> >     the rest of the response acceptance criteria were met.
>
> DC's opinion: The update already allows the response to include a superset of 
> the certificates whose statuses were requested, based on RFC 5019. Servers that 
> provide fresh responses to requests should never return responses that only 
> include a subset of the certificates whose statuses were requested, since they 
> can respond "unknown" for the certificates whose statuses they don't know. If a 
> server that provides pre-generated responses receives a request that asks for 
> information about multiple certificates should it return a pre-generated 
> response for one of the certificates or return an "unauthorized" response?
KH: If it provides pregenerated responses, why not change the ASN.1 to
allow for multiple individual responses in a SEQUENCE or SET?
> >     certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL
>
>     NEW:
> >     certs [0] EXPLICIT Certificates OPTIONAL
> >
> DC's opinion: This would be a change in the protocol and would be inconsistent 
> with the ASN.1 in RFC 5912. However, a sentence could be added stating that if 
> no certificates are included then the certs field SHOULD be absent rather than 
> being present and containing an empty SEQUENCE.
If the certs field should be absent, rather than containing an empty
sequence, that should be an IMPLICIT, based on my understanding?
> >     issuerKeyHash is the hash of the Issuer's public key. The hash shall be
> >     calculated over the value (excluding tag and length) of the subject public
> >     key field in the issuer's certificate.
> >
> >     issuerKeyHash is the hash of the Issuer's public key. The hash shall be
> DC's opinion: This appears to be a change, but it should be made if this is how 
> current implementations actually compute the hash of a public key.
KH: This is the same problem that's been biting the
authorityKeyIDentifier and subjectKeyIDentifier.  In addition, I'm also
very worried about the concept of algorithm-inflexibility.
> > HTTP based OCSP requests can use either the GET or the POST method to submit 
> > their requests. To enable HTTP caching, small requests (that after encoding 
> > are less than 255 bytes), MAY be submitted using GET. If HTTP caching is not 
> > important, or the request is greater than 255 bytes, the request SHOULD be 
> > submitted using POST. Where privacy is a requirement, OCSP transactions 
> > exchanged using HTTP MAY be protected using either TLS/SSL or some other lower 
> > layer protocol.
> >
> > where {url} may be derived from the value of AuthorityInfoAccess or other 
> > local configuration of the OCSP client.
> >
> > Content-Type header has the value "application/ocsp-request" while the body of 
> > the message is the binary value of the DER encoding of the OCSPRequest.
>
> NEW:
> > HTTP based OCSP requests MUST use the POST method to submit their requests. 
> > Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be 
> > protected using either TLS/SSL or some other lower layer protocol.
> >
> > Content-Type header has the value "application/ocsp-request" while the body of 
> > the message is the binary value of the DER encoding of the OCSPRequest.
>
> DC's opinion: This change should not be made. It is inconsistent with RFC 5019, 
> which requires the use of the GET method for requests that are less than 255 bytes.
KH: This change *cannot* be made.  It is impossible for a
properly-written, appropriately-paranoid stack (*looks at NSS*) to
adhere to.  The OCSP responder replies with a certificate which status
it's authoritative for, but the client can't know that unless it
doublechecks that there's no certificate-evaluation recursion.  This in
turn causes a violation of the 'MAY be protected using either TLS/SSL'
part, in particular related to the informational RFC about how PKIX
certificates were to be used with HTTP.

Also, "where privacy is a requirement", the subject of the certificate
should obtain the OCSP status itself, and use OCSP stapling.  Otherwise,
it's (again) a known-association privacy violation.

(If you don't think that 'known-association' is a valid privacy concern,
you haven't seen the need that CEOs have for
known-to-be-private-and-confidential-and-unrecognized meeting locations
for high-level talks about mergers and acquisitions.  Also, there's US
Federal Law that explicitly requires that phone records not be divulged
to anyone other than they're supposed to be divulged to, which happened
because some congressman's associations with questionable characters
came to light after someone performed a social engineering attack -- the
media called it "pretexting", not the actual word that should have been
used for it, "fraud" -- and obtained that congresscritter's phone
records.  The same thing for library book and video rental records,
though they were protected almost a decade before.)

(The sword cuts both ways, too.  If a known child-porn distributor
looked up the OCSP status of a site, that site could come under
investigation for the same thing that the distributor came under
investigation for.  That's why you don't want clients to look up the
OCSP responses for servers.  If a known child-porn-hosting server looked
up the status of a client's certificate, hooboy.  I would NOT want to be
the person behind that client.)

-Kyle H

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 03 Aug 2010 18:43:31 +1200

>1) Rewording of the "good" and "unknown" certificate status response values:

This is a loooong-overdue fix, particularly since this issue had already been
raised, and debated at length, when 2560 was still in the early draft stages
more than ten years ago.  However it still retains the problematic naming
"good", which means that unless a RP digs down into the depths of the RFC they
won't really be helped much by the new text.  So alongside the text change,
the status should be renamed to "not revoked", which would finally make it
orthogonal with the other status of "revoked".

>6) Computing hash of public key:

What about finally allowing the use of a standard identifier like an
ESSCertIDv2, which I'd already commented on in a previous message?

>To enable HTTP caching, small requests (that after encoding are less than 255
>bytes), MAY be submitted using GET.

Shouldn't this have extra warning text to say that it'll only work if nonces
aren't used?  Anything with nonces will never be cached (*should* never be
cached), so it'd be better to use POST unless you're not worried about replay
attacks.

>DC's opinion:  This change should not be made.  It is inconsistent with RFC
>5019, which requires the use of the GET method for requests that are less
>than 255 bytes.

I think the change is a good move, because unless you're using no-nonce OCSP
it's not going to have the effect you think it will.

Peter.

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 03 Aug 2010 00:48:37 -0700

> the person behind that client.)

If a bad guy can frame someone else just by looking up their
certificate, that is the real problem.

-- 
Matt

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 03 Aug 2010 12:25:12 -0400

Comments in-line

> known to have ever been issued?)

Even if your proposal could be implemented, it would be a change to the 
protocol, which is out of scope for this effort.

The other problem is that an OCSP responder cannot "know" whether the 
requested certificate was ever issued.  The responder is not provided 
with a copy of (or hash of) the requested certificate, but only the (1) 
hash of the issuer's name, (2) hash of the issuer's public key, and (3) 
serial number of the certificate.  An attacker could create a fake 
certificate that is identical to a certificate that was actually issued 
(including issuer name and serial number), but with some fields (e.g., 
subject name) changed.  The signature on the certificate would not 
verify, but a query to an OCSP responder about the certificate would be 
identical to a query about the real certificate that was used as the 
basis for creating the fake certificate.

In addition, a design goal of OCSP was that responders should be able to 
generate the responses using only the information provided in CRLs.  
CRLs provide the set of certificates that were revoked, but not the set 
of certificates that have been issued.

> association) leakage.

I would be against this change.  An OCSP responder that always provides 
fresh responses and that has up-to-date status information would not 
include a nextUpdate value in its responses, but we cannot say that the 
responder "wishes its responses not to be cached."

> allow for multiple individual responses in a SEQUENCE or SET?

This would be an interesting solution, but it would be a change to the 
protocol.

> sequence, that should be an IMPLICIT, based on my understanding?

No, the "EXPLICIT" tag only affects the encoding of certs when it is 
present, and has nothing to do with whether it should be present.  If 
the developers of OCSP had wanted certs to always be present (even if it 
contained an empty SEQUENCE) they would have omitted the "OPTIONAL".  
The current text simply provides two different ways to encode the same 
information and the "NEW" text simply eliminates one of those encodings.

> very worried about the concept of algorithm-inflexibility.

But, unlike key identifiers, it is important that everyone compute 
KeyHash in OCSP in the same way.  Introducing algorithm agility into the 
computation of KeyHash would require a change in the protocol.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 04 Aug 2010 04:42:06 +1200

"David A. Cooper" <[email-masked]> writes:

>requested certificate was ever issued.  The responder is not provided with a 
>copy of (or hash of) the requested certificate, but only the (1) hash of the 
>issuer's name, (2) hash of the issuer's public key, and (3) serial number of 
>the certificate.  An attacker could create a fake certificate that is 
>identical to a certificate that was actually issued (including issuer name 
>and serial number), but with some fields (e.g., subject name) changed.  The 
>signature on the certificate would not verify, but a query to an OCSP 
>responder about the certificate would be identical to a query about the real 
>certificate that was used as the basis for creating the fake certificate.

At the risk of sounding like a broken record, this is what ESSCertIDv2 would 
fix by using a cert hash as the identifier.

Peter.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 03 Aug 2010 12:41:48 -0400

On 08/03/2010 02:43 AM, Peter Gutmann wrote:
> "David A. Cooper"<[email-masked]>  writes:
>    

While I agree with you that calling the status "good" has lead to a lot 
of confusion, since there are many people who know that the response 
status is called "good" who haven't read the document to see what the 
definition of "good" is, changing the name would be a change in the 
protocol, which is outside the scope of changes that I am permitted to 
make.  "good" is a field in the ASN.1.

> ESSCertIDv2, which I'd already commented on in a previous message?

Again, this would be a change in the protocol.

> cached), so it'd be better to use POST unless you're not worried about replay

I disagree.  While this was clearly a controversial issue several years 
ago, RFC 2560 clearly says that the nonce extension is non-critical, 
that support for any particular extension is optional, and that 
unrecognized extensions MUST be ignored.  The description of the request 
syntax says that a request may include "optional extensions which MAY be 
processed by the OCSP Responder".  An OCSP responder that can only 
provide pre-generated responses would be unable to process the nonce 
extension and so would just ignore its presence in the request.

> it's not going to have the effect you think it will.

I don't know what the motivation was for suggesting a change that would 
only allow for the use of the POST method.  Perhaps it was simply to 
simplify things by reducing the number of options.  But, making a change 
that would prevent the use of the GET method would be a change in the 
protocol, it would make the profile in RFC 5019 inconsistent with the 
base standard, and it would make existing implementations that currently 
use the GET method non-compliant.

Dave

---

From: Simon Tardell <[email-masked]>
Date: Tue, 3 Aug 2010 23:36:58 +0200

> client
> certificate

Consider the question the client is asking and the actions it can take. In
the revised text, it is clear that if the client gets "good" it can accept
the certificate, if it gets "revoked" it should reject it, and if it gets
"unknown" it can try get an answer somewhere else.

If you let "unknown" be an affirmative statement about non-issuance then you
would have two values of the response that tell the client to reject the
certificate and none that tells it that it may try a fallback responder.
That spells less scalability to me.

Re: "unwilling": I could think of one reason. Unauthorized is on a response
level where as unknown is on a single response level, so if you check for
more than certificate in a request and want to tell someone to go elsewhere
for one of them, that might be a way. But it feels a bit constructed.

/Simon

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 3 Aug 2010 16:53:19 -0700

> make.  "good" is a field in the ASN.1.

If you change the ASN.1 label, but not the corresponding encoded value then e.g. an OCSP responder could issue something that says "good" and a client could decode it as "not revoked", and each side would understand the correct thing from the data.  IIUC the only compatibility issue would be between an application and its own ASN.1 support and with its own ASN.1 definitions.  I think you can debate whether this actually constitutes a protocol change since neither the bits on the wire nor their *intended* meaning change.

Of course a change like this is likely to cause its own set of confusions, mostly because people will think it's a bigger change than it is.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Thomas Pornin <[email-masked]>
Date: Wed, 4 Aug 2010 14:12:06 +0200

On Tue, Aug 03, 2010 at 04:53:19PM -0700, Henry B. Hotz wrote:
> If you change the ASN.1 label, but not the corresponding encoded value
> then e.g. an OCSP responder could issue something that says "good" and
> a client could decode it as "not revoked", and each side would
> understand the correct thing from the data.

Changing the spelling of a label does not modify on-the-wire encoded
bits... when you use BER encoding rules (or any of its subsets such as
DER). But it changes things if you use XER (the XML encoding rules).

(I have not heard of anyone using XER to encode OCSP responses -- maybe
even signing them with XML-DSig -- but I cannot preclude that
possibility.)

	--Thomas Pornin

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 04 Aug 2010 10:00:20 -0400

Several years ago when X.509 changed the name of the nonRepudiation bit 
in the keyUsage extension to contentCommitment there was a debate within 
the PKIX WG about whether the bit's name should also be changed in 
3280bis (now RFC 5280).  The final decision was against changing the 
name, and as I recall the reason for this decision was as follows 
(http://www.ietf.org/mail-archive/web/pkix/current/msg05257.html):

> Here's the real reason not to change: Many people use ASN.1 compilers 
> which means that names from the ASN.1 module end up being directly 
> used in higher layer code.  Changing the name causes that code not to 
> compile. I'd say that there's quite a lot of 3280 code in the world at 
> this stage. So, if the semantics isn't supposed to have changed (and I 
> assume that is meant to be the case) then this cost just doesn't seem 
> worthwhile.

While I wouldn't be against changing "good" to something like 
"notRevoked", I am going under the assumption that I am not at liberty 
to make any changes to the ASN.1, and so will not make the change unless 
I see strong WG support for it.  Perhaps referring to this as a protocol 
change is incorrect, but I still believe it goes beyond the very limited 
scope of the task assigned to me by the WG.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 04 Aug 2010 10:36:38 -0400

On 08/03/2010 05:36 PM, Simon Tardell wrote:
> Consider the question the client is asking and the actions it can 
> take. In the revised text, it is clear that if the client gets "good" 
> it can accept the certificate, if it gets "revoked" it should reject 
> it, and if it gets "unknown" it can try get an answer somewhere else.
>
> If you let "unknown" be an affirmative statement about non-issuance 
> then you would have two values of the response that tell the client to 
> reject the certificate and none that tells it that it may try a 
> fallback responder. That spells less scalability to me.

I think that is an interesting point.  However, an issue similar to this 
was raised prior to last week's IETF meeting, and I (at least tried) to 
explain it during my presentation on the effort to update OCSP (see 
Slide 13 of http://www.ietf.org/proceedings/78/slides/pkix-2.pdf).  As 
noted in the meeting minutes 
(http://www.ietf.org/proceedings/78/minutes/pkix.htm) those who attended 
the PKIX session were against making any changes.

> Re: "unwilling": I could think of one reason. Unauthorized is on a 
> response level where as unknown is on a single response level, so if 
> you check for more than certificate in a request and want to tell 
> someone to go elsewhere for one of them, that might be a way. But it 
> feels a bit constructed.

I suppose I can create a contrived example in which an OCSP server might 
return "unknown" when it knows the status of a certificate but is 
unwilling to provide the status to the client:

1) Government Agency A operates two PKIs, one to issue certificates for 
use on an classified network and one to issue certificates for use on an 
unclassified network.

2) Government Agency A also operates a locally trusted OCSP responder 
that is capable of providing status information for any certificate 
issued in either PKI.

3) All employees of Government Agency A are authorized to make queries 
to this OCSP responder, however, only those with security clearances are 
permitted to learn the status of certificates issued for use on the 
classified network.

4) An employee without a security clearance sends a OCSP request asking 
the status of two certificates: one issued for use on the classified 
network and one issued for use on the unclassified network.

If the request only asked for the status of the certificate issued for 
use on the classified network, I could argue that a response of 
"unauthorized" would be appropriate since "the client is not authorized 
to make this query to this server."  But in this case only a portion of 
the query is unauthorized.  So, the responder has the choice of error 
sending an "unauthorized" error response and thus not providing 
information about the status of either certificate or of providing a 
non-error response that only provides the status of one of the 
certificates.  For the other certificate, the responder could either not 
mention the certificate in the response (which may or may not be 
permitted by the protocol) or return a status of "unknown".

As you say, this is highly constructed, and so it is not clear to me 
that the document needs to explicitly call this out as a reason that a 
server may return a status of "unknown".

Dave

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Aug 2010 12:22:48 -0400

>...

Not necessarily true. The OCSP responder could make use of TLS and 
have a cert for which a CRL was issued, instead of OCSP.

Steve

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 4 Aug 2010 13:36:05 -0400

-----Original Message-----
From: Stephen Kent
> have a cert for which a CRL was issued, instead of OCSP.

Or it could use a short-term cert that will not be revoked.  It would be
insane to believe that the risk of an OCSP responder's private key being
compromised is comparable in magnitude to the risk of unprotected
communications with the responder being attacked:  "Screw security - I
can't use signed responses or HTTPS because someone might break into the
responder and steal the key".

That's like not using WPA2 for wireless because someone might hack your
machine or the AP and steal the key.

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 05 Aug 2010 20:03:14 +1200

"David A. Cooper" <[email-masked]> writes:

>While I agree with you that calling the status "good" has lead to a lot of
>confusion, since there are many people who know that the response status is
>called "good" who haven't read the document to see what the definition of
>"good" is, changing the name would be a change in the protocol,

Others have already commented on this so I'll just add an additional bit:

>which is outside the scope of changes that I am permitted to make.

Or the RFC police turn up?  Gimme change control and I'll make it :-).

>"good" is a field in the ASN.1.

The problem is that with only the surrounding text changed you now have ASN.1 
that says "A" and explanatory text with it that says "not A", which I think 
will cause more trouble than a change in the ASN.1 (that won't affect 
bits-on-the-wire) will.

>Again, this would be a change in the protocol.

When the RFC police turn up, you can blame me.

>While this was clearly a controversial issue several years ago, RFC 2560
>clearly says that the nonce extension is non-critical, that support for any
>particular extension is optional, and that unrecognized extensions MUST be
>ignored.

Hmm, we're talking about different things here, it's not the OCSP nonce that's
the problem, it's the use of HTTP GET.  GET is idempotent, but if you're using
a nonce then it can never be idempotent, you have to use POST for this (a non-
nonced request is OK with GET).  By using GET with a non-idempotent request
you're breaking cacheing, which seems to be the opposite of what the text
gives as the reason for using GET.

Peter.

---

From: "Sugimoto, Koichi - GlobalSign K.K." <[email-masked]>
Date: Thu, 5 Aug 2010 20:35:01 +0900

Hello all,

client
certificate
> DC's opinion: I think the revised text for "good" is an improvement. I 
> would be concerned about adding "or is unwilling to tell" to 
> "unknown". Why wouldn't the server return an "unauthorized" error code in
this case?

I cannot agree with the "NEW" description.
"OLD" description is rather better than "NEW".

Suppose that the OCSP responder caches a CRL of the corresponding
certificate.
Let x_i be the thisUpdate of the i-th CRL and y_i be the nextUpdate of the
i-th CRL.
Further, let x be the notBefore of the certificate and y be the notAfter of
the certificate.
We can see the relations among the values as x_i < y_i, x < y, and (y_i -
x_i) < (y - x).
Then, the following 5 cases should be evaluated:

1. x < y < x_i < y_i
2. x < x_i <= y < y_i
3. x <= x_i < y_i <= y
4. x_i < x <= y_i < y
5. x_i < y_i < x < y

Let t be the estimated time.
Then, the "OLD" description makes me conclude:

1) If the time t meets x_i <= t <= y_i, then, the OCSP response must be
revoked when the crl contains the serial number of the certificate, and good
when crl does not contain the serial number.
2) If the time t meets t < x_i or y_i < t, then, the OCSP response must be
unknown or internalError.
 - I think "intenalError" is more suitable than "unauthorized".

But the "NEW" description makes the response even complex, I do not think it
better.
See the following my analysis:

http://docs.google.com/fileview?id=0BxzhUySdlJHwMmQ1NDAyNTYtZTBiZC00OWNhLWE5
ZjYtNDMwZjA1MTU5ZTM3&hl=en

Let me remind you the "unknown" problem.
The red part (from 4.1. to 4.6.) is the case of the point in dispute.
In case of SSL server certificates, if the OCSP responder returns "unknown"
to clients, then, most browsers show unauthorized error.
In order to avoid this problem, the server certificate must be issued as
irregular way such that notBefore being smaller than the issued time of the
certificate.

How would you think of this?

Regards,
Koichi Sugimoto.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Aug 2010 10:38:50 -0400

>Or the RFC police turn up?  Gimme change control and I'll make it :-).

The Security ADs have made it clear that they will reject any changes 
of that sort. So, yes, the deputies of the RFC police forbid such 
changes :-).

Steve

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 05 Aug 2010 19:46:38 +0100

On 02/08/2010 22:52, David A. Cooper wrote:
>>     The "good" state indicates a positive response to the status
>>     inquiry.  At a minimum, this positive response indicates that the
>>     certificate is not revoked, but does not necessarily mean that the
>>     certificate was ever issued or that the time at which the response
>>     was produced is within the certificate's validity interval. 
>>     Response extensions may be used to convey additional information
>>     on assertions made by the responder regarding the status of the
>>     certificate such as positive statement about issuance, validity, etc.
>>
>>     The "unknown" state indicates that the responder doesn't know
>>     about the certificate being requested.
> 
>     NEW:
>>     The "good" state indicates that the certificate has not been
>>     revoked.  It does not indicate that the certificate was ever
>>     issued or is in its validity interval.
>>
>>     The "unknown" state indicates that the responder does not know, or
>>     is unwilling to tell, the requestor the status of the
>>     certificate.  A client may be able to get a definitive response
>>     later, or at another responder.
>>
>>     Response extensions may be used to convey additional information
>>     on assertions made by the responder regarding the status of the
> would be concerned about adding "or is unwilling to tell" to "unknown". 
> Why wouldn't the server return an "unauthorized" error code in this case?
> 

Only reason I can see is that "unauthorized" is not signed.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 5 Aug 2010 13:48:54 -0700

> of that sort. So, yes, the deputies of the RFC police forbid such 

Are you sure, or is it worth asking them?

It may sound like I'm advocating the change, but honestly I don't care.  I'm just wondering if there's a way to accommodate the people who do care.

---

From: Simon Tardell <[email-masked]>
Date: Thu, 5 Aug 2010 23:19:50 +0200

> gives as the reason for using GET.
I can't see that it is the nonce that breaks idempotence. It should be the
"producedAt" field, unless you cache. If you use the GET binding you will
only access the same URL if the request is identical (the same nonce too).

/Simon

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Aug 2010 17:08:54 -0400

>Are you sure, or is it worth asking them?

yes, I am sure. Tim (the cognizant Security AD), made it quite clear, 
as did Russ, the IETF Chair.

Steve

---

From: Simon Tardell <[email-masked]>
Date: Thu, 5 Aug 2010 23:35:48 +0200

I had a glass of wine or two to drink at this point, but it seems to me that
you perhaps misunderstood the clarification that the "new" wording tried to
make. In the "old" wording it is possible to understand that other
information about the certificate than its revocation status (such as
issuance, or validity period) would influence whether good, revoked or
unknown was returned. The new wording tries to make it clear that good,
revoked and unknown only refers to revocation. Statements about issuance,
validity etc have to be made in another way.

'The "unknown" state indicates that the responder does not know [...] the
status of the certificate.'

would in your example translate to t being outside of the interval [x_i,
t_i], regardless of the value of x and y.

/Simon

On Thu, Aug 5, 2010 at 13:35, Sugimoto, Koichi - GlobalSign K.K. <
[email-masked]> wrote:

> inquiry. At a
> > >     issued or that the time at which the response was produced is
> within
> the
> > >     additional information on assertions made by the responder
> regarding
> the
> revoked. It
> is
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
>

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 06 Aug 2010 15:54:29 +1200

>Are you sure, or is it worth asking them?

I was going to suggest someone gives me their names and home addresses, but I 
guess your approach would work too :-).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 06 Aug 2010 15:57:31 +1200

>only access the same URL if the request is identical (the same nonce too).

Right, and that's the point, you'll never get a cacheable request/response 
(unless you're replaying a response as per "optimised" OCSP), therefore 
sending it via a mechanism designed to be cacheable doesn't have any effect 
other than to pollute the cache.

Peter.

---

From: koichi sugimoto <[email-masked]>
Date: Fri, 6 Aug 2010 13:58:58 +0900

Thanks for the clarification.
But I'm afraid that adding "or is unwilling to tell" yields ambiguous
implementation.
That causes serious problem that I mentioned.

Regards,
Koichi Sugimoto.

2010/8/6 Simon Tardell <[email-masked]>:
> On Thu, Aug 5, 2010 at 13:35, Sugimoto, Koichi - GlobalSign K.K.
> <[email-masked]> wrote:
>>
>> Hello all,
>>
>> > >     certificate's validity interval. Response extensions may be used
>> > > to
>> convey
>> > > about
>> > > on

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 07 Aug 2010 02:03:22 +1200

Stephen Kent <[email-masked]> writes:
>yes, I am sure. Tim (the cognizant Security AD), made it quite clear, as did 
>Russ, the IETF Chair.

Shall we try my approach then?  Does anyone know where I could buy two severed 
horse's heads?

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 6 Aug 2010 11:15:57 -0400

I've never (well, only once, with NR) seen such passion with regard to a
field/value name in an ASN.1 module.

Perhaps next on the agenda should be a grass-roots movement to fix the
spelling of <a=http://en.wikiquote.org/wiki/Kenneth_Thompson>creat()<a>.

People who read and write source code could reasonably be expected to
read and understand RFC text defining the semantics, regardless of how
CHOICE names are spelled in an ASN.1 module.  To those who:

> haven't read the document to see what the definition of "good" is

the best advice would be RT*M.  Someone who has, for example, an expired
certificate and an OCSP status of "good" and writes code that accepts
the certificate as valid should not be writing security code in the
first place.  Even without looking at the RFC it should be obvious that
a cert with a bad signature or invalid date cannot be valid regardless
of what the OCSP status is called.

TBH, I don't really care what the name is now (not_revoked would have
been a much better name back in 1999), but the fact that XER would
change the bits on the wire is a very strong argument for leaving it as
is.  And the possibility that people who don't RTM and can't think
logically might be confused is a very weak argument for change.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Gutmann
Sent: Friday, August 06, 2010 10:03 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Previous attempt to update OCSP

>yes, I am sure. Tim (the cognizant Security AD), made it quite clear,
as did 
>Russ, the IETF Chair.

Shall we try my approach then?  Does anyone know where I could buy two
severed 
horse's heads?

Peter.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 6 Aug 2010 10:02:49 -0700

> change the bits on the wire is a very strong argument for leaving it as

Absent any implementations that use XER, I could quibble with "very", but I basically agree.

> logically might be confused is a very weak argument for change.

OTOH, I have a problem with values which don't mean what they say.  It just seems "wrong" for OCSP to say a cert is "good" when it was never issued by the relevant CA in the first place.  That there are other non-OCSP checks that are obviously needed is only a partial excuse.

That the rules of the process forbid the change here, doesn't preclude starting a new RFC where it is in scope.

---

From: Simon Tardell <[email-masked]>
Date: Fri, 6 Aug 2010 22:08:07 +0200

Under very constructed circumstances, yes. "or unwilling to tell" was
Ambarish's words IIRC. I am not sure how his thinking went on that.

The rest of the new wording I am strongly in favour of.

/S

On Fri, Aug 6, 2010 at 06:58, koichi sugimoto <
[email-masked]> wrote:

> >> > >     minimum, this positive response indicates that the certificate
> is
> >> not
> >> But the "NEW" description makes the response even complex, I do not
> think
> >> it
> >> better.

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 6 Aug 2010 16:50:53 -0400

-----Original Message-----
From: Henry B. Hotz [mailto:[email-masked]]

> It just seems "wrong" for OCSP to say a cert is "good"
> when it was never issued by the relevant CA in the first place.

I can understand that.  But in my mind, OCSP is saying the cert status is "[0] NULL".  Applications translate from binary values to human-meaningful displays all the time, and nothing prevents applications from translating those bits to "not revoked" or "pas révoqué" or "לא בוטל" regardless of how the ASN.1 module labels that CHOICE option.  (French and Hebrew courtesy of Google - don't blame me if they are gibberish :-).

And I agree that if a different protocol (OCSPv2) were being written, it could use a different status structure with different field names.

Dave

---

From: "Kyle Hamilton" <[email-masked]>
Date: Sat, 7 Aug 2010 00:17:51 -0700 (PST)

Even "not revoked" has some serious violations of the principle of least astonishment.  Every app would have to add the caveat "not revoked (possibly never issued)".

-Kyle H

---

From: Simon Tardell <[email-masked]>
Date: Sat, 7 Aug 2010 17:06:10 +0200

The OCSP client would normally have the certificate at hand. So if the cert
is not issued, it is forged, and then you have another problem.

I am not aware of any other PKI:s other than some German signature law
compliant PKI that want to assert statements on issuance in OCSP responses.
And it is only because the law requires the user to accept the token before
it can be used, so there exists a state "issued, but not accepted" for
tokens that were produced centrally, and this was grafted onto OCSP by
hijacking "unknown" (so, it is not really a statement about issuance). In my
mind, it could have been better.

Outside of this pathological case, are statements about issuance really an
issue?

/Simon

On Sat, Aug 7, 2010 at 09:17, Kyle Hamilton <[email-masked]> wrote:

> Even "not revoked" has some serious violations of the principle of least
> astonishment.  Every app would have to add the caveat "not revoked (possibly
> never issued)".
>
> -Kyle H
>
>
>> I can understand that.  But in my mind, OCSP is saying the cert status is
>> "[0] NULL".  Applications translate from binary values to human-meaningful
>> displays all the time, and nothing prevents applications from translating
>> those bits to "not revoked" or "pas révoqué" or "לא בוטל" regardless of how
>> the ASN.1 module labels that CHOICE option.  (French and Hebrew courtesy of
>> Google - don't blame me if they are gibberish :-).
>>
>> And I agree that if a different protocol (OCSPv2) were being written, it
>> could use a different status structure with different field names.
>>
>> Dave
>>

---

From: "Kyle Hamilton" <[email-masked]>
Date: Sat, 7 Aug 2010 17:59:46 -0700 (PST)

> mind, it could have been better.

Agreed.

> Outside of this pathological case, are statements about issuance really an

Yes.

How else is the CA supposed to figure out that it's been compromised?  "Many eyes make all bugs shallow."   If you look at an OCSP client as an observer, and its query as a proposed patch, you can see the utility of OCSP not merely for the relying party but also for the CA.

And the reason why is because if OCSP is a means of performing a near-real-time validation of certificate status (Online Certificate Status Protocol), there needs to be an explicit "do not trust" state, with perhaps an extension that requests the full certificate be submitted for verification, or at the very least a trigger in the background saying that a certificate was checked that matched the hash of the issuer but was not in the online database of status information.  A truly-bad certificate should never have a status of "good", in ANY protocol.

-Kyle H

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 07 Aug 2010 18:32:03 -0700

On Sat, 2010-08-07 at 17:59 -0700, Kyle Hamilton wrote:
> How else is the CA supposed to figure out that it's been compromised?
> "Many eyes make all bugs shallow."   If you look at an OCSP client as
> an observer, and its query as a proposed patch, you can see the
> utility of OCSP not merely for the relying party but also for the CA.

It is useless against compromise of the CA's private key, because the
attacker would just forge certificates without the pointer to the OCSP
responder.  It might be useful against a vulnerability in the CA's
certificate issuance system that lets the attacker get certificates with
some fields forged but not remove the OCSP field.

-- 
Matt

---

From: "Kyle Hamilton" <[email-masked]>
Date: Sat, 7 Aug 2010 20:52:18 -0700 (PST)

Hypothetical situation:

Third-party responder which has additional information about the trust anchors, including knowledge that *all* certificates issued by them have OCSP built-in.

Client browser which is configured to use third-party responder for everything.

Client browser sends the hashes.  The third-party responder can find out from the CA "never issued", and initiate an investigation.

You are viewing the problem as one that must be resolved without additional input.  We have an environment from which we can gain additional data, including the concept that the application is the final arbiter of what it will accept.  If (say) a browser were updated with the knowledge that OCSP from a given CA would *always* be available from a given URL, it would give reason for pause if the OCSP data didn't return "okay".  (Then again, it could also be a change to PKIX, because such information could be readily included in the self-signed CA certificate containing the trust anchor and additional attributes associated with that anchor's trust.)

That's the biggest reason why I don't like the idea of "okay" being able to return "okay" for a certificate that was never issued.  It's completely and absolutely confusing -- there's no absolute positive in the protocol, there's only an absolute negative.

-Kyle H

---

From: Tomas Gustavsson <[email-masked]>
Date: Sun, 08 Aug 2010 10:03:48 +0200

Hi,

On 08/08/2010 05:52 AM, Kyle Hamilton wrote:
> Hypothetical situation:
>
> Third-party responder which has additional information about the trust
> anchors, including knowledge that *all* certificates issued by them have
> OCSP built-in.
>
> Client browser sends the hashes. The third-party responder can find out
> from the CA "never issued", and initiate an investigation.
>
> You are viewing the problem as one that must be resolved without
> additional input. We have an environment from which we can gain
> additional data, including the concept that the application is the final
> arbiter of what it will accept. If (say) a browser were updated with the
> knowledge that OCSP from a given CA would *always* be available from a
> given URL, it would give reason for pause if the OCSP data didn't return
> "okay". (Then again, it could also be a change to PKIX, because such
> information could be readily included in the self-signed CA certificate
> containing the trust anchor and additional attributes associated with
> that anchor's trust.)
>
> That's the biggest reason why I don't like the idea of "okay" being able
> to return "okay" for a certificate that was never issued. It's
> completely and absolutely confusing -- there's no absolute positive in
> the protocol, there's only an absolute negative.

Perhaps the name "ok" is not the most clear in the world, since it 
really means "not revoked".

Large PKIs have a couple of different, reasonable, reasons to answer OK 
to everything that is not explicitly revoked.

1. Very large data sets. If you have issued several hundred million 
certificates the database of issued certificates is very large. In order 
to keep data sizes down you can opt to only keep revoked certificate 
info in the OCSP responders database.

2. High performance. If you have issued several hundred million 
certificates the database of issued certificates is slower to search. In 
order to keep response times as low as possible you can opt to only keep 
revoked certificate info in the OCSP responders database.

Issue 2 is also valid if you use pre-generated OCSP responses, in which 
case you must answer OK to everything not revoked, otherwise 
pre-generation is pretty much pointless.

In our implementation (EJBCA) we first required everything in the 
database so we could answer "unknown". But we quickly had to introduce a 
configuration option to only keep revoked certificates in the database, 
so we can handle both requirement sets.

>> some fields forged but not remove the OCSP field.

Or if I compromised a CA I might as well issue a certificate as usual, 
impersonating someone else. From both the CA and OCSP point of view 
everything would be normal.

Cheers,
Tomas

---

From: Yoav Nir <[email-masked]>
Date: Sun, 8 Aug 2010 11:10:07 +0300

On Aug 7, 2010, at 6:06 PM, Simon Tardell wrote:

> The OCSP client would normally have the certificate at hand. So if the cert is not issued, it is forged, and then you have another problem. 
> 
> I am not aware of any other PKI:s other than some German signature law compliant PKI that want to assert statements on issuance in OCSP responses. And it is only because the law requires the user to accept the token before it can be used, so there exists a state "issued, but not accepted" for tokens that were produced centrally, and this was grafted onto OCSP by hijacking "unknown" (so, it is not really a statement about issuance). In my mind, it could have been better.
> 
> Outside of this pathological case, are statements about issuance really an issue?

Sure, here's another pathological case. We had a database corruption in our CA, and had to revert to a 3-day old backup. That left a few certificates that were issued, but not in the database, which meant that they could not be revoked, without some manual tampering with the database. We referred to these certificates as time travelers, or visitors from an alternate reality. There were also a lot of Doc Brown impressions. But an OCSP reply could make these certificates unusable without manually modifying the database. It would also confuse the heck out of the users.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 08 Aug 2010 21:58:25 +1200

Yoav Nir <[email-masked]> writes:

>We had a database corruption in our CA, and had to revert to a 3-day old 
>backup. That left a few certificates that were issued, but not in the 
>database, which meant that they could not be revoked, without some manual 
>tampering with the database. We referred to these certificates as time 
>travelers, or visitors from an alternate reality. There were also a lot of 
>Doc Brown impressions. But an OCSP reply could make these certificates 
>unusable without manually modifying the database. It would also confuse the 
>heck out of the users.

Did this actually happen, or is it a what-if?

In any case I think it's not the job of PKI protocols to try and compensate 
for the behaviour of broken CAs.  A variation of this might be "we 
accidentally sold our CA's HSM on eBay and now a few certificates have been 
issued that aren't in our database.  We referred to these certificates as time 
travellers [...]".  This is the CA's problem, not something that a PKI 
protocol should be expected to clean up after the fact.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 8 Aug 2010 13:52:11 +0300

> Did this actually happen, or is it a what-if?

This was a CA that our QA department use for testing, but yes, it really happened. I really told the QA guy that he needs to think 4-dimensionally. And not to touch the hardware token because it might be made from anti-matter.

> protocol should be expected to clean up after the fact.

Agree. But a server giving OCSP answers out of a CRL does not count as online verification to me. I think whoever answers the OCSP requests should have access to the database, and be able to answer "good", "revoked" or "wait-a-minute...". "Unknown" is a kludge for broken implementations.  

If an OCSP responder gets a request for a non-existant certificate, it is a sure indication that something is wrong, and should be investigated (by humans), although I guess OCSP requests can be easily forged, no?

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 8 Aug 2010 08:02:49 -0400

The discussion of mechanisms to check things other than revocation status of a certificate is beyond discussion of RFC 2560, its revision and OCSP.

Section 1 and 2 of RFC 2560 make it clear that OCSP is a substitute for CRL; nothing more.

You should write a separate I-D to provide other features and services.

P.S: I would withhold judgment in its value regarding compromise detection of CA until I see the whole draft as opposed to mail-list discussion.

> Kyle Hamilton
> Sent: Saturday, August 07, 2010 11:52 PM
> To: Matt McCutchen
> Cc: [email-masked]
> anchors, including knowledge that *all* certificates issued by them
> have OCSP built-in.
> 
> Client browser sends the hashes.  The third-party responder can find
> out from the CA "never issued", and initiate an investigation.
> 
> additional data, including the concept that the application is the
> final arbiter of what it will accept.  If (say) a browser were updated
> with the knowledge that OCSP from a given CA would *always* be
> available from a given URL, it would give reason for pause if the OCSP
> data didn't return "okay".  (Then again, it could also be a change to
> PKIX, because such information could be readily included in the self-
> signed CA certificate containing the trust anchor and additional
> attributes associated with that anchor's trust.)
> 
> That's the biggest reason why I don't like the idea of "okay" being
> able to return "okay" for a certificate that was never issued.  It's
> > certificate issuance system that lets the attacker get certificates
> > with some fields forged but not remove the OCSP field.
> >
> > --
> > Matt
> >
> >

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 09 Aug 2010 00:46:18 +1200

> You should write a separate I-D to provide other features and services.

And would this get any further than it did the last time it was tried?

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 8 Aug 2010 10:30:49 -0400

This is not going anywhere at all.

I-D should go further if has practical value.

> From: Peter Gutmann [mailto:[email-masked]]
> Sent: Sunday, August 08, 2010 8:46 AM
> To: Santosh Chokhani
> Cc: Kyle Hamilton; Matt McCutchen; [email-masked]

---

From: "Bentkofsky, Michael" <[email-masked]>
Date: Sun, 8 Aug 2010 17:14:21 -0400

Having implemented a high performance (over 20k requests per second)
OCSP service for a large data set of millions of public certificates, I
don't believe that answering Ok for a certificate that was never issued
is particularly targeted at the performance constraints of large CA's.
Most of the reason appears to be that OCSP is generated from CRL's,
which of course only details revoked certificates. I believe this has
been a failing of OCSP thus far and believe there could be a lot of
value in providing a way to differentiate between "not revoked, but
issued" and "never issued". Whenever I talk to people about verifying
certificate status, they naturally believe the "Ok" is indicating not
only non-revocation, but is also giving an indication that the
certificate is "valid".

Thanks,

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tomas Gustavsson
Sent: Sunday, August 08, 2010 4:04 AM
To: [email-masked]
Subject: Re: [pkix] Previous attempt to update OCSP

Hi,

> anchors, including knowledge that *all* certificates issued by them
have
> Client browser sends the hashes. The third-party responder can find
out
> additional data, including the concept that the application is the
final
> That's the biggest reason why I don't like the idea of "okay" being
able

>
> -Kyle H
>
> On Sat, Aug 7, 2010 at 6:32 PM, Matt McCutchen
<[email-masked]>
> wrote:
with

Cheers,
Tomas

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 09 Aug 2010 17:32:24 +1200

>I-D should go further if has practical value.

So the last time this came up it was excluded from consideration because it
was felt that anything that provided a positive response to a cert-status
query would impurify the precious bodily fluids of DPD/DPV, even though this
has almost nothing to do with DPD/DPV (my comments at the time were that given
the quagmire that was DPD/DPV I had a strong vested interest in keeping as far
from that as possible).  The opposition to a positive-response status got
quite rabid, to the extent that one PKIX member made a personal appeal to the
WG chair to have any discussion of positive-status mechanisms excluded from
consideration (!!!).  Looking through the email from the discussion from
*eight years ago* here's one comment:

  OCSP deals only with revocation status, consistent with its role as an
  alternative to a CRL, and that is the critical, defining characteristic of
  the service it offers. I agree that folks really want to know whether a cert
  is valid, more than they want to know whether it has been revoked. CRLs
  clearly offer only the revocation status part of the answer, and OCSP does
  the same, yet we have seen examples of people who either misunderstood that
  the answer "no revoked" is not the same as "valid,"

This is the very same discussion that we're having right now, but this was
eight years ago!  (And the same thing had already been going on long before
OCSP was published, so this issue is more than a decade old).

This is why I'm rather cynical about it ever being fixed, it was a known
problem before OCSP was even published as a standard, it's been a problem ever
since, it gets discussed every now and then, and like many problems on PKIX
the discussion eventually dies out when people get tired of it and nothing
ever gets fixed.

Anyway, to keep things simple I'll just point to the last draft from when a
positive-response protocol was attempted:

http://tools.ietf.org/id/draft-gutmann-cms-rtcs-01.txt

Peter.

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 09 Aug 2010 12:39:24 +0200

On 08/09/2010 07:32 AM, Peter Gutmann wrote:
> "Santosh Chokhani"<[email-masked]>  writes:
>>> Santosh Chokhani<[email-masked]>  writes:
>>>

I guess that the current OCSP functioning is now so cemented (due to 
large scale world-wide deployment) that it is nearly impossible to 
change anything fundamental. In that case using an extension mechanism 
is probably the only reasonable way.

/Tomas

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 09 Aug 2010 12:52:15 +0200

The text says:

    The value for signature SHALL be computed on the hash of the DER
    encoding ResponseData.

I think it would more correct to use the fiedlname tbsResponseData

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 09 Aug 2010 13:46:06 +0200

> is probably the only reasonable way.

The proposed change of the definition of 'good' doesn't seem very 
helpful in this case
I don't think that it is an improvement.
It can be considered as a change in the protocol.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Aug 2010 13:18:15 -0400

Peter,

Thanks for sharing this.  I do not recall reading this.

One resistance I see to this is CA providing on-line status.  That has
both security and performance implications.

The I-D does provide how a rogue party can mint certificates of a CA and
how the protocol protects against the same rogue party to provide the
status response also.

> Sent: Monday, August 09, 2010 1:32 AM
> To: [email-masked]; Santosh Chokhani
> Cc: [email-masked]
> query would impurify the precious bodily fluids of DPD/DPV, even
though
> this
> the quagmire that was DPD/DPV I had a strong vested interest in
keeping
> as far
>   the service it offers. I agree that folks really want to know
whether
> a cert
>   clearly offer only the revocation status part of the answer, and
OCSP
> does

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 09 Aug 2010 22:40:14 +0200

Hi,

Perhaps the wide spread adoption of OCSP is due to the extreme simplicity of the protocol, and its semantics. Something that is very rare in standardization. If you talk about adding stronger validation semantics to OCSP, how does this relate to other protocols such as SCVP? 
I can easily see why this has not moved forward in eight years. Anyone can _almost_ understand and implement ocsp, make it more complex and adoption drops rapidly. It's a wonder x.509 is used at all. To expect that the more intrinsic parts are used correctly is just too much to expect.

I agree with Peter that one protocol countering for the failure of another protocol if still born (at least that is my interpretation of his words).

Cheers,
Tomas

---

From: Simon Tardell <[email-masked]>
Date: Mon, 9 Aug 2010 22:54:40 +0200

On Mon, Aug 9, 2010 at 13:46, Peter Sylvester <[email-masked]>wrote:

>
>  I guess that the current OCSP functioning is now so cemented (due to large
>> scale world-wide deployment) that it is nearly impossible to change anything
>> fundamental. In that case using an extension mechanism is probably the only
>> reasonable way.
>>
>
> The proposed change of the definition of 'good' doesn't seem very helpful
> in this case

I don't agree here. The old wording is unclear and has given rise to two
different, incompatible interpretations. Clarifying which interpretation is
correct is not a change. It is a clarification.

The new wording ensures (or improves, depending on your viewpoint)
scalability. The other interpretation of the old wording (where "unknown"
would be a positive assertion) has to be implemented some other way to be
compatible with the protocol (perhaps we should specify a standard extension
for this, while we are at it, since there seems to be some kind of interest
in it, just to make sure everyone is satisfied). Existing implementations
don't have to change anything though, they work, but lack the scalability of
the new wording.

/Simon

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Aug 2010 18:44:07 +1200

Tomas Gustavsson <[email-masked]> writes:

>Perhaps the wide spread adoption of OCSP is due to the extreme simplicity of 
>the protocol, and its semantics.

OCSP isn't that simple, it's actually quite complicated for what it does.  The
reason it gets used is because it's not CRLs.  In the absences of OCSP, you
could come up with a protocol that used trained chimpanzees to report status
info and people would still flock to it because it's not CRLs.

In any case no RP ever notices whether it's simple or complex because they
don't implement it, they just use it.  What they see is "here's a protocol
that will tell you in real-time whether a cert is valid or not", without
realising that they're not getting anything like that.  So RTCS is an attempt
to give people what they're actually expecting from a cert-status protocol.
Adapting your design to do what the world expects is so much easier than
expecting the world to adapt to what your design does (which in OCSP's case
hasn't happened, and is unlikely to ever happen).

Peter.

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 10 Aug 2010 09:30:52 +0200

On 08/10/2010 08:44 AM, Peter Gutmann wrote:
> Tomas Gustavsson<[email-masked]>  writes:
>

I totally buy that OCSP is used because there is nothing worse than CRLs.

> hasn't happened, and is unlikely to ever happen).

However I do think that you underestimate some of the users of OCSP, I 
think many of them do know that it is a replacement for CRLs and the 
validation includes more than a revocation check.
I also think the semantics (ok, unknown, revoked) is more or less domain 
specified, since OCSP is usually deployed in a specific domain where the 
TP defines the boundaries of the world. In this OCSP gives much 
flexibility since it allows usage of unknown, if the TP desires, and it 
can leave it out if so desired (global replication of large databases is 
an issue for OCSP providers).

Like it or not, OCSP obviously filled a business need, having the 
advantage of being first to market...

RTCS sounds quite reasonable though, I like the re-use of CMS and the 
high speed/high volume design. Do you see any chance of actually 
promoting a new protocol and get it widely adopted?

(I have no personal strings attached to OCSP, I prefer implementing the 
easiest protocol if users want it.)

/Tomas

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 10 Aug 2010 10:06:17 -0400

-----Original Message-----
From: Tomas Gustavsson

>> reason it gets used is because it's not CRLs.
>>

Nothing is worse than 10 MB CRLs over LDAP.  But nothing, including OCSP
or RTCS, could be better or simpler than 10 KB CRLs over HTTP, thus
taking advantage of the entire web caching infrastructure.  The fact
that CRLs have been poorly deployed throughout their entire existence is
not an indictment of the CRL's elegant (for PKI) data structure; both
OCSP and any CMS-protected data are far more bloated.

> RTCS sounds quite reasonable though, I like the re-use
> of CMS and the high speed/high volume design. Do you see any
> chance of actually promoting a new protocol and get it widely adopted?

Claiming both high volume (through use of symmetric authenticatedData)
and simplicity (through use of CMS) is a bit misleading.  Unsigned data
through TLS has high volume and key management.  Authenticated data
through CMS has no key management, so someone would have to re-invent
that wheel (probably badly) - the very talking point that RTCS uses
against OCSP.

Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Aug 2010 10:17:35 -0400

Why not just use partitioned CRL and get rid of OCSP and another box to
attack and another trust component and its key management to analyze in
the security architecture.

Partitioned CRL asymptotically can converge to what OCSP does given that
most OCSP deployments I am aware of not really real-time; they either
serve pre-signed response or even nonce-based responses are based on
CRL.

> Kemp, David P.
> Sent: Tuesday, August 10, 2010 10:06 AM
> To: [email-masked]

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 10 Aug 2010 17:12:02 +0200

> the security architecture.

So you mean that you will serve your CRLs from the same machine as 
running the CA? Sounds not very likely to happen, unless your scale is 
so small that you don't need either CRLs or OCSP anyhow.

> serve pre-signed response or even nonce-based responses are based on

I'm aware of several real-time OCSP deployments. I am not aware of any 
CA that partitions the CRL into 3000 pieces to make them small enough. 
Generating the 3000 CRLs every 2 hours does not sound like something I 
would recommend.
(30000 pieces is what is needed to make one 30MB CRL into 10KB CRLs).

Let's face it, different requirements is served best by different means, 
be it CRLs, OCSP or RTCS. I don't think there will ever be one 
technology to rule them all.

Cheers,
Tomas

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 10 Aug 2010 11:48:55 -0400

Umm, looking at the first Google hit I ran across
(http://java.sun.com/developer/technicalArticles/xml/dig_signatures/),
they are talking about 1000 XML sign operations per second on Intel
hardware for 1024 bit keys.  (They also claim 5,500 sigs/sec for SPARC
hardware.)  Why would 30,000 signatures per 2 hours (4.2 sigs/sec) be
"not recommended" for a CA with enough customers to have 30MB CRLs?

Dave

-----Original Message-----
From: Tomas Gustavsson

Cheers,
Tomas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Aug 2010 12:30:07 -0400

Tomas,

CA published partitioned CRL to an HTTP Web server, obviating the need
for the relying parties to access the CA.

I do not know what you mean by "scale it so small" in this context.  You
always need revocation information unless certificate validity period is
small.  In that case you are signing certificates daily or every few
hours.

As to the performance, the technology that makes an OCSP responder sign
all those responses, be used by the CA also to sign and publish
partitioned CRLs.

> Sent: Tuesday, August 10, 2010 11:12 AM
> To: [email-masked]
> >> From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> >>>> OCSP isn't that simple, it's actually quite complicated for what
> it
> >> does.  The
> >>> I totally buy that OCSP is used because there is nothing worse
than
> >> CRLs.
> >> that CRLs have been poorly deployed throughout their entire
> existence
> >> is

---

From: "Polk, William T." <[email-masked]>
Date: Tue, 10 Aug 2010 16:01:49 -0400

After reviewing this thread, Sean and I would like to remind everyone that the scope of this effort is strictly limited to cleaning up the current OCSP protocol specifications (as specified in RFCs 2560, 5019, and the ocsp-agility draft).  The Security ADs are in agreement that changing status names is outside the scope, and should be tabled for this document.

Thanks,

Tim Polk

On 8/5/10 5:08 PM, "Stephen Kent" <[email-masked]> wrote:

Steve

---

From: Simon Tardell <[email-masked]>
Date: Tue, 10 Aug 2010 22:21:04 +0200

On Tue, Aug 10, 2010 at 09:30, Tomas Gustavsson <[email-masked]> wrote:

> specified, since OCSP is usually deployed in a specific domain where the TP
> defines the boundaries of the world.
>

I see a lot of PKI deployments, that, while being closed domains are not
able to define any semantics. They control the OCSP responder, but the OCSP
clients are standard issue (the built-in clients in the platforms). In my
experience, custom OCSP clients are rare. YMMV, of course.

> In this OCSP gives much flexibility since it allows usage of unknown, if
> the TP desires, and it can leave it out if so desired (global replication of
> large databases is an issue for OCSP providers).
>

Useage or non-usage of a feature is a flexibility, yes, but I would perhaps
not use the same word for wringing the meaning of a vague wording in the
specification.

/S

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 10 Aug 2010 14:45:07 -0700 (PST)

> OCSP and any CMS-protected data are far more bloated.

If the CRL actually included semantics as to "was a particular certificate valid at a particular date/time", I'd agree with you about their elegant data structure; as it is, though, there's at least two problems I see:

1) CRLs allow expired certificates to "fall off", which prevents anything but the first CRL after the expiration of the certificate from being a time-based authority as to the status of the certificate during its nominal notBefore/notAfter timeframe.  (If I had the ability to specify the "next generation" of CRLs, I'd ensure that there was an 'archive' mechanism, where someone could query for the CRL of a given time.)
2) CRLs suffer a particular issue called "misrevocation".  i.e., the wrong certificate gets added to the CRL with keyCompromise as the reason, someone downloads it, the error is corrected (and the serial number of the incorrect certificate removed and the correct one added), and now any client that didn't get the mis-issued CRL will work properly with the mis-revoked certificate, but the clients that implement strict CRL semantics will never work properly with the mis-revoked certificate again.  This can't be fixed by adding the incorrect serial number with 'removeFromRevocationList' as the reason code, as rFRL is only specified as valid with delta CRLs.

>> chance of actually promoting a new protocol and get it widely adopted?

If we need real-time credential status, why are we using certificates?  They were *specifically* created by the ITU nee CCITT as a means to provide *offline* -- that is, *no available connection to the recorder* -- reliable credentials.  If you need real-time status, you cannot rely on certificates.  You must do the "verify with privilege management authority" thing; the only reason why PKIX has to be implemented is because TLS requires it as the only mandatory authentication scheme.

Otherwise, if you need real-time identity and privilege status, the only thing that should exist is an empty X.509 structure with nothing more than the key and the Issuer therein.  You can get the rest of the data associated with the key from the Issuer by using the key as an index into the Issuer's record, without having to clog up the rest of the system.

(I'll note that I've gotten my head chomped by Nelson Bolyard of NSS for having the temerity to suggest that TLS should allow for PEM/base64-encoded certificates in the protocol -- because it causes a 33% data size increase, and the ease of traffic content analysis for a sysadmin who's trying to understand why a given server is failing.  I'm now suggesting dropping at least 3/4 of the information in the certificate, because it can be obtained online much more easily and authoritatively than via a data structure which was designed for offline, no-real-time-status-availability use.)

PKIX fails to meet many (and, it could be argued, even 'most') of its stated goals.  More "patchy protocols" have grown around PKIX than anything else, including HTTP (which has the 'cookie protocol' to try to make up for its lack of pure session support).  There is no support for Attribute Certificates in PKIX, and PKIX grants extendedKeyUsage capability far too liberally to be anything other than an extremely efficient means for public CAs to extort more money from an unsuspecting populace.  ($450 for a certificate to sign PDF files?!)

Also, PKIX's lack of prescribing minimum standards for verification has led to a problem where neither Penango (an in-browser S/MIME client with certificate verification capability) nor Qualys's SSLLabs Server Certificate Survey can determine from a technical standpoint that anything more than a domain or an email address has been verified.  Because these products _only_ display what they can absolutely know, the absolute minimum which can be certified by a CA, there is no benefit at all to increasing the Class of certificate one obtains.  To provide an example of this, I have had state taxing authorities use domain-validated certificates (instead of Organization-Validated) on their websites, to save taxpayer money.  There's no differentiation in the UI, so why should they bother with OV?

(In my case, I have a Class 2 validation through StartCom.  The benefits I'm provided with are my name and city in my email certificate, a 2-year code-signing certificate and wildcard, multi-domain server certificates.  The code-signing certificate is just another example of "extendedKeyUsage" abuse; the last is only slightly less damaging to think about.)

Just because I know who CA A says EE B is doesn't mean that I automatically grant access to B, and I don't necessarily trust A's assertion as to B's identity anyway.  That decision is taken out of my hands by the people who make browser software, and add trust by default to organizations that I have no knowledge of.  There is no reason for this, other than that PKIX fails to address the real problems underlying the Internet's lack-of-identity-authenticity.

Essentially, PKIX is a failure.  It failed to create mutual-authentication systems that were widely deployed, which led to the prefix-injection attack against TLS on the public Internet to be exploited.

(When -- if ever -- is the PKIX WG going to realize that the spec it has created has no place on the open Internet, and only has appropriate scope to be deployed in a particular administrative domain -- and thus is outside of the scope of Internet standards organizations?  There *is* no Universal Font of Trust.  The ITU operates a CA, and they don't even certify people or organizations they can't verify above and beyond a simple email or domain validation check -- and their CA is *not* PKIX-profiled.)

In fact: X.509 is primarily about an identity infrastructure.  The PKI must exist before the Privilege Management Infrastructure, but the PKI is NOT any kind of PMI.  Until the PMI is defined -- which is exceptionally out-of-scope for the IETF -- no privileges should be able to be granted due to flags set by a CA on a particular certificate.

-Kyle H

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 10 Aug 2010 19:13:13 -0400

-----Original Message-----
From: Kyle Hamilton [mailto:[email-masked]] 

> If the CRL actually included semantics as to
> "was a particular certificate valid at a particular
> date/time", I'd agree with you about their elegant
> data structure; as it is, though, there's at least
> two problems I see:
>
> 1) CRLs allow expired certificates to "fall off",
> which prevents anything but the first CRL after the
> expiration of the certificate from being a time-based
> authority as to the status of the certificate during
> its nominal notBefore/notAfter timeframe.
> (If I had the ability to specify the "next generation"
> of CRLs, I'd ensure that there was an 'archive' mechanism,
> where someone could query for the CRL of a given time.)

What does this have to do with CRLs or PKIX?  You could stand up a
repository right now (or just use the wayback machine) that responds to
queries by date/time for anything you wish to archive, including CRLs.

> 2) CRLs suffer a particular issue called "misrevocation".
> i.e., the wrong certificate gets added to the CRL with
> keyCompromise as the reason, someone downloads it, the
> error is corrected (and the serial number of the incorrect
> certificate removed and the correct one added), and now
> any client that didn't get the mis-issued CRL will work
> properly with the mis-revoked certificate, but the clients
> that implement strict CRL semantics will never work properly
> with the mis-revoked certificate again.

Can you point to the RFC 5280 section that calls for Relying Parties to
behave as you describe?

Section 6.3.3 says "This algorithm begins by assuming that the
certificate is not revoked."
Section 6.3.3 (a) (1) (ii) says: "Update the local CRL cache with a
current complete CRL, verify that the current time is before the next
update value in the new CRL, and continue processing with the new CRL."

What I don't see is any text that requires or suggests that RPs preserve
state from previous CRLs, and any such text would be in conflict with
the initialization process.

A CA that removes a serial number from a CRL before the certificate
expires is not PKIX-compliant.  But an RP that received such a
non-compliant "corrected" CRL would assume that the certificate is not
revoked.

> If we need real-time credential status, why are we using certificates?
> They were *specifically* created by the ITU nee CCITT as a means
> to provide *offline* -- that is, *no available connection to the
> recorder* -- reliable credentials.

Certificates can be used both offline and online, unlike mechanisms that
can be used only online (i.e. that require interaction with a server
before a user can be authenticated).  If an authentication server has
high latency or is not 5 9's reliable, certificate-based authentication
can proceed immediately whereas interactive authentication would stall
waiting for the server to respond or come back up.

> If you need real-time status, you cannot rely on certificates.

This is both a non-sequitur and patently false.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 Aug 2010 15:12:40 +1200

"Kyle Hamilton" <[email-masked]> writes:

>DQoNCk9uIFR1ZSwgQXVnIDEwLCAyMDEwIGF0IDc6MDYgQU0sIEtlbXAsIERhdmlkIFAuIDxEUEtl
>bXBAbWlzc2kubmNzYy5taWw+IHdyb3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
>PiBGcm9tOiBUb21hcyBHdXN0YXZzc29uDQo+DQo+PiBPbiAwOC8xMC8yMDEwIDA4OjQ0IEFNLCBQ
>ZXRlciBHdXRtYW5uIHdyb3RlOg0KPj4+DQo+Pj4gT0NTUCBpc24ndCB0aGF0IHNpbXBsZSwgaXQn
>cyBhY3R1YWxseSBxdWl0ZSBjb21wbGljYXRlZCBmb3Igd2hhdCBpdA0KPiBkb2VzLiCgVGhlDQo+
>Pj4gcmVhc29uIGl0IGdldHMgdXNlZCBpcyBiZWNhdXNlIGl0J3Mgbm90IENSTHMuDQo+Pj4NCj4+

Interesting, I'd never considered the misrevocation issue.  Is this a real
problem though, or just (one of many) conceptual issues with periodic-
blacklist-based validity checks?

(Given that fact that revocation checking barely works anyway - I'm still
waiting for the Realtek malware cert to be regarded as revoked by software a
month after the CA declared it revoked - I'd say that it's not such a big
concern, but only because of the nonfunctionality of the revocation mechanism
as a whole).

>IHRoZSBDUkwgd2l0aCBrZXlDb21wcm9taXNlIGFzIHRoZSByZWFzb24sIHNvbWVvbmUgZG93bmxv
>YWRzIGl0LCB0aGUgZXJyb3IgaXMgY29ycmVjdGVkIChhbmQgdGhlIHNlcmlhbCBudW1iZXIgb2Yg
>dGhlIGluY29ycmVjdCBjZXJ0aWZpY2F0ZSByZW1vdmVkIGFuZCB0aGUgY29ycmVjdCBvbmUgYWRk

Drifting rather off topic here, but I think attribute certs are a lost cause,
and have been for years.  If you really want a PMI, use your X.509 cert to
sign some SAML, which is well-supported and gives you what you need (and far
more than an attribute cert ever can).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 Aug 2010 15:59:15 +1200

"Bentkofsky, Michael" <[email-masked]> writes:

>Whenever I talk to people about verifying certificate status, they naturally
>believe the "Ok" is indicating not only non-revocation, but is also giving an
>indication that the certificate is "valid".

That's the experience I've had as well, that no matter what the spec says (and
we can't even get a bunch of PKI domain experts to agree on this, so it's no
surprise that end users have no idea), the effect of OCSP at the RP is "valid"
and "not valid", where OCSP status=OK is "not valid" and anything else is
"valid".

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 Aug 2010 16:13:10 +1200

I wrote:

>where OCSP status=OK is "not valid" and anything else is "valid".

Argh, sorry, obviously that should have read "status=revoked".

Peter.

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 11 Aug 2010 10:14:22 +0200

On 08/10/2010 10:21 PM, Simon Tardell wrote:
> On Tue, Aug 10, 2010 at 09:30, Tomas Gustavsson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I also think the semantics (ok, unknown, revoked) is more or less
>     domain specified, since OCSP is usually deployed in a specific
>     domain where the TP defines the boundaries of the world.
>
>
> able to define any semantics. They control the OCSP responder, but the
> OCSP clients are standard issue (the built-in clients in the platforms).
> In my experience, custom OCSP clients are rare. YMMV, of course.
>
>     In this OCSP gives much flexibility since it allows usage of
>     unknown, if the TP desires, and it can leave it out if so desired
>     (global replication of large databases is an issue for OCSP providers).
>
>
> Useage or non-usage of a feature is a flexibility, yes, but I would
> perhaps not use the same word for wringing the meaning of a vague
> wording in the specification.

I agree with this. I jsut wanted to remind us that any 
improvements/replacements have to be a bit flexible and not try to force 
the world into one single theoretical model designed by a few PKI 
experts. Any flexibility should ideally be clear in the model and not by 
twisting the semantics of course.

Cheers,
Tomas

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 11 Aug 2010 10:21:18 +0200

> for the relying parties to access the CA.

The Web server is of course an additional host to attack.

> all those responses, be used by the CA also to sign and publish

The signing performance is rarely an issue, although it can be in 
extreme cases. What I'm talking about is selecting all the revoked 
certificates to be placed in the CRLs from a huge database. Doing this 
to produce CRLs is inherently more difficult than finding a single 
certificate to make an OCSP/whatever response. Than there is also the 
issue of potentially distributing the CRLs to several locations.

I'm not saying it can't be done, but IMHO it is much more difficult and 
will faster run into scalability issues.

Cheers,
Tomas

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 11 Aug 2010 01:28:01 -0700

On Tue, 2010-08-10 at 14:45 -0700, Kyle Hamilton wrote:
> PKIX fails to meet many (and, it could be argued, even 'most') of its
> stated goals.  More "patchy protocols" have grown around PKIX than
> anything else, including HTTP (which has the 'cookie protocol' to try
> to make up for its lack of pure session support).

Cookies do some things that TLS sessions don't: they can persist for
years and be scoped to domains.  They also got to market first.  I have
a hard time blaming PKIX for not winning webmasters away from them.

> Also, PKIX's lack of prescribing minimum standards for verification
> has led to a problem where neither Penango (an in-browser S/MIME
> client with certificate verification capability) nor Qualys's SSLLabs
> Server Certificate Survey can determine from a technical standpoint
> that anything more than a domain or an email address has been
> verified.  [...]

Is it really PKIX's job as a technical working group to define OV?

> Just because I know who CA A says EE B is doesn't mean that I
> automatically grant access to B, and I don't necessarily trust A's
> assertion as to B's identity anyway.  That decision is taken out of my
> hands by the people who make browser software, and add trust by
> default to organizations that I have no knowledge of.

<tangent>
This is unfair to the browser makers.  I'll refer to Mozilla since I'm
most familiar with them.  Given current technology, they are doing the
best they can, trying to admit CAs according to a consistent set of
criteria.  They must assess the costs and benefits of recognizing more
CAs differently than you, given their broad user population.  As always,
you're welcome to remove some or all CAs.
</tangent>

> There is no reason for this, other than that PKIX fails to address the
> real problems underlying the Internet's lack-of-identity-authenticity.

> There *is* no Universal Font of Trust.

I would welcome work to design and implement system that doesn't require
a set of universally trusted public CAs.  SPKI looks like the right
approach.  In the meantime, there are benefits to using the public CA
system for all but one's most sensitive communications.

> It failed to create mutual-authentication systems that were widely
> deployed, which led to the prefix-injection attack against TLS on the
> public Internet to be exploited.

That's unfair.  TLS with server-only authentication has some significant
uses, including anonymous integrity-protected retrieval of information.
The prefix-injection attack was the result of an oversight in the design
of TLS, which was corrected in a straightforward way.

> (When -- if ever -- is the PKIX WG going to realize that the spec it
> has created has no place on the open Internet, and only has
> appropriate scope to be deployed in a particular administrative domain
> -- and thus is outside of the scope of Internet standards
> organizations?

Nonsense.  With PKIs at the organizational level, standardizing the
technology still means that each organization doesn't have to reinvent
it for themselves (possibly insecurely) and that a user can use the same
client software to interact with many organizations and have it just
work.  For that matter, HTTP is only practiced by pairs of machines at a
time.

-- 
Matt

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 11 Aug 2010 06:25:28 -0400

Tomas,

The attack on web server can at best cause denial of service since the
CRL partitions are signed.

The works off the revoked certificate database to create CRL or
partitions and OCSP works from a large CRL database.  I do not see a
performance issue both conceptually and based on experience.

> From: Tomas Gustavsson [mailto:[email-masked]]
> Sent: Wednesday, August 11, 2010 4:21 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> > always need revocation information unless certificate validity
period
Behalf
> >>> Why not just use partitioned CRL and get rid of OCSP and another
> box
> >> to
> >>> attack and another trust component and its key management to
> analyze
> >> in
> >>> Partitioned CRL asymptotically can converge to what OCSP does
given
> >> that
> >> Generating the 3000 CRLs every 2 hours does not sound like
something
> I
> >>>> Nothing is worse than 10 MB CRLs over LDAP.  But nothing,
> including
> >>>> OCSP
> >>>> and simplicity (through use of CMS) is a bit misleading.
Unsigned
> >>> data

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 11 Aug 2010 13:18:53 -0400

From: Tomas Gustavsson

> will faster run into scalability issues.

Directories are databases optimized for read access (OLAP - lots of
indexing) as opposed to write access (OLTP - minimal indexing).  When a
certificate is revoked, it should be added to a "revoked" index, and
dumping the revoked serial numbers should not be a challenge even for a
10M cert database on an average laptop running mySQL.

For scalability issues you seem to be comparing one OCSP response to an
entire CRL.  But a server is not going to produce just one OCSP
response, it will have to produce responses for all certificates that
are being validated by relying parties.  If I send a single signed
message to the PKIX list, OCSP responders around the world will light up
in order to validate it, and they will continue to do so for as long as
people read that message from the archives.  So revocation information
(not just CRLs) has to be distributed to several locations in order to
support Internet-scale use of certificates, and the scalability question
is how revocation information for all senders is made available to all
relying parties, not how a single OCSP response or a single CRL is
distributed to a single relying party.

Think in terms of an article published on wsj.com or news.yahoo.com and
read by millions.  If the article is signed or the server uses TLS, then
those millions of readers need to validate a cert.  A single 10 KB CRL
could be distributed to those millions of readers the same way the
article is distributed.  But how many OCSP responders would be needed to
service that same number of readers, and how would those responders get
their revocation info from the CA?  CRLs probably. Database replication
maybe. OCSP probably not.

Dave

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 12 Aug 2010 09:11:41 +0200

> 10M cert database on an average laptop running mySQL.

I think you overestimate the power of laptops, but lets leave that 
discussion :-)

> maybe. OCSP probably not.

I don't think this is a real world sceario, having end users do 
revocation checks, be it using CRLs or OCSP. It will just never happen, 
because it just doesn't not work. Not due to load factors, but other 
factors. Unless the revocation information is embedded in the document 
so the check can happen without disturbing the user (and the end user 
will not care about revocation anyhow imho).

In your scenario there are also many other scenarios. If the article is 
for example a PDF document, the CRL *or* the OCSP response can be 
distributed embedded in the document. Same functionality.

I think there is a use case for both CRLs and OCSP. Currently OCSP seems 
to have the upper hand, at least in my line of work. With CRLs degraded 
to special cases.

Cheers,
Tomas

---

From: Jacob Dilles <[email-masked]>
Date: Thu, 12 Aug 2010 07:52:58 -0400

> will not care about revocation anyhow imho).

It is a real world scenario. Example: The 5 million + daily end-users of www.bankofamerica.com online banking, would very much care if the server's TLS private key was compromised lest they divulge their financial information to a malicious party.

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 12 Aug 2010 14:48:16 +0200

> It is a real world scenario. Example: The 5 million + daily end-users of www.bankofamerica.com online banking, would very much care if the server's TLS private key was compromised lest they divulge…

Interesting. You learn something new every day. They use CRLs or OCSP?

Do they use a special client then? Cause I guess you can't depend on the 
end user to configure their browser to download CRLs or make OCSP 
queries. At least my firefox doesn't download any CRLs or make any OCSP 
queries when connecting to their https site.

Cheers,
Tomas

---

From: Jacob Dilles <[email-masked]>
Date: Thu, 12 Aug 2010 09:07:33 -0400

> Interesting. You learn something new every day. They use CRLs or OCSP?

Both. When I visit https://sitekey.bankofamerica.com/sas/signonSetup.do (Online banking) am presented with an EV TLS certificate with both OCSP and CRL extensions. The CRL distribution point is http://EVSecure-crl.verisign.com/EVSecure2006.crl , and the OCSP URI is http://EVSecure-ocsp.verisign.com . 

> queries when connecting to their https site.

I'm not sure what version of Firefox you are using, mine (3.6.8) checks all three certificates in the chain via OCSP. There is a setting (Advanced --> Validation --> Use OCSP) to turn it off. 

Jacob

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 12 Aug 2010 09:25:28 -0400

>because it just doesn't not work.

Demonstrably false.  *All* USAF email and web clients are all configured to check revocation on all certs, using DoD's OCSP service with fallback to CRLs fetched over HTTP.  It works well enough that people actually notice when it doesn't.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 12 Aug 2010 09:30:26 -0400

It's worth noting that to be EV compliant browsers are *required* to check revocation status on EV certificates.  In fact, if you disable revocation checking in Firefox and visit www.paypal.com you'll find that Larry the Security Cop will stay blue instead of turning green.

-- Tim

>Jacob Dilles
>Sent: Thursday, August 12, 2010 8:08 AM
>To: [email-masked]
>>> It is a real world scenario. Example: The 5 million + daily end-users
>of www.bankofamerica.com online banking, would very much care if the
>server's TLS private key was compromised lest they divulge their
>financial information to a malicious party.
>>
>Both. When I visit https://sitekey.bankofamerica.com/sas/signonSetup.do
>(Online banking) am presented with an EV TLS certificate with both OCSP
>and CRL extensions. The CRL distribution point is http://EVSecure-
>crl.verisign.com/EVSecure2006.crl , and the OCSP URI is http://EVSecure-
>ocsp.verisign.com .
>
>I'm not sure what version of Firefox you are using, mine (3.6.8) checks
>all three certificates in the chain via OCSP. There is a setting
>(Advanced --> Validation --> Use OCSP) to turn it off.
>
>Jacob
>

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 12 Aug 2010 15:43:36 +0200

That is correct. I had noticed that the certificate has both crl and 
ocsp urls in it. I enabled OCSP and it turned green. This is a fun game 
to play.

This just proves my point, there are so many different scenarios in 
actual use so if you put your chin out you will immediately be proven 
wrong :-)

Cheers,
Tomas

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 12 Aug 2010 09:47:11 -0400

-----Original Message-----
From: Tomas Gustavsson

> In your scenario there are also many other scenarios.
> If the article is for example a PDF document, the CRL
> *or* the OCSP response can be distributed embedded in
> the document. Same functionality.

Precisely!  We are in complete agreement that there are many other
scenarios.  But just as a single web page may load dozens of images, a
PDF document or web page may load non-imbedded revocation information.
Imbedding revocation info in a document means that the document must be
dynamically generated for each reader - bad.  But linking from the
document (for example via CRLDP contained in the certificate that *is*
imbedded in the document) is what I'm talking about.

> I think there is a use case for both CRLs and OCSP.
> Currently OCSP seems to have the upper hand, at least
> in my line of work. With CRLs degraded to special cases.

Because CRLs have historically been so badly deployed (10MB files,
manual user downloads, no http: DPs) OCSP does have the upper hand.  But
technically, pre-signed OCSP responses have the same semantics as
partitioned CRLs, they just take many more bytes to convey the same
information.  My contention is that if CAs would just properly partition
and publish CRLs, then applications could easily and invisibly follow
the links.  And that CRLs can perform the same function as pre-signed
OCSP, just using less bandwidth and no special-purpose infrastructure
(responders).

Dave

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 12 Aug 2010 16:22:32 +0200

> imbedded in the document) is what I'm talking about.

I'm not following you here. The producers signature, and corresponding 
OCSP response is not tied to the reader in any way. An OCSP response 
does not have to be tied to a specific consumer any more than a CRL has 
to be. These types of embedded revocation info is used to be able to 
verify documents long term, becuase you do not want the latest CRL or a 
new OCSP response. What you want to know is if the writers certificate 
was revoked when the document was signed (preferably timestamped from a 
trusted time stamp authority as well).

> OCSP, just using less bandwidth and no special-purpose infrastructure

I will read up more on CRL partitioning so I'm prepared for the future :)

---

From: Jacob Dilles <[email-masked]>
Date: Thu, 12 Aug 2010 10:45:52 -0400

> trusted time stamp authority as well).

This is beyond the scope of both the OCSP and the CRL. 

The purpose of embedding long-term verification in a PDF or any other document is to say "Alice was authorized by Bob to user her credential to sign this document as of TIMESTAMP". An OCSP response is not, and was never intended to be, a mechanism for conveying authorization data. It can not, by design as a real-time CRL, assert this statement is true - it can only say that it does (or does not) know if the certificate was revoked. The misconception that OCSP verifies whether or not a certificate is still valid led to this discussion in the first place. 

A CRL is equally inappropriate because it would require embedding every single revoked certificate to date, otherwise (10 or 20 years down the road) there is no way of knowing if a different partition of the CRL had in fact revoked the certificate. This is a serious problem with large organizations, eg. 3 million credentials revoked and re-issued every two years. The CRL attachment would overwhelmingly dominate the size of the document. 

There are ways of embedding non-reputable, cryptographically verifiable white-lists of authorized-to-sign credential holders in a PDF and other documents. CRLs, and responses from the real-time OCSP, are not among them. 

Jacob

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 12 Aug 2010 11:37:05 -0400

-----Original Message-----
From: Jacob Dilles

> The purpose of embedding long-term verification in a PDF
> or any other document is to say "Alice was authorized by
> Bob to user her credential to sign this document as of TIMESTAMP".

Perhaps you have such a use case in mind, but delegation is not the
primary purpose of signatures.  I sign my PDF timecard every week.  I'm
not authorizing anyone else, and the only thing the auditors might care
about next year is whether I signed my own document.  If my certificate
is revoked at the time of signature someone else might have forged it,
otherwise I am presumed to be responsible for the contents.

> A CRL is equally inappropriate because it would require
> embedding every single revoked certificate to date,
> otherwise (10 or 20 years down the road) there is no way
> of knowing if a different partition of the CRL had in fact
> revoked the certificate.

That is absurd.

First: one embeds serial numbers, not certificates, in a CRL.  (Assume
you meant "... listing every single revoked certificate to date".)

Second: there is only one CRL series authoritative for any given
certificate (disregard reason codes for the moment).

Assume CRL partition A covers certs 1, 2, and 3, and CRL partition B
covers certs 4, 5, and 6.  If 20 years later you want to know if cert 1
is revoked at time X, then all you need is the CRL from partition A
applicable to time X.  You don't need any of certs 2-6, and you don't
need any CRLs for partition B.  By definition a "different partition"
cannot revoke certificate 1: if that certificate is revoked then the CA
will put its serial number on Partition A CRLs and nowhere else.

Dave

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 12 Aug 2010 11:53:29 -0400

>OCSP response is not tied to the reader in any way.

...except in the simplest case where the reader doesn't grok OCSP at all.  Then your stapled response does him not one whit of good.

Recall that RFC5280 doesn't require or include RFC2560, but it *does* require implementation of CRL handling.  So a stapled CRL would work everywhere.

-- Tim

---

From: Jacob Dilles <[email-masked]>
Date: Thu, 12 Aug 2010 12:47:17 -0400

On Aug 12, 2010, at 11:37 AM, Kemp, David P. wrote:
-----Original Message-----
From: Jacob Dilles

You sign your time card.

The person who issued - and did not revoke - your certificate has authorized you to use that credential. Maybe it was the CA owner, or your boss, but someone authorized *you* to utilize *your* PKI credential. By including some sort of verification in the signed time card, you are making an assertion that this authorization is still valid, that you are authorized to use the credential - purpose of use aside.

When your credential is revoked, that same authority(/person/boss) has specifically revoked the use of your credential, that is, you are no longer authorized to authenticate with it. If you use that credential after it has been revoked, it should be disallowed. The decision to disallow is an authorization decision, not an authentication decision (the signature will still validate, or the TLS handshake will still succeed, etc..).

While responsibility for the contents of the document, the authorization to sign the document, et. al. are also authorization decisions, and are not decided by a CRL or OCSP, at a fundamental level a CRL or the OCSP is used to make an authorization decision after (cryptographic) authentication has been performed.

This was said earlier in the thread:

From: Kyle Hamilton <[email-masked]<mailto:[email-masked]>>
Date: August 10, 2010 5:45:07 PM EDT
To: "Kemp, David P." <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] Previous attempt to update OCSP

Using a credential (at all) is a privilege that the CRL extension grants, and may revoke, thus extending the scope of the PKI to authorization.

On Aug 12, 2010, at 11:37 AM, Kemp, David P. wrote:

That is absurd.

Not really.

First: CRLs in the system described above would accumulate more than 20mb of 16 byte serial numbers each year. It is not contrived, 3,018,685 CAC's have been issued according to the June numbers.

Second: Disregarding reason codes is the *only* way to avoid an indeterminate state in this case. So you would force a CA to permanently revoke every certificate, and must include an extension testifying to this behavior. Since this is not part of RFC 5280, your system is no longer a standard.

If we are coming up with an new authorization standard anyway, is there any reason whatsoever to keep CRLs and OCSP around?

Jacob

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 12 Aug 2010 10:54:10 -0700

> work.  For that matter, HTTP is only practiced by pairs of machines at a

Since (unlike most X.509) most Kerberos service is deployed at the organizational level, can I interpret this as an argument in favor of KX509?  ;-)

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 12 Aug 2010 14:02:02 -0400

In a discussion it always helps if people use the same language.   My
vocabulary derives from NIST SP800-63, which begins with: 

"Electronic authentication (E-authentication) is the process of
establishing confidence in user identities electronically presented to
an information system."

While you can claim that an identity provider "authorizes" a user to
make use of credentials and revocation status information in order to
perform authentication, that is not the sense in which authorization is
normally used.   As a practical matter it is impossible to authenticate
identities without some basic knowledge of privileges  - if every user
with a PKI certificate were permitted to act as a CA the PKI would not
be useful.  X.509 is not a "voting" identity infrastructure, and even
PGP recognizes "keyserver" as an entity with unique privileges.  Those
basic privileges - being accepted by relying parties as an identity
credential issuer or status provider - are generally regarded as being
intrinsic to the PKI itself, and not PMI-related authorizations.

Dave

From: Jacob Dilles [mailto:[email-masked]] 
Sent: Thursday, August 12, 2010 12:47 PM
To: Kemp, David P.; [email-masked]
Subject: Re: [pkix] Previous attempt to update OCSP

	-----Original Message-----
	From: Jacob Dilles

		Bob to user her credential to sign this document as of
TIMESTAMP".

	Perhaps you have such a use case in mind, but delegation is not
the
	primary purpose of signatures.  I sign my PDF timecard every
week.  I'm
	not authorizing anyone else, and the only thing the auditors
might care
	about next year is whether I signed my own document.  If my
certificate
	is revoked at the time of signature someone else might have
forged it,
	otherwise I am presumed to be responsible for the contents.

You sign your time card. 

The person who issued - and did not revoke - your certificate has
authorized you to use that credential. Maybe it was the CA owner, or
your boss, but someone authorized *you* to utilize *your* PKI
credential. By including some sort of verification in the signed time
card, you are making an assertion that this authorization is still
valid, that you are authorized to use the credential - purpose of use
aside. 

When your credential is revoked, that same authority(/person/boss) has
specifically revoked the use of your credential, that is, you are no
longer authorized to authenticate with it. If you use that credential
after it has been revoked, it should be disallowed. The decision to
disallow is an authorization decision, not an authentication decision
(the signature will still validate, or the TLS handshake will still
succeed, etc..).

While responsibility for the contents of the document, the authorization
to sign the document, et. al. are also authorization decisions, and are
not decided by a CRL or OCSP, at a fundamental level a CRL or the OCSP
is used to make an authorization decision after (cryptographic)
authentication has been performed. 

 

	From: Kyle Hamilton <[email-masked]>

	To: "Kemp, David P." <[email-masked]>

	Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>

	In fact: X.509 is primarily about an identity infrastructure.
The PKI must exist before the Privilege Management Infrastructure, but
the PKI is NOT any kind of PMI.  Until the PMI is defined -- which is
exceptionally out-of-scope for the IETF -- no privileges should be able
to be granted due to flags set by a CA on a particular certificate.

Using a credential (at all) is a privilege that the CRL extension
grants, and may revoke, thus extending the scope of the PKI to
authorization. 

That is absurd.

 

Not really.

First: CRLs in the system described above would accumulate more than
20mb of 16 byte serial numbers each year. It is not contrived, 3,018,685
CAC's have been issued according to the June numbers. 

Second: Disregarding reason codes is the *only* way to avoid an
indeterminate state in this case. So you would force a CA to permanently
revoke every certificate, and must include an extension testifying to
this behavior. Since this is not part of RFC 5280, your system is no
longer a standard.

If we are coming up with an new authorization standard anyway, is there
any reason whatsoever to keep CRLs and OCSP around? 

Jacob

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 12 Aug 2010 11:03:48 -0700

Agreed.

For "ordinary users" checking a random server cert, OCSP is better.  For a service checking a client cert a CRL is better because then the service doesn't die, or slow down, if the OCSP service has a problem.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Aug 2010 15:14:21 -0400

>...
>
>While responsibility for the contents of the document, the 
>authorization to sign the document, et. al. are also authorization 
>decisions, and are not decided by a CRL or OCSP, at a fundamental 
>level a CRL or the OCSP is used to make an authorization decision 
>after (cryptographic) authentication has been performed.

A CRL or OCSP response is a statement about the revocation status of 
a PKC, period. One may argue that revoking a credential implicitly 
revokes the ability to use that credential as an (authentication) 
input to an access control (authorization) decision. But, that is not 
quite what you said above. A cert is not valid unless it passes all 
of the cert path validation checks, including revocation status 
checks.

Steve

---

From: Jacob Dilles <[email-masked]>
Date: Thu, 12 Aug 2010 16:02:56 -0400

On Aug 12, 2010, at 2:02 PM, Kemp, David P. wrote:

In a discussion it always helps if people use the same language.   My vocabulary derives from NIST SP800-63, which begins with:

“Electronic authentication (E-authentication) is the process of establishing confidence in user identities electronically presented to an information system.”

I agree that common language is essential, and in the same pursuit I believe we went through this (from a slightly different angle) six months ago (18MAR10 "Re: [pkix] Authorization: was RE: Proposal for matching uniform resource identifiers with regular expressions in certificates") during another long and off-topic thread. We ended up agreeing with the definition for authorization from RFC 4949 (page 28):

$ authorization

      1a. (I) An approval that is granted to a system entity to access a
      system resource. (Compare: permission, privilege.)

      1b. (I) A process for granting approval to a system entity to
      access a system resource.

I don't believe the two definitions contradict: The PKI is responsible for authentication, which it performs by (cryptographically) demonstrating a high statistical probability that the user at the other end was issued a private key corresponding to the presented public key.

Full stop.

This is where the NIST, and any other, definition of authentication ends.

 As a practical matter it is impossible to authenticate identities without some basic knowledge of privileges

Rubbish - The very nature of AIA OCSP and CRLDistributionPoints as non-critical extensions means that they are not necessary to perform authentication. Whatever they are used for must be a form of authorization once the basic, mathematical, authentication has taken place. A serial number in a CRL or a signed OCSP response have no bearing on the mechanics of the public key verification. This is true for all practical methods of AuthN/AuthZ.

Take the simplest username/password authentication for instance. The username holds no indication whatsoever of privilege. Any username/password authenticated system takes two steps when a user logs in, first hashing (hopefully ;-) the password and verifying that it matches in the database. Then, it looks up what that person is allowed to do in a table that associates username to privilege.  Providing a username that is not in the database has the same result as failure to provide the correct password for a username that is in the database - authentication failure.

Introduce some complexity, say Microsoft's Active Directory. Again, two discrete steps whereby first the user is authenticated ("AuthenticatedUser" group), then their privileges/groups/roles are looked up. Again, providing a bogus username results in the same error as registered user typing in the wrong password. This error does not indicate that you are unauthorized to access the system, only that the system can't make out who you really are.

Similarly, there are ways to independently, and securely, provide authorization information after the PKI has authenticated a user. As it stands though, there is no official way for an application to tell between a broken (corrupt) certificate and revoked certificate - anything that has passed PKITS only knows "yes" and "no" - as you say,

Those basic privileges - being accepted by relying parties as an identity credential issuer or status provider – are generally regarded as being intrinsic to the PKI itself, and not PMI-related authorizations.

We have, historically, abused the system to provide authorization information within the PKI's authentication mechanism. Unfortunately these hacks were never fixed, and are now are so deeply embedded in the standards and implementations that they will never be removed. Regardless, we can, and should, focus on an legitimate, scalable, authorization solution equivalent in elegance to the PKI.

This may be an unpopular position here, and I suppose the moral of the story is "when in Rome, do as the Romans do." I just hope when looking to the future we can say "just because everyone is doing it doesn't make it right."

Jacob

---

From: Tom Gindin <[email-masked]>
Date: Thu, 12 Aug 2010 21:20:48 -0400

Jacob:

        I think we may have a disagreement about the proper form of CRL 
partitioning.  The form which makes this feasible is when your CRL 
Distribution Point extension contains a distributionPointName and no 
reason flags (crlIssuer is not relevant), and in which the 
distributionPointName is a URL.  It is also necessary for the CA to 
allocate a new distributionPointName after each N certificates, where N is 
not more than a few thousands.
        I don't see how keyCompromise is an authorization decision.  It 
asserts that the certificate is no longer valid as identification because 
the private key is available to at least one other entity.
        By the way, if you want a clear indicator of whether a given CRL 
keeps entries for expired certificates, why not propose an CRL extension 
(not a CRL entry extension) to allow a CA to do so (CRLKeepsExpired)?  I 
don't think that any value syntax beyond ReasonFlags is useful for such a 
thing.  X.509 (at least v4) says that expired certificates may be removed 
from a CRL, but it doesn't say they must.  5280 certainly suggests that 
they should, but I don't see a requirement that they must.  For 
non-partitioned CRL's, the resulting CRL's would be unworkably large - but 
not for partitioned ones.

                Tom Gindin

From:
Jacob Dilles <[email-masked]>
To:
"Kemp, David P." <[email-masked]>, "[email-masked]" <[email-masked]>
Date:
08/12/2010 12:48 PM
Subject:
Re: [pkix] Previous attempt to update OCSP
Sent by:
[email-masked]

-----Original Message-----
From: Jacob Dilles

You sign your time card. 

The person who issued - and did not revoke - your certificate has 
authorized you to use that credential. Maybe it was the CA owner, or your 
boss, but someone authorized *you* to utilize *your* PKI credential. By 
including some sort of verification in the signed time card, you are 
making an assertion that this authorization is still valid, that you are 
authorized to use the credential - purpose of use aside. 

When your credential is revoked, that same authority(/person/boss) has 
specifically revoked the use of your credential, that is, you are no 
longer authorized to authenticate with it. If you use that credential 
after it has been revoked, it should be disallowed. The decision to 
disallow is an authorization decision, not an authentication decision (the 
signature will still validate, or the TLS handshake will still succeed, 
etc..).

While responsibility for the contents of the document, the authorization 
to sign the document, et. al. are also authorization decisions, and are 
not decided by a CRL or OCSP, at a fundamental level a CRL or the OCSP is 
used to make an authorization decision after (cryptographic) 
authentication has been performed. 

Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

In fact: X.509 is primarily about an identity infrastructure.  The PKI 
must exist before the Privilege Management Infrastructure, but the PKI is 
NOT any kind of PMI.  Until the PMI is defined -- which is exceptionally 
out-of-scope for the IETF -- no privileges should be able to be granted 
due to flags set by a CA on a particular certificate.

Using a credential (at all) is a privilege that the CRL extension grants, 
and may revoke, thus extending the scope of the PKI to authorization. 

That is absurd.

Not really.

First: CRLs in the system described above would accumulate more than 20mb 
of 16 byte serial numbers each year. It is not contrived, 3,018,685 CAC's 
have been issued according to the June numbers. 

Second: Disregarding reason codes is the *only* way to avoid an 
indeterminate state in this case. So you would force a CA to permanently 
revoke every certificate, and must include an extension testifying to this 
behavior. Since this is not part of RFC 5280, your system is no longer a 
standard.

Jacob

---

From: [email-masked]
Date: Thu, 12 Aug 2010 18:45:14 -0700 (PST)

On Thu, Aug 12, 2010 at 5:48 AM, Tomas Gustavsson <[email-masked]> wrote:
> Do they use a special client then? Cause I guess you can't depend on the end
> user to configure their browser to download CRLs or make OCSP queries. At
> least my firefox doesn't download any CRLs or make any OCSP queries when
> connecting to their https site.

Firefox is slated to begin requiring OCSP at the time that the CA/B Forum has mandated that it be provided for EV certificates: December 31, 2010.  NSS has had the ability to perform OCSP checking forever, but it's always been an about:config bit: security.ocsp.* are the settings in Firefox.

-Kyle H

---

From: [email-masked]
Date: Thu, 12 Aug 2010 18:47:47 -0700 (PST)

If you have an OCSP response from just after the signing operation that you staple into the document after you generate the hash of the doc and sign it, and get the timestamping authority reply to countersign the time it was signed...

then yes.

But not in the case of a lack of timestamping.

-Kyle H

---

From: [email-masked]
Date: Thu, 12 Aug 2010 20:13:27 -0700 (PST)

...so, in X.509 (and PKIX), why is there no separate concept of CRL for 'privilegeRevoked' instead of 'keyCompromise'?  Yes, partitioned CRLs are supposed to allow for this, but there are too many use cases where partitioned CRLs are not at all okay, and CRL has a connotation associated with 'revocation' (i.e., in the 'authentication' phase), instead of being processed during the 'authorization' phase.

-Kyle H

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 13 Aug 2010 16:00:23 +1200

Jacob Dilles <[email-masked]> writes:

>It is a real world scenario. Example: The 5 million + daily end-users of
>www.bankofamerica.com online banking, would very much care if the server's
>TLS private key was compromised lest they divulge their financial information
>to a malicious party.

Since Bank of America until quite recently didn't bother protecting the page
where users are expected to enter their credentials with anything more
substantial than a GIF of a padlock, I don't think this is a particularly good
example to use...

(I've just checked now and they finally use HTTPS on their home page, and
redirect HTTP to HTTPS.  That only took them, what, about ten years to get
right?

Hmm, and Wachovia do it too.  And Citibank at least redirect you to an HTTPS
page.  And so does US Bank, after asking for your ID.  What on earth happened?
Was there a change in banking regulations in the last few months?).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 13 Aug 2010 16:19:34 +1200

"Miller, Timothy J." <[email-masked]> writes:

>Demonstrably false.  *All* USAF email and web clients are all configured to
>check revocation on all certs, using DoD's OCSP service with fallback to CRLs
>fetched over HTTP.  It works well enough that people actually notice when it
>doesn't.

You missed the qualification of "real world sceario" above.  The DoD PKI is
not even close to a real-world scenario, being entirely removed from any
practical market constraints, it's more a demonstration of the old saw that
given sufficient thrust, pigs can indeed fly.  You'd need to provide examples
of CRLS and OCSP working fine in a heterogeneous PKI [0] in a nontrivial
standard commercial environment that has to conform to real-world market
constraints.

Peter.

[0] So saying "$bigcorp has managed to get it to work in their pet PKI"
    doesn't count, it has to fulfil the requirements listed above.  Think
    of the deployment base of, say, Oracle and give me an example of it
    working across that range of environments.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 12 Aug 2010 22:27:13 -0700

On Thu, 2010-08-12 at 10:54 -0700, Henry B. Hotz wrote:
> Since (unlike most X.509) most Kerberos service is deployed at the
> organizational level, can I interpret this as an argument in favor of
> KX509?  ;-)

Not really.  The point was that organization-level security realms are
useful.  If Kerberos is currently deployed more commonly than X.509 at
that level, that does not necessarily mean it is better.

-- 
Matt

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 13 Aug 2010 08:11:50 +0200

> standard commercial environment that has to conform to real-world market

Agree 100%.  $200+ card readers is another example of how far away from
the market DoD is:

http://na.blackberry.com/eng/ataglance/security/products/smartcardreader/

It is obvious that phones will be at the core of client-side PKI but this
scheme isn't going to make it happen.

Anders

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 13 Aug 2010 07:22:47 -0400

Peter,

I am NOT speaking for DoD.

But, you could not be more wrong.

DoD PKI has to produce revocation information that can be consumed by a
wide variety of COTS products.

> Sent: Friday, August 13, 2010 12:20 AM
> To: [email-masked]; [email-masked]; [email-masked]

---

From: "Bentkofsky, Michael" <[email-masked]>
Date: Fri, 13 Aug 2010 07:37:25 -0400

Peter,

I am reading these replies to suggest that OCSP is just not used in the "real world" and in fact revocation checking is not really used. Since the B of A example is citing a Verisign issued certificate I can say quite definitively OCSP checking is done in SSL in the real world very frequently, to the tune of over 2 billion OCSP requests per day with respect to Verisign issued certs with an AIA tag. The real world examples I see include Gmail account access, code signing cert revocation checking on automated software installs, as well as the cited financial institutions and online merchants that protect their sites using SSL. 

All major browsers use OCSP checking during SSL session establishment and will disallow a connection to a revoked site. As for why businesses use SSL more lately, I believe it is a calculation of risk in the light of some notable attacks on formerly acceptable techniques and the increased functionality of sites making attacks more valuable.

Michael

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Fri Aug 13 00:00:23 2010
Subject: Re: [pkix] Previous attempt to update OCSP

Peter.

---

From: "Al Arsenault" <[email-masked]>
Date: Fri, 13 Aug 2010 07:44:22 -0400

Peter

Please define your terms. Is this equivalent to saying "Verisign/Symantec
doesn't do it, so it won't work. QED?"

After all, you've said the example can't be the US DoD, or any other
Government PKI, and it can't be a company's PKI.  What's left?

If it's been demonstrated to work in a global environment, with hundreds of
thousands to millions of clients, with every major commercial product and a
wide variety of open source products, that still doesn't count?

		Al Arsenault

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 12:20 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] Previous attempt to update OCSP

given sufficient thrust, pigs can indeed fly.  You'd need to provide
examples

Peter.

---

From: "Al Arsenault" <[email-masked]>
Date: Fri, 13 Aug 2010 07:52:57 -0400

What the heck are you talking about? A prior employer deployed a phone-based
PKI with revocation checking in 2002 - see, e.g.
http://www.thefreelibrary.com/Diversinet,+Ericsson,+Gemplus,+Hewlett-Packard
,+Hongkong+Post+and...-a084992195

(It didn't go very far because WAP was a truly ugly solution, but we won't
go there for now...:-)

Nobody I know uses a $200 smart card reader, DoD or otherwise, and the idea
of using your phone as the token to store your keys and credentials has been
around since at least 2002, as well. The Blackberry gadget's interesting,
but looks more like a toy than anything else.

		Al Arsenault

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 2:12 AM
To: Peter Gutmann
Cc: [email-masked]
Subject: Re: [pkix] Previous attempt to update OCSP

examples

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 13 Aug 2010 23:54:37 +1200

"Santosh Chokhani" <[email-masked]> writes:

>DoD PKI has to produce revocation information that can be consumed by a wide
>variety of COTS products.

... all configured by/for, and controlled by, a single central organisation, 
and at a cost that runs into the billions of dollars (Information Security 
Magazine described it as a billion dollar boondoggle in 2004 based on GAO 
figures, and I assume it hasn't got any cheaper since then).  This is not even 
remotely close to commercial reality and conforming to real-world market 
constraints, which I made a point of in my original message.

Give me several *billion* dollars and centralised control over the deployment
and I can prove that PKI, or CRLs, or homing pigeons, or trained monkeys, or
ouija boards, or anything you want really, can "work" too.

The DoD PKI is not proof that PKI is practical or effective, merely proof 
that, given sufficient thrust, pigs can indeed fly.  I think every time 
someone yet again drags out the DoD/Federal PKI as "proof" of anything, they 
should be required to end any statement made with "and it only required 
centralised control by one organistion and merely cost us a few billion 
dollars to achieve it!" to put the claim(s) made into the proper perspective.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 14 Aug 2010 00:06:14 +1200

"Bentkofsky, Michael" <[email-masked]> writes:

>I am reading these replies to suggest that OCSP is just not used in the "real
>world" and in fact revocation checking is not really used.

Oh no, my gripe was just with the repeated use of the Federal/DoD PKI as
"proof" of anything (or at least proof of anything positive :-).

Peter.

---

From: "Al Arsenault" <[email-masked]>
Date: Fri, 13 Aug 2010 08:09:47 -0400

Okay, I'll ask again - what's your point?

What, specifically, will you accept as "proof" that revocation checking is
used in the real world? 

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 8:06 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [pkix] Previous attempt to update OCSP

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 13 Aug 2010 09:30:52 -0400

>Agree 100%.  $200+ card readers is another example of how far away from

Now now. You missed the *best* example of divorce from market forces:

http://www.gdc4s.com/documents/Sectera_Edge_Price_List_July_2008.pdf

But then I'd counter with the "unique requirements" saw, and we'd be off to the races.  :)

While I'm sympathetic to phone-as-cryptotoken, there are still problems that go beyond keygen, particularly re: externally verifiable execution.  This appears to be solvable, but it's not simple and the infrastructure doesn't exist.  Plus, the DoD (and the Fed at large) doesn't look like it wants to separate the logical credential from the physical credential any time soon--CACs and PIVs are identity cards as much as they are PKI smartcards.

That said, in re: Peter's challenge, I think FF has done well implementing the EV-mandated revocation check, and that's worked across the general population.  If that doesn't satisfy as 'real world' than nothing will.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 13 Aug 2010 09:34:34 -0400

If you want to use a *smartcard* with your phone, your options are limited.  There's an old sled for some discontinued BBs, but the rest are either tethered readers (not exactly a successful form-factor) or Bluetooth readers similar to the RIM device.

Add to that Bluetooth's joke they call session security, and you end up with a challenging engineering problem.

-- Tim

>Sent: Friday, August 13, 2010 6:53 AM
>To: 'Anders Rundgren'; 'Peter Gutmann'
>Cc: [email-masked]
>>> Demonstrably false.  *All* USAF email and web clients are all
>configured
>to
>>> check revocation on all certs, using DoD's OCSP service with fallback
>to
>CRLs
>>> fetched over HTTP.  It works well enough that people actually notice
>when
>it
>>> doesn't.
>>
>> You missed the qualification of "real world sceario" above.  The DoD
>PKI
>is

---

From: Jacob Dilles <[email-masked]>
Date: Fri, 13 Aug 2010 09:35:28 -0400

>        Jacob:

Tom,

> partitioning.  

Where is the disagreement? 

>From a theoretical standpoint, according to the definition of authentication the number of persons (whom have access to a private key) is irrelevant in the process of authenticating said key. A revocation check does not affect the cryptographic elements of PK verification. If authentication can be performed without it, and it does not add any additional assurance to that authentication, I don't see how it could not be considered an authorization decision. From the beginning the CRL was a solution to the issue of what happens when the authority decides that it no longer wishes for a user to use their credential == authority decides == authorization decision. 

>From an empirical standpoint, Kyle hit the nail on the head:

On Aug 12, 2010, at 11:13 PM, <[email-masked]> <[email-masked]> wrote:

> why is there no separate concept of CRL for 'privilegeRevoked' instead of 'keyCompromise'

Because they are both authorization statements. 

That is not to say that a revocation check is undesirable or unnecessary, it is only with proper authorization that a credential becomes useable in the real world. While CRL's are significantly better than nothing, they have several major and fundamental flaws (eg. low propagation speed, difficulty in distribution and caching, poor immunity to denial-of-service attacks, large binary size and bandwidth usage or thousands of smaller pieces floating about, inability to prevent use of a forged certificate, to name only a few) and almost anything is better than a CRL. 

In my opinion, the most prudent way to deal with the scalability (300 million? 6 billion?) requirements looming on the horizon is to (1) acknowledge that the revocation check is a authorization decision and (2) standardize the separation of that decision from the authentication process. Since the WG can not recant CRLs (after all, they have been engrained in the standard for over a decade) and thus will never agree with this preemptively, there's really nothing else to do but wait to see what happens in the industry. 

> (not a CRL entry extension) to allow a CA to do so (CRLKeepsExpired)?  

No, thanks - I'm not going to waste my time patching a patch.

If a draft comes forward offering an extensible authorization infrastructure complementary to the PKI which can obsolete CRLs I will support it fully. At the moment, I don't have the time or the masochistic tendencies to frame such a draft myself. 

Jacob

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 13 Aug 2010 09:36:03 -0400

>... all configured by/for, and controlled by, a single central organisation,

Not so.  DoD PKI relying parties are scattered throughout commercial and civilian environments.

-- Tim

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 13 Aug 2010 09:45:48 -0400

> (not a CRL entry extension) to allow a CA to do so (CRLKeepsExpired)?

There's no need to propose a new extension, since one has already been 
defined in X.509 (expiredCertsOnCRL):

     This CRL extension field indicates that the CRL includes revocation 
notices for expired certificates.

     expiredCertsOnCRL EXTENSION ::= {
        SYNTAX ExpiredCertsOnCRL
        IDENTIFIED BY id-ce-expiredCertsOnCRL }

     ExpiredCertsOnCRL ::= GeneralizedTime

     This extension is always non-critical.

When this extension is present, it indicates that the scope of the CRL 
is extended to cover all certificates (that are otherwise within the 
scope of the CRL) that expired at or after the time specified in the 
extension.  There is a limitation imposed that the revocation status of 
a certificate cannot be updated once the certificate has expired.

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 14 Aug 2010 02:07:11 +1200

>Not so.  DoD PKI relying parties are scattered throughout commercial and

But the DoD sets the exact requirements that they have to conform to, which
includes specifying exactly what the software has to do.  There may not be a
guy in olive drab standing over each PKI-using device or system, but they're
there by one level of indirection.

I've talked to a number of developers who've worked on PKI software for USG 
use, and some of them have put in massive amounts of effort (6-12 month 
efforts by entire development teams) to get their code to do what the DoD PKI 
required.  This isn't even remotely representative of commercial reality, what 
other customer could go to a commercial vendor and in effect tell them "here 
are our requirements, drop any other work and spend the next year customising 
your product to meet them".

And to emphasise this point again, this isn't about revocation checking -
although as I pointed out in my previous message with the declared-revoked-
but-not-really-revoked malware cert the state of revocation checking isn't so
hot either, there's a big difference between "we've declared it revoked and
published a CRL" and "RPs are being effectively protected by the revocation
mechanism" - but the claim that the DoD PKI is representative of real-world
use.

Actually here's a challenge: I have some particularly vicious malware (once 
this is running it's reformat-and-reinstall time, and hope you didn't have 
anything sensitive on your machine before it ran since some of the plugins 
scan for and exfiltrate sensitive data) that's been signed by a cert that was 
revoked a full month ago.  I will offer to send this to anyone on the list who 
promises to disable all anti-virus checking and similar protection on their 
day-to-day-use PC (lets's say their own personal laptop or their home PC), 
plug it into an open network (to allow the malware to exfiltrate their data if 
it gets to run, i.e. you can't cheat and run it in a VM or some 
specially-set-up test environment) and then run the malware, trusting in the 
revocation check of the cert it's signed with to protect them.

Any takers?

Peter.

---

From: Tom Gindin <[email-masked]>
Date: Fri, 13 Aug 2010 10:10:59 -0400

Kyle:

        There is a value for CRLReason called "privilegeWithdrawn" (see 
RFC 5280 5.3.1), which was intended mainly as a reason code for Attribute 
Certificates, and didn't even exist in RFC 2459.  My copy of X.509v4 says 
that it can be used for Public Key Certificates as well.  Are you 
objecting to the word "Withdrawn" instead of "Revoked" in its label?
        To the extent that authentication and authorization can be 
separated, Public Key Certificates are more appropriate for authentication 
than for authorization.  The latter is why Attribute Certificates are 
defined.

                Tom Gindin

From:
[email-masked]
To:
Tom Gindin/Watson/IBM@IBMUS
Cc:
"Jacob Dilles" <[email-masked]>, "[email-masked]" <[email-masked]>, 
"Kemp, David P." <[email-masked]>
Date:
08/12/2010 11:13 PM
Subject:
Re: [pkix] Previous attempt to update OCSP

...so, in X.509 (and PKIX), why is there no separate concept of CRL for 
'privilegeRevoked' instead of 'keyCompromise'?  Yes, partitioned CRLs are 
supposed to allow for this, but there are too many use cases where 
partitioned CRLs are not at all okay, and CRL has a connotation associated 
with 'revocation' (i.e., in the 'authentication' phase), instead of being 
processed during the 'authorization' phase.

-Kyle H

> authorized you to use that credential. Maybe it was the CA owner, or 
your
> disallow is an authorization decision, not an authentication decision 
(the
is
> Using a credential (at all) is a privilege that the CRL extension 
grants,
> First: CRLs in the system described above would accumulate more than 
20mb
this

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 13 Aug 2010 10:54:44 -0400

Code signing has its own peculiar twist on validation that I'm personally not convinced is correct on the face of it, so color me unsurprised if system developers did it badly.  I'm don't think that this specific case is enough to call revocation in general a failed technology.

-- Tim

>Sent: Friday, August 13, 2010 9:07 AM
>To: [email-masked]; [email-masked]; [email-masked];
>Miller, Timothy J.; [email-masked]
>Subject: RE: [pkix] Previous attempt to update OCSP
>
>>Not so.  DoD PKI relying parties are scattered throughout commercial
>and
>>civilian environments.
>

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 13 Aug 2010 17:16:40 +0200

Miller, Timothy J. wrote:
> Code signing has its own peculiar twist on validation

Right on.

I just found out that checking expiration time has been
deleted from recent releases of Java since it became a problem that
code ceased to work :-)

Anders

that I'm personally not convinced is correct on the face of it, so color me unsurprised if system developers did it badly.  I'm don't think that this specific case is enough to call revocation in 
general a failed technology.

---

From: Jacob Dilles <[email-masked]>
Date: Fri, 13 Aug 2010 12:06:29 -0400

Tom,

I'm not Kyle, however

On Aug 13, 2010, at 10:10 AM, Tom Gindin wrote:

> Are you objecting to the word "Withdrawn" instead of
> "Revoked" in its label?

I was highlighting the word "privilege" as it is synonymous with "authorization" here.

> than for authorization.  The latter is why Attribute Certificates are 

RFC 5755 came close and is certainly on the right track, but is not mature enough to supplement (let alone obsolete) the CRL for authentication certificates because:
(1) It is still user-centric (as opposed to attribute/role-centric) so you'd need a one-to-one mapping to an authentication certificate, which doubles complexity and creates
(2) The chicken vs. egg problem of who revokes/makes authorization decisions about the ACs (since they use CRLs)

At a minimum, a (a) multi-user, (b) fixed validity, (c) non-revokable, and (d) attribute-centric attribute certificate is required for it to have real-world value. Such a standard has not been defined. 

If it were, one of the applications of an attribute-centric AC would be a drop-in replacement for the CRL to provide revocation authorization, which could form the basis for a corresponding, real time, certificate validity responder service that could legitimately assert to a client that "this certificate is valid."

Jacob

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 14 Aug 2010 07:47:27 -0400

Peter,

What specifically in the US Federal or DoD PKI you see that does things
that commercial deployment of PKI should not do?

Do not pontificate and generalize, be specific.

I have seen you other posts and they do not provide anything specific
and are not helpful.  I would expect you to say that the PKI you are
criticizing does X which makes it insecure for reason Y or X is not
standard compliant or X is not supported by COTS.

As others already mentioned, these PKIs are sensitive to the needs of
heterogeneous commercial products that consume PKI objects such as
certificates, CRLs, and OCSP responses.  To my knowledge, they go to
great lengths to ensure that secure, interoperability is achieved for a
multitude of commercial products.  

> Sent: Friday, August 13, 2010 7:55 AM
> To: [email-masked]; [email-masked]; Santosh Chokhani;
> [email-masked]; [email-masked]
> someone yet again drags out the DoD/Federal PKI as "proof" of
anything,
> they

---

From: Yoav Nir <[email-masked]>
Date: Sat, 14 Aug 2010 16:42:15 +0300

I think what Peter is saying, is that the DoD spends a huge amount of time and money to get the PKI working.

The usual business is too cheap (sorry, "too focused on minimizing cost to enhance shareholder value") to spend that much.

On Aug 14, 2010, at 2:47 PM, Santosh Chokhani wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 14 Aug 2010 18:04:15 +0200

> I think what Peter is saying, is that the DoD spends a huge amount of time and money to get the PKI working.

I think he also meant that vendors have gone an extra mile or two get a part of that gold,
otherwise the DoD would probably have had to settle for something considerably
less advanced in order to get their PKI running.

Now, the funny thing is that in spite of those extravagant expenditures, they have
no working (=affordable and useful) plan for putting their PKI in mobile phones.

Although the DoD (and even more their allies...) probably (violently) object to the
following, I believe this *may* be fairly close to what they will *eventually* get:

http://webpki.org/auth-token-4-the-cloud.html

Before you dismiss this project, you shouldn't forget that this is (currently) the
only show in town :-)

It will surely take a couple years to complete but that's like a second in the world of PKI :-)

If take a peek in the documents and links you will note that the project spans from
low-level Crypto, Electronics, USB communication, Middleware, new PKI protocols,
OTP, Information Cards, Web Signatures, to enhanced Browser integration and
User experience concepts.

That is, IMO you *have to* do it all in one (hell-of-a) piece if you want to achieve something
that actually *interoperates*.  Not even a billion dollar for running like five separate
standardization efforts powered by dozens of fierce competitors would help.  Its that hard.

This very "humble" mission also intends to be the catalyst that finally transforms mobile
phones into useful payment devices since the financial sector haven't presented a tangible
roadmap for getting payment credentials on-board in phones.  I believe that the historical
separation of authentication and payment technologies have proved to be quite contra-productive.

There are currently no plans making this a formal standard; this is an Open Source +
Open Hardware initiative that is based on "iterations" and dynamic updates, which is
another reason for bringing in the whole package. Otherwise you typically get stuck
because you hit a limit nobody else had noticed before.  This is about how Apple and
Google operate today so it simply can't be wrong ;)

I don't see why it couldn't even be powering (parts of) the following:

http://www.whitehouse.gov/blog/2010/06/25/national-strategy-trusted-identities-cyberspace

Given the huge US budget deficit, cheap should be an "in-thing" :-)

Regards
Anders

---

From: "C.J. Adams-Collier KF7BMP" <[email-masked]>
Date: Sat, 14 Aug 2010 13:06:03 -0700

Wow.  This list is pretty active.  I don't have time to follow all of
the threads, but this one is interesting.

Thi (CC'd) and I have been talking about adding keyserver and x.509
support to APK.  I haven't had time, what with GSoC, the move, and the
summer.  I'm putting up a PKI server at pki.colliertech.org using COTS
Debian software.  It should be sufficient to a perform the role of
repository as defined in 19.34.410 / 434-180-420 soon.  We're aiming for
2011/01/01.  As I stated earlier on the list, I completed a test for
certification as ca operative personnel.  The director of the
corporations division let me know that I have passed that bar.  We now
need an audit run (please let me know if you know anyone qualified) and
to complete the paperwork for the $50,000 bond.

My question to those of you who are still reading is this: Do you think
that the above framework would meet the requirements as outlined in the
thread below?  I'd be happy to discuss the implementations and
limitations of the PKI infrastructure as shipped in the upcoming release
of Debian.

Cheers,

C.J.

---

From: "Todd E. Johnson" <[email-masked]>
Date: Sun, 15 Aug 2010 09:27:21 -0400

I'm game.  Send it across. :)

-- 

Regards,

Todd E. Johnson

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 16 Aug 2010 03:45:28 +1200

Yoav Nir <[email-masked]> writes:

>If an OCSP responder gets a request for a non-existant certificate, it is a
>sure indication that something is wrong, and should be investigated (by
>humans), although I guess OCSP requests can be easily forged, no?

It depends, if it's a request for a cert based on a SHA-1 fingerprint then
this is indeed a good policy, but with OCSP's weird indentifiers where you
take a bit of this and a bit of that, hash some bits, don't hash others, and
then send them to the server, getting a pile of requests for non-existent
certs is more likely because client and server don't agree over generating
IDs.

(I guess it's more or less resolved now until another new implementation comes
along, but when OCSP was first being implemented there were quiet a few
problems with two sides disagreeing on identifiers, and in some cases things
were put into production because the blacklist-based checking meant that a
failure was totally silent, you never got a 'revoked' response back so things
appeared to work even though they weren't working.  There may well be
implementations out there today that still do this, but you can't really
tell).

Peter.

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 16 Aug 2010 09:33:06 +0200

> Recall that RFC5280 doesn't require or include RFC2560, but it *does* require implementation of CRL handling.  So a stapled CRL would work everywhere.

That is just not true. Verification of say PDF digital signatures is not 
specified in RFC5280, it's a specification of it's own (perhaps the case 
of PDF signatures is not considered an open standard, but lets leave 
that aside here). This specification will define what processing will be 
done or not. Saying that a stapled CRL would work everywhere is bolloks. 
If the signature specification does not mandate stapling of CRLs, or 
processing them, it's just up to the implementation. And if the 
signature standard mandates it either CRL or OCSP would work equally 
well, if specified in the signature specification.

Claiming that all signature verifying software always follows the 
RFC5280 "Certification Path Validation" algorithm is truly a bold 
statement :-)

Cheers,
Tomas

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Mon, 16 Aug 2010 13:38:04 +0300

On 8/16/2010 10:33 AM, Tomas Gustavsson wrote:
>> ...except in the simplest case where the reader doesn't grok OCSP at 
>> all.  Then your stapled response does him not one whit of good.
>>
>> Recall that RFC5280 doesn't require or include RFC2560, but it *does* 
>> require implementation of CRL handling.  So a stapled CRL would work 
>> everywhere.
>>
>> -- Tim
>
> That is just not true. Verification of say PDF digital signatures is 
> not specified in RFC5280, it's a specification of it's own (perhaps 
> the case of PDF signatures is not considered an open standard, but 
> lets leave that aside here). This specification will define what 
> processing will be done or not. Saying that a stapled CRL would work 
> everywhere is bolloks. If the signature 
well, how about PAdES, isn't it an open standard?

M.D.

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 16 Aug 2010 12:49:01 +0200

> well, how about PAdES, isn't it an open standard?

I guess so, I can download the spec from ETSI for free it seems. But I'm 
not sure about the signature spec from Adobe?

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 16 Aug 2010 12:52:25 +0200

> not sure about the signature spec from Adobe?

I just took a quick peek, and PAdES specifies both CRL and OCSP in the 
"Long Term" profile.

Cheers,
Tomas

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 16 Aug 2010 08:49:20 -0400

I suppose we ought to forget all about this "Internet" thing too, since
it is a DoD-specific network that cost lots of money and effort to
build, and no one in the real world would want to use it anyway.

DoD and the space program have always been on the leading edge.  But
some of their stuff does flow downhill - remember Tang - the breakfast
of astronauts?

Dave

-----Original Message-----

I've talked to a number of developers who've worked on PKI software for
USG 
use, and some of them have put in massive amounts of effort (6-12 month 
efforts by entire development teams) to get their code to do what the
DoD PKI 
required.  This isn't even remotely representative of commercial
reality, what 
other customer could go to a commercial vendor and in effect tell them
"here 
are our requirements, drop any other work and spend the next year
customising 
your product to meet them".

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 16 Aug 2010 09:50:37 -0400

The definition of authentication (again, from NIST 800-63) is precisely
about the number of persons (or non-person entities) who have access to
a private key.  "The process of establishing confidence in user
identities electronically presented to an information system" cannot
lead to confidence if "Identity proofing and registration of applicants"
(the first of five factors) is not assured.  If you hand out keys by
email, then you will not have strong authentication even if you can
theoretically prove without a shadow of a doubt that anyone who grabbed
a copy of the key does actually possess it.

What precisely do you mean by "authenticating said key"?  A key is a
key, and anyone who has it can prove that they have it simply by giving
it to you (or anyone else who asks).  And if they give it to 1000
people, any of those 1000 key possessors can perform cryptography with
it.   So what.

Authentication (establishing confidence in user identities) requires
both some level of assurance on issuance/registration and some level of
private key protection.  Which means that the number of persons with
access to a key is not only relevant, but critical.

If you don't accept that basic premise, at least for purposes of
discussion, then no follow-on discussion (such as why and how
certificates are revoked) will make any sense at all.

-----Original Message-----
From: Jacob Dilles

>From a theoretical standpoint, according to the definition of
authentication the number of persons (whom have access to a private key)
is irrelevant in the process of authenticating said key. A revocation
check does not affect the cryptographic elements of PK verification. If
authentication can be performed without it, and it does not add any
additional assurance to that authentication, I don't see how it could
not be considered an authorization decision. From the beginning the CRL
was a solution to the issue of what happens when the authority decides
that it no longer wishes for a user to use their credential == authority
decides == authorization decision.

---

From: Jacob Dilles <[email-masked]>
Date: Mon, 16 Aug 2010 13:24:40 -0400

On Aug 16, 2010, at 9:50 AM, Kemp, David P. wrote:

(the first of five factors) is not assured.

Absolutely - Just remember that PKI authentication and user identity authentication are two different problems. There are many uses for the PKI in which the identity of the key-holder is not pertinent to the transaction, therefore RFC 5280 explicitly does not address user identity authentication:

8.  Security Considerations

...security factors outside the scope of this specification will affect the assurance provided to certificate users.

The procedures performed by CAs and RAs to validate the binding of the subject's identity to their public key greatly affect the assurance that ought to be placed in the certificate.  Relying parties might wish to review the CA's certification practice statement.

So clearly your requirement

is outside the scope of this discussion entirely.

Notwithstanding the irrelevance,

If you hand out keys by

I agree, and I've never implied that cryptographic PK authentication is synonymous with strong user authentication. Things like a password (something you know), a biometric match (something you have), or a disconnected token (something you have), used with or without the PKI, can increase the level-of-assurance of a user's identity during authentication.

Let's try to keep apples compared to apples,

Jacob

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Aug 2010 13:21:32 -0400

At 8:13 PM -0700 8/12/10, [email-masked] wrote:
>Content-Type: multipart/signed; protocol="application/pkcs7-signature";
>	micalg="sha1"; charset=x-user-defined; 
>boundary=gmsm1.4.5eqgcsgr60gegmd20fuyh2
>
>...so, in X.509 (and PKIX), why is there no separate concept of CRL 
>for 'privilegeRevoked' instead of 'keyCompromise'?  Yes, partitioned 
>CRLs are supposed to allow for this, but there are too many use 
>cases where partitioned CRLs are not at all okay, and CRL has a 
>connotation associated with 'revocation' (i.e., in the 
>'authentication' phase), instead of being processed during the 
>'authorization' phase.
>
>-Kyle H

First, remember that revocation is an assertion that the binding 
represented by the cert is no longer valid. Unless a reason code is 
asserted, an RP does not know what aspect of the assertion is the 
basis for the revocation.

Sscond, you persist in characterizing cert path validation as being 
divisible into "authentication" and "authorization" phases, but the 
rest of us (who are not pericore.com employees) don't.

Steve

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 16 Aug 2010 23:50:27 +0200

> build, and no one in the real world would want to use it anyway.

Dear Dave,

A decade ago in this very list I aired the idea that end-to-end
secured person-to-person solutions like S/MIME had serious usability
issues not to mention the cost required for getting on-board the Bridge CA.

This is essentially what I proposed:

http://webpki.org/papers/PKI/gateway.pdf

The support for such ideas (in PKIX) were lukewarm to say least.

Well, since the market (as I predicted), neither bought into FPKI
nor into S/MIME and was not being offered a simpler PKI (since you
basically *need* a government to get descent money) it turned to
something completely different which we could call "Super Providers".

The commercial world got *transparent* encrypted and authenticated
communication using Skype, currently serving HALF A BILLION users,
while the USG (and those living on it...) has to toil with an antiqued
off-line e-mail system requiring *end-users* sort-of "understand" PKI.

The financial industry were taken by surprise by PayPal since the former
*also* failed getting a leaner act together in time.

I guess you are not particularly interested in hearing an even more
disturbing prediction for the *next* decade?  Anyway, here it is:

Phones will replace CAC cards, only a few enthusiasts (like the
Feds) will continue with cards.  The US army will sooner or later
drop cards because waiting for a card to be distributed to a distant
camp in Afghanistan is a loser-idea.

Unfortunately, I suspect the Taliban's will be first with on-line
provisioning of credentials :-(

And really, $200+ single-use card-readers?  I don't think so.

Regards
Anders

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 18 Aug 2010 04:09:13 +1200

>I'm game.  Send it across. :)

See my message in private mail, but I have to ask: You're pretty much asking
to have your machine, and its contents, handed over to the control of Russian
malware, so I assume you've got some way of gaming this test.  How are you
doing it? :-).

Peter.

---

From: "Todd E. Johnson" <[email-masked]>
Date: Tue, 17 Aug 2010 22:30:41 -0400

Hi Peter,

It seems there are some assumptions made of my everyday platform, but in 
the end, my curiosity is genuine.

For the effort, I get to observe, and create signatures.  ;)  I did not 
see that as a caveat to the challenge...

I can't seem to locate any private email from you.  Perhaps the said 
malware did not make it past the Yahoo! anti-virus? (unfortunately that 
is beyond my control)

On 08/17/2010 12:09 PM, Peter Gutmann wrote:
> "Todd E. Johnson"<[email-masked]>  writes:
>

-- 

Regards,

Todd E. Johnson

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 20 Aug 2010 01:55:05 +1200

"Todd E. Johnson" <[email-masked]> writes:

>It seems there are some assumptions made of my everyday platform, but in the
>end, my curiosity is genuine.

Hmm, so reading between the lines here, you're not actually risking your
machine and/or data?

>I can't seem to locate any private email from you.  Perhaps the said malware
>did not make it past the Yahoo! anti-virus? (unfortunately that is beyond my
>control)

It probably didn't even make it out of our network (I had the same trouble
getting it in).  Hmm, I'll have to try something else, I'll continue this off-
list since it's probably not that interesting to everyone else.

Peter.