Subject: A proxy certificate validation question.

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 7 Jan 2009 10:57:35 -0600

Just to take a break from discussing MD5 for a moment, let me make sure 
I understand the implications of the proxy cert (PC) path validation 
algorithm:

A relying party that does *not* understand PCs will fail to validate a 
chain from root->EE->PC *if and only if* one of the CAs in the chain has 
pathLenConstraint set to a value that exhausts at the EE cert.

In other words, in order to prevent EEs from issuing PCs to spoof other 
EEs, the last CA in a chain can set pathLenConstraint=0.  Relying 
parties that understand PCs will validate chains with PCs because they 
only do the 3280 validation algorithm starting from the EE cert, but a 
relying party that *does not* understand PCs will do the 3280 validation 
starting from the last PC--causing the pathLenConstraint check to fail.

Do I have that right?  Seems to be an important protection to me.

I'm assuming the RP is obeying basicConstraints, of course.  Yes, Peter, 
I know that's not always true.  :)

-- Tim

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 07 Jan 2009 18:35:26 +0100

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

> Just to take a break from discussing MD5 for a moment, let me make
> sure I understand the implications of the proxy cert (PC) path
> validation algorithm:
>
> chain from root->EE->PC *if and only if* one of the CAs in the chain
> has pathLenConstraint set to a value that exhausts at the EE cert.

Per RFC 3820 the proxyCertInfo extension MUST be marked as critical, and
if I understand RFC 3280 correctly, verifiers MUST reject the
certificate if it encounters a critical extension it does not recognize.
The latter is not reflected in the section 6 path validation algorithm,
as far as I can tell, though, but it is mentioned in section 4.2.

/Simon

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 07 Jan 2009 13:27:16 -0500

No pathLenConstraint is necessary.  If the EE certificate is really an 
EE certificate, then it will either not include a basicConstraints 
extension or it will include a basicConstraints extension with 
cA=FALSE.  In either case, a relying party that does not understand 
proxy certificates will not validate any certification paths that 
include the EE certificate as an intermediate certificate, and so would 
reject a path of the form ...->EE->PC.

Dave

Timothy J. Miller wrote:
> In other words, in order to prevent EEs from issuing PCs to spoof 
> other EEs, the last CA in a chain can set pathLenConstraint=0.  
> Relying parties that understand PCs will validate chains with PCs 
> because they only do the 3280 validation algorithm starting from the 
> EE cert, but a relying party that *does not* understand PCs will do 
> the 3280 validation starting from the last PC--causing the 
> pathLenConstraint check to fail.
>
> I'm assuming the RP is obeying basicConstraints, of course.  Yes, 
> Peter, I know that's not always true.  :)
>
> -- Tim

---

From: Von Welch <[email-masked]>
Date: Wed, 07 Jan 2009 15:26:23 -0600

> certificate if it encounters a critical extension it does not recognize.

That is correct, the fact the PC extension is critical is the
mechanism that prevents a relying party ignorant of proxy
certificates from validating one.

The fact that the subject name of the PC must be a single CN
component appended to the subject name of its issuer (see Sections
3.4 and 4.1.3.a.4) prevents any spoofing of an EE subject name in a
PC at a PC-aware relying party.

Von

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Jan 2009 17:26:51 -0500

Von,

I think David Cooper's response is correct, i.e., because the issuer 
of the proxy cert is an EE, and an EE is NOT normally allowed to pose 
as a CA, the cert path validation should fail if an RP is not aware 
of the special processing required for a proxy cert.

Steve

---

From: "Tom Scavo" <[email-masked]>
Date: Wed, 7 Jan 2009 18:03:27 -0500

On Wed, Jan 7, 2009 at 5:26 PM, Stephen Kent <[email-masked]> wrote:
>
> I think David Cooper's response is correct, i.e., because the issuer of the
> proxy cert is an EE

The issuer of a PC is either an EE or another PC.

> and an EE is NOT normally allowed to pose as a CA, the
> cert path validation should fail if an RP is not aware of the special
> processing required for a proxy cert.

Yes, I think you're right.  It's a race condition between
basicConstraints and an unrecognized critical extension.  AFAICT by
reading 5280, basicConstraints wins.

Tom

---

From: Von Welch <[email-masked]>
Date: Wed, 07 Jan 2009 17:16:41 -0600

Steve,

 Yes, while both the basic constraints with CA != True and the
critical extension should cause a failure in that case, the basic
constraints failure should come first per processing rules.

Von

Stephen Kent wrote:
> 
> Von,
> 
> I think David Cooper's response is correct, i.e., because the issuer of
> the proxy cert is an EE, and an EE is NOT normally allowed to pose as a
> CA, the cert path validation should fail if an RP is not aware of the
> special processing required for a proxy cert.
> 
> Steve

---

From: Philipp Gühring <[email-masked]>
Date: Thu, 08 Jan 2009 18:23:40 +0100

Hi,

> 1) Enables a limit to be placed on a path length

Path-Length limitation only helps against a Sub-CA attack.
It doesn't help against an attack where EE' is a certificate for *.com
(According to the researchers, that attack is even easier than a Sub-CA
attack.)

> SHA1 is not an immediate threat but it is certainly something that we
> should worry about. 

I fully agree. SHA1 will likely follow with the same kind of attack in a
few years.

> At the moment I see three potential insurance policies
> 
> 1) Introduce additional randomness into the digest value.

It seems that it even matters where the randomness is inserted.
As far as I have understood it, randomness in the beginning (somewhere
around the serial number) is better than randomness at the end (some
X.509v3 extensions)

> 2) Employ OCSP as a means of introducing a stronger algorithm (and
> addressing concerns previously raised in this list)

You mean using something similar like OCSP, that provides a re-signature
for an existing certificate?

Something we should be careful about:
I think some RFC defines that a certificate must be unique according to
issuer+serial number. And some software actually implemented that and
completely declares a whole (root?) CA invalid as soon as it sees two
different certificates with same issuer+serial number.
So if we re-sign an old certificate, and the client would exchange the
signature, this would cause a different certificate (at least the
signature at the end and the SHA-1 (or MD5) Hash of the whole
certificate would change). If it passes the modified certificate on to
another module, the other module might declare the CA invalid.

What if we use something like OCSP that delivers a renewed (with
different serial number) certificate when someone presents an old
certificate?

> 3) Employ path length constraints in the CA cert to defeat the single
> bit attack.

I personally do not believe in Path-Length constraints.

> I like all three approaches and do not consider them to be exclusive. If
> we pick just one I think we are more likely to see a failure.

Best regards,
Philipp Gühring

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Jan 2009 08:30:13 -0800

I think that as far as the IETF is concerned we need to stop thinking about the MD5 issue and instead think about the SHA1 issue. That is harder because the legacy base does not provide universal support for something stronger. So any transition comes with a significant cost.

Lets break this down, I think there might have been a good idea that was missed.

The particular feature of the compressor attack is that you only get to flip a single bit. Therefore you have to make it count. Flipping the cert signing bit from on to off is the most effective way of making it count.

So if the initial chain is

R -> C1 -> C2 -> EE

The new chain is

R -> C1 -> C2 -> EE' -> EE

There are two places we can apply constraints to defeat this attack. One is in EE, the other is somewhere higher up in the chain, C1 or C2.

So the question now is, is there an extension that is implemented today that

1) Enables a limit to be placed on a path length
2) Is implemented in existing browsers
3) Can be used without interfering with other browsers, i.e.
   3a) MAY be marked not-critical
   3b) Is accepted by every legacy browser without exception.

In terms of 3a, I am quite happy taking an existing extension and changing a MUST to a SHOULD provided that we don't have a deployed base that attempts to enforce compliance. If ou are using the extension for the purpose of issuing proxy certs then the requirement is necessary. But the critical bit means 'break if you do not understand this' and this is not the desired semantics for an insurance policy.

The ideal case is that we find something that works today. The less ideal case is that we can only impose restrictions going forward which is still valuable, but not so much.

SHA1 is not an immediate threat but it is certainly something that we should worry about. At the moment I see three potential insurance policies

1) Introduce additional randomness into the digest value.
2) Employ OCSP as a means of introducing a stronger algorithm (and addressing concerns previously raised in this list)
3) Employ path length constraints in the CA cert to defeat the single bit attack.

I like all three approaches and do not consider them to be exclusive. If we pick just one I think we are more likely to see a failure.

-----Original Message-----
From: [email-masked] on behalf of Von Welch
Sent: Wed 1/7/2009 6:16 PM
To: Stephen Kent
Cc: [email-masked]; Simon Josefsson; Timothy J. Miller; [email-masked]
Subject: Re: A proxy certificate validation question.

Steve,

Von

---

From: "Timothy J. Miller" <[email-masked]>
Date: Thu, 8 Jan 2009 11:53:29 -0600

> around the serial number) is better than randomness at the end (some

Use randomized hashing and the whole vector is moot for all hashes 
unless a pre-image break is discovered.

-- Tim

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Jan 2009 13:06:42 -0800

I am a big fan of randomized hashing.
 
Problem is that some MAC constructions do not offer collision resistance. In particular CMAC does not which means that we can use HMAC-SHA512 but not CMAC-AES.
 
Which is a serious limitation as SHA2 is one of the things we are trying to get away from. 

I think we need to find a better construction than CMAC. I don't see why we can't have a MAC function constructed from a block cipher that has all the provably secure features of CMAC plus provably secure collision resistance with a known key.
 
So the current situation is that I am a big fan of something I do not currently have a standard for doing. Which means that we can't use randomized hashing as a shortcut for getting a replacement digest function.

________________________________

From: Timothy J. Miller [mailto:[email-masked]]
Sent: Thu 1/8/2009 12:53 PM
To: Philipp Gühring
Cc: Hallam-Baker, Phillip; [email-masked]; Stephen Kent; Simon Josefsson; [email-masked]
Subject: Re: A proxy certificate validation question.

-- Tim

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 09 Jan 2009 11:48:30 +0100

Philipp,

> for an existing certificate?

Actually, SCVP could help to tell original and rogue certificates apart. This requires the following
1) The SCVP server uses a secure hash function and signature algorithm
2) The client requests inclusion of the certificate in question in the response by means of the wantBack id-swb-pkc-cert.
3) The server is able to retrieve the certificate from a trustworthy source (only containing authentic certificates),
i.e. from the CA's repository.
If SCVP was widely deployed, it could mitigate the risks implied by hash function weaknesses.

In Germany, the OCSP responders provided by CA's issuing qualified certificates typically provide a similar white-list
lookup feature:
1) They respond with status "good" only if the certificate has actually been issued by the CA. In particular, they have
access to the CA's repository (or a replication) and do not only rely on a CRL.
2) They use a private OCSP response extension CertHash (defined by the Common PKI standard) to include the hash value of
the certificate in question in the response.

There are some German signature verification tools and email clients which support this white-list lookup feature and
check the certificate against the cert hash included in the response. Of course this features exceeds standard OCSP, but
it is actually used.

> different certificates with same issuer+serial number.
This problem would not occur with a validation service providing white-list lookup.

> different serial number) certificate when someone presents an old
Better: SCVP or OCSP with white-list lookup.

Johannes

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 9 Jan 2009 06:20:21 -0800

Lets start with a principle here: No new protocols.

This is not an opportunity for people to deploy their pet protocol. So far we have SCVP and SPKI proposed as somehow being a 'simpler' option than OCSP, the protocol that is widely deployed by CAs and employed by relying applications for the express purpose of reporting certificate validity.

If the group had wanted to make SCVP a replacement for OCSP then it should have accepted Mike Meyer's proposal to make SCVP an extension to OCSP, which was in any case the logic behind the earlier change of the original OCSP to ASN.1 syntax.

As far as I am aware, SCVP or SPKI deployment would require an entirely new infrastructure for every single member of the CA/Browser forum. That is not consistent with my view of a 'simpler' solution.

I do not think using SCVP for something it is not designed to do is simpler. I do not think that introducing SPKI, an entirely different PKI is 'simpler'. Neither is going to happen.

Even if they were simpler (which they are not). What I am interested in here is 'more practical'. In particular, what solutions are most likely to be acceptable to members of the CA/Browser forum. Solutions that do not gain the support of at least one major CA and at least one major application provider are irrelevant. The current expectation amongst CAs is that the core PKI infrastructures are X.509v3 certificates, X.509v2 CRLs and OCSP with an expectation that use of CRLs will be replaced by use of OCSP at some point. Any proposal involving any other mechanism is going to be less attractive than one based on those mechanisms.

Looking at the OCSP specification, there is an SHA1 problem in any case. The key reference mechanism specifies SHA1 as the only algorithm. We have to fix that in any case if we are going to take OCSP to DRAFT status. Having a digest reference to the whole certificate is the most logical alternative.

-----Original Message-----
From: [email-masked] on behalf of Johannes Merkle
Sent: Fri 1/9/2009 5:48 AM
To: Philipp Gühring
Cc: [email-masked]
Subject: Re: A proxy certificate validation question.

Philipp,

Johannes

---

From: Stephen Kent <[email-masked]>
Date: Mon, 12 Jan 2009 14:58:42 -0500

At 6:20 AM -0800 1/9/09, Hallam-Baker, Phillip wrote:
>This is not an opportunity for people to deploy their pet protocol. 
>So far we have SCVP and SPKI proposed as somehow being a 'simpler' 
>option than OCSP, the protocol that is widely deployed by CAs and 
>employed by relying applications for the express purpose of 
>reporting certificate validity.

Trust me, SPKI is not on the table :-) as a option.

>If the group had wanted to make SCVP a replacement for OCSP then it 
>should have accepted Mike Meyer's proposal to make SCVP an extension 
>to OCSP, which was in any case the logic behind the earlier change 
>of the original OCSP to ASN.1 syntax.

right, but PKIX did not take the path of keeping the brand and 
changing the semantics.

>As far as I am aware, SCVP or SPKI deployment would require an 
>entirely new infrastructure for every single member of the 
>CA/Browser forum. That is not consistent with my view of a 'simpler' 
>solution.

SCVP is in a different category from SPKI, but the bottom line impact 
you cite is correct.

>I do not think using SCVP for something it is not designed to do is 
>simpler. I do not think that introducing SPKI, an entirely different 
>PKI is 'simpler'. Neither is going to happen.

agreed.

>Even if they were simpler (which they are not). What I am interested 
>in here is 'more practical'. In particular, what solutions are most 
>likely to be acceptable to members of the CA/Browser forum. 
>Solutions that do not gain the support of at least one major CA and 
>at least one major application provider are irrelevant. The current 
>expectation amongst CAs is that the core PKI infrastructures are 
>X.509v3 certificates, X.509v2 CRLs and OCSP with an expectation that 
>use of CRLs will be replaced by use of OCSP at some point.

I don't agree with this last point. CRLs are still viable in many 
contexts, and  can serve as the reference for many OCSP servers, so 
...

>Any proposal involving any other mechanism is going to be less 
>attractive than one based on those mechanisms.

to first order, I agree.

>Looking at the OCSP specification, there is an SHA1 problem in any 
>case. The key reference mechanism specifies SHA1 as the only 
>algorithm. We have to fix that in any case if we are going to take 
>OCSP to DRAFT status. Having a digest reference to the whole 
>certificate is the most logical alternative.

right, we have to fix the lack of algorithm agility and the use cases 
you briefed at the 72nd IETF.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 12 Jan 2009 14:54:36 -0500

At 11:48 AM +0100 1/9/09, Johannes Merkle wrote:
>2) The client requests inclusion of the certificate in question in 
>the response by means of the wantBack id-swb-pkc-cert.
>3) The server is able to retrieve the certificate from a trustworthy 
>source (only containing authentic certificates),

The X.509 PKI model has never assumed that one should check the 
validity of a cert by looking for it in some repository. I realize 
that some European CAs have advocated this model, but PKIX said NO to 
this a few years ago. The discussion context was whether OCSP is a 
cert validation protocol vs. a cert revocation status protocol.

>In Germany, the OCSP responders provided by CA's issuing qualified 
>certificates typically provide a similar white-list
>lookup feature:
>1) They respond with status "good" only if the certificate has 
>actually been issued by the CA. In particular, they have
>2) They use a private OCSP response extension CertHash (defined by 
>the Common PKI standard) to include the hash value of
>There are some German signature verification tools and email clients 
>which support this white-list lookup feature and
>check the certificate against the cert hash included in the 
>response. Of course this features exceeds standard OCSP,

yes, and moreover, this runs contrary to the scope of OCSP as 
expressed in the  development and RFC publication of SCVP.

Steve

---

From: Eric Norman <[email-masked]>
Date: Tue, 13 Jan 2009 15:13:39 -0600

On Jan 12, 2009, at 1:54 PM, Stephen Kent wrote:

> validity of a cert by looking for it in some repository.

After all, if you're going to do an on-line status check
every time a certificate is used, then why are you using
this certificate stuff in the first place?

Eric Norman

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 14 Jan 2009 19:13:35 +1300

Eric Norman <[email-masked]> writes:

>After all, if you're going to do an on-line status check every time a 
>certificate is used, then why are you using this certificate stuff in 
>the first place?

Ooh, ooh, I know that one, the answer is:

  "because of digital ancestor-worship of closed-door OSI standards 
  from the 1980s"

and it was from an NCSC(?) paper some years ago.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Jan 2009 12:11:46 -0500

>and it was from an NCSC(?) paper some years ago.

Peter,

for bonus points (and to help validate your comment) can you provide 
a cite of the relevant OSi standards, or the NCSC paper?

Steve

---

From: Stephen Wilson <[email-masked]>
Date: Thu, 15 Jan 2009 07:37:26 +1100

> this certificate stuff in the first place?

Using certificates in an online-all-the-time environment can indeed look 
  like overkill.  But in my view, the greatest and most unique benefit 
of PKI comes in offline environments where it is important to be able to 
check the historical validity of a transaction.  Because certificates 
bake in the attributes of a sender as they were at the time of the 
transaction, and the validity at any time in the past can be easily 
checked by the CRLs and delta CRLs (OK, now I'm veering away from online 
status check).

My favorite examples are from e-health.  Take an electronic 
prescription, digitally signed by a physician, using her certificate 
issued by a medical registration board.  The script might also be 
counter signed by the patient using a smartcard.  In the case of 
narcotics or other scheduled medications, a special license is required 
and this can be represented as an attribute in the physician certificate.

Now, in processing prescriptions, electronic messages plus copies of the 
digital signatures and certificates are sent all over the place: to the 
pharmacist, to the government, to one or more electronic health records, 
to special monitoring agencies in the case of scheduled prescriptions, 
to insurance companies, and so on.  And these messages need to be 
verifiable not just the day that the script was written, but for a long 
time down the track (when more courses of treatment are dispensed from a 
repeat script, when an in-patient is discharged from hospital, when the 
patient transfers their care from one provider to another, when 
electronic health record entries are retrieved and validated by other 
carers or researchers, when insurance claims are processed, when a 
specialist reviews the case, or when occasionally some invesitigation 
into drug prescribing is undertaken ...).  Furthermore, as copies of 
these messages wend their way across disparate systems and the world, 
increasingly distant form the original transaction event, they need to 
maintain their fidelity and integrity.

The digital signature of the physician, plus her certificate, bakes into 
the transaction her medical qualifications as they were at the time she 
wrote the script.  Even after her certificate expires, or is revoked 
(because she retires or whatever), the signature remains easily 
verifiable.

In contrast, what sort of alternative authentication technology could 
provide easily verifiable confirmation of all parties' credentials as 
they were at the time?  What system allows all parties' credentials and 
other attributes at all times in the past to be retrieved and validated?

The online-all-the-time paradigm (which I think deeply informs design 
assumptions in most federated ID systems as well especially the Identity 
Metasystem) seems to overlook the fact that often times, old transaction 
events remain important.

It's not just healthcare.  Environments with similar hallmarks -- long 
lived transactions and multiple, distant relying parties -- include 
trade documentation, conveyancing, superannuation (pension funds) 
management, insurance, and business banking.  These are the sorts of 
niche areas where PKI has tended to do best historically.

Cheers,

Steve Wilson
Lockstep Technologies.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 16 Jan 2009 12:42:51 -0800

Actually the group did keep the band and change the semantics. The draft of OCSP I wrote, the last one submitted before the conversion to ASN.1 described key status semantics.
 
But we are still firmly inside the scope of reporting certificate status here. The only change is that we are looking for ways to build in extra security in cases where we are slightly less certain about the security of SHA1.
 
At present there is one place where SHA1 is hard coded into OCSP as the only alg choice. That may have been the right decision then. It is certainly not something that we would consider acceptable today.

On the CRL thing, yes people will continue to use CRLs. In particular for describing the status of OCSP responder certs. But if folk come along and say reduce two mechanisms to one, OCSP is going to be the one left in virtually all application level applications.

From: Stephen Kent [mailto:[email-masked]]
Sent: Mon 1/12/2009 2:58 PM
To: Hallam-Baker, Phillip
Cc: Johannes Merkle; Philipp Gühring; [email-masked]
Subject: RE: A proxy certificate validation question.

agreed.

to first order, I agree.

Steve

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 16 Jan 2009 13:12:42 -0800

Not to labor the point, but XKMS is a PKI as well. The original code-name was Trust Assertion XML Infrastructure.
 
The static assertions were then separated from the dynamic protocol. The dynamic protocol turned into XKMS. The static protocol led to the assertion layer of SAML.

What you really want though is simply a CKI. A Cryptographic Key Infrastructure. There is really no point is committing yourself up front to only use one form of cryptography. 

From: [email-masked] on behalf of Stephen Wilson
Sent: Wed 1/14/2009 3:37 PM
To: [email-masked]
Subject: Why use PKI? [was: A certificate validation question]

Cheers,

Steve Wilson
Lockstep Technologies.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 16 Jan 2009 12:30:37 -0800

Yes, if you adopt this approach PKIX eventually becomes at the technical level merely an inefficient version of XKMS.
 
I don't see anything particularly wrong with that. My concerns here are simply to enable as many applications as possible use the web as predictably securely as possible. Since the legacy base only supports PKIX based PKI that requires a certain quantity of what Peter refered to as 'ancestor worship of OSI standards'.

Which is precisely why Steve's point is relevant. You do not want to do so much to OCSP that you have made it into XKMS.
 
On the other hand, we do need to work out an effective transition strategy for SHA1 here given the fact that deployment of SHA256 is minimal and we do not yet have SHA3.

We need a transition plan that maintains maximal security and functionality for as many applications for as long as possible that involves touching as few parts of the infrastructure as possible. 
 
It is not an immediate concern but the longer we wait to take action the greater the eventual cost will be. 

From: [email-masked] on behalf of Eric Norman
Sent: Tue 1/13/2009 4:13 PM
To: [email-masked]
Subject: Re: A certificate validation question.

Eric Norman

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 16 Jan 2009 16:42:22 -0500

... and for the status of CA certificates, server certificates, or any other class of subjects for which the revocation rate is very low.  CRLs are an attractive approach when the only information to be transmitted is akin to "yes, the stars are still shining in the heavens" and only the occasional supernova needs to be individually enumerated.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
Sent: Friday, January 16, 2009 3:43 PM
To: Stephen Kent
Cc: Johannes Merkle; Philipp Gühring; [email-masked]
Subject: RE: A proxy certificate validation question.

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 16 Jan 2009 15:19:41 -0800

Phillip Hallam-Baker wrote:
> On the CRL thing, yes people will continue to use CRLs. In particular
> for describing the status of OCSP responder certs. But if folk come
> along and say reduce two mechanisms to one, OCSP is going to be the one
> left in virtually all application level applications.

David P. Kemp wrote:
> … and for the status of CA certificates, server certificates, or any
> other class of subjects for which the revocation rate is very low.  CRLs
> are an attractive approach when the only information to be transmitted
> is akin to “yes, the stars are still shining in the heavens” and only
> the occasional supernova needs to be individually enumerated.

TLS servers that request client authentication prefer to use CRLs than
OCSP for validating client certs because it's faster and more efficient
to use a CRL downloaded (say) daily than to do an OCSP query for every
connection.

---

From: Tom Gindin <[email-masked]>
Date: Fri, 16 Jan 2009 18:58:54 -0500

Eric:

        May I be equally flippant, but less dismissive?  If an RP 
developer goes out on the Internet for a certificate status check, he 
expects a recent signature as assurance of the result.  He won't bother 
otherwise, as some don't even with signed responses.

                Tom Gindin

Eric Norman <[email-masked]> 
Sent by: [email-masked]
01/13/2009 04:13 PM

To
[email-masked]
cc

Subject
Re: A certificate validation question.

Eric Norman

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 20 Jan 2009 10:35:38 -0600

> to use a CRL downloaded (say) daily than to do an OCSP query for every

That's all well and good until your CRLs get to a couple of hundred 
megabytes.

-- Tim

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Jan 2009 11:49:45 -0500

At 10:35 AM -0600 1/20/09, Timothy J. Miller wrote:
>That's all well and good until your CRLs get to a couple of hundred megabytes.
>
>-- Tim

CRLs of that size are usually an indication of very poor planning, 
the CRL for CACs being a prime example.

Steve

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 20 Jan 2009 11:20:38 -0600

> the CRL for CACs being a prime example.

Which is of course what I was thinking of.  However, you can blame 
planning all you want but folks still have to deal with the consequences.

However, IMHO it's unfair to call this poor planning, since the DoD PKI 
was (is?) unique in scale.

-- Tim

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 20 Jan 2009 14:50:14 -0500

partitioned into small chunks of 1,000-10,000 subjects each regardless
of the total scale of the PKI.  Using pre-signed OCSP responses of
20-subject partitions provides no benefit over 20-subject CRLs, but is
hugely inefficient of bandwidth and storage.

If we think the current revocation structure is inadequate for 4 million
active users, what happens when it expands to cover 40 million
dependents and retirees?  A little planning would be nice.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Timothy J. Miller
Sent: Tuesday, January 20, 2009 12:21 PM
To: Stephen Kent
Cc: Nelson B Bolyard; [email-masked]
Subject: Re: A proxy certificate validation question.

Which is of course what I was thinking of.  However, you can blame 
planning all you want but folks still have to deal with the
consequences.

-- Tim

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Jan 2009 14:12:43 -0500

>However, IMHO it's unfair to call this poor planning, since the DoD 
>PKI was (is?) unique in scale.
>
>-- Tim

The DoD PKI folks (at DISA, Mitre, and NSA) were advised about some 
of the inevitable, adverse side effects of their strategies well 
before the CRL turned into Godzilla. I know, because I was one of 
those who delivered the warnings. The response was of the form "we're 
too far along in our planning to change now" and the result was as 
expected.

This was an train wreck that folks chose to not avoid.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Jan 2009 16:56:24 -0500

One of my favorite examples of poor CAC CRL planning has to do with 
the fact that when a CAC holder is promoted, the CAC has to be 
replaced (the rank info on the physical card is no longer accurate). 
One result of this replacement is revocation of the 3 certs on the 
card. The DoD must have some reasonable data on the expected 
promotion frequency of personnel at various rungs in the career 
ladder, and this info could have been used to adjust the validity 
interval to more closely track the expected lifetime of the certs 
relative to this very common revocation reason.

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 22 Jan 2009 00:09:07 +1300

>for bonus points (and to help validate your comment) can you provide a cite
>of the relevant OSi standards, or the NCSC paper?

Uhh, I think it should be obvious which OSI standard OCSP is a digital
ancestor-worship of.  As for the conference, all I have is the quote on
my home page:

  [PKI designs are based on] digital ancestor-worship of closed-door-generated
  standards going back to at least the mid 80's. [...] The result seems to be
  protocols so convoluted and obtuse that vendor implementation is
  difficult/impossible and costly.
    - William Flanigan Jr. and Deborah Mitchell

Unfortunately I don't recall exactly where that came from, whatever it is it's
a paper-only publication since Google doesn't find any hits for it, and one of
the NCSC proceedings seemed to be a good match.  However I'm not actually
going to plough through them all to see if it really was from there.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 22 Jan 2009 02:04:08 +1300

>IMHO that's not a planning failure, that's an execution failure.

It's neither an execution failure nor a planning failure, it's a design
failure.  A system that requires you to download anything more than a boolean
yes/no response to "is this cert I've got OK" (with a little extra crypto
protection as required) is broken.  Don't blame the users when the tools are
at fault.

Peter.