Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm working on software that will be in use for foreseeable future (15 years+) that will need to validate XAdES-A signatures (long term archival, similar to PAdES-A, but for XML). That means, it will have multiple CA certificates required for its verification, different signature algorithms and different digest algorithms.

As such, I see two problems:

  • getting information which CA certificates lost their validity before their notValidAfter date (because of CA compromise, cease of operation, etc.)
  • marking algorithms (like SHA-1) or key lengths (like RSA 1024) as insecure after some date

Is there some standard for files with such information? If I create my own, should I rather choose to save this information as OIDs (algorithms) or just as human-readable names (I'm using Java if that has anything to do with this...).

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

About trusted CA list formats, see RFC 5914 ("Trust Anchor Format") and the behemoth Trust Service Status List format. European Union tries to maintain such a list.

For the algorithms or key sizes, as far as I know, the recommendations are for human consumption, not in a computer-readable format. See this site for pointers (e.g. to the NIST recommendations). Contrary to lists of trust anchors, we do not expect regular activity there, and it will be by burst (changes to our notion of security of algorithms and key lengths come from cryptanalytic research results, which appear rather unpredictably -- because Science works that way).

share|improve this answer
    
I expect the algorithm changes to be in bursts, but I don't want to wave the configuration in to the source: people are usually much more likely to edit configuration files than source code. And those files should be kept up to date, especially when this becomes legacy code. I'm not sure if I read RFC 5914 correctly, but I don't see explicit dates or time that restricts validity of certificates... I'll probably be using TSSL as the deployment will be in EU. –  Hubert Kario Sep 21 '12 at 13:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.