views:

484

answers:

5

Hello,

I am programming a Certification Authority in java for a uni class, now I don't know what's the best option for the serial number of the Certificate.

  • Simple static counter from 0 to veryBigNumber
  • some huge BigInt random number

Is there any good reason for choosing one over the other... or none of them??

thanks,

+2  A: 

Technically counter from 0 to veryBigNumber is easier to implement than bigRandomNumber - because the serial numbers MUST be different.

However - you might not want to use a simple counter if you care about people knowing how many certificates you issued.

laura
+2  A: 

It depends on what you are using the serial number for. If you are a small company and if you are planning on giving one certificate per customer, then your serial number will reveal how many customers you have.

Other then that i dont see any reason why the serial number shouldn't be serial. Some people argue that using serial numbers will give away some information (the next serial number) to a potential attacker but i dont think that is a big issue.

hmm
+2  A: 

I would recommend that you use a random number, but keep a list of those issued serial numbers in a database. This will allow for two things.

  1. You will never reissue the same serial number.
  2. You can tell from a certificate's serial number if it is even remotely valid.

Of course #1 requires that you check against the known list on generation and to generate a new random number if a collision occurs, and #2 isn't much of anything in terms of security or validation but an interesting prospect never-the-less.

Jason Whitehorn
I think I will do just that... thanks
marco
"You can tell from a serial number if it is even remotely valid" is not true. Validity of a certificate requires lots of checks, and the serial number isn't one of them. It's possibly a quick index into the list of certificates you've stored, but that's all. A hash would be just as good. But it *certainly* won't help a client verify whether a certficiate is valid (or "remotely" valid, whatever that means).
John
@John, I assume then that you did not read my other sentence... "#2 isn't much of anything in terms of security or validation but an interesting prospect never-the-less."
Jason Whitehorn
@Jason, I did read it, and agreed. But it's a bit strange that after recommending a random number, you describe benefits that aren't actually related to the number being random - they are just as applicable to the use of serial numbers. In security protocols, it's traditional to use the term "serial number" when a sequence starting from zero is adequate, and the term "nonce" when there is security benefit to be gained by using random numbers. I find that so many people (especially students) find it easy to get wrong impressions about PKI that it's worth clarifying at any opportunity.Regards.
John
+1  A: 

The main requirement is that the pair (Issuer distinguished name, serial number) should be unique in the universe. Therefore you should not use a random number unless it is so large that the probability of repeat is negligible. A 20 byte random number should be more than adequate. A simple counter is perfectly fine, if you don't mind other people knowing how many certificates you have issued.

The relatively recent attacks on SSL certificate issuers (by Alex Sotirov et. al) that exploited the weakness in MD5 actually were made even easier by the use of counter-type serial numbers. Random serial numbers were not attacked. This does not mean that predictable serial numbers are bad security, it just means that for this application random serial numbers could help mask the weaknesses in MD5. The root problem was still MD5.

GregS
A: 

I think if we examine the word Serial the answer is implicit....Serial,series, progression etc

Mark Sutton