headers
Nick Pope | 2 Oct 1996 12:21
Picon
Picon

X.509 validity period

Talking about X.509 defects (as in Warwicks recent message), I have 
come across a more fundamental issue which I would 
like to get views.

I have a client who requires to be able to hold signed documents and 
their certificates in a long term archive.

This necessitates the validity period of the certificates to be 
potentially longer than 50 years.  The current validity period is 
encoded in UTCTime which has a 2 digit year, which has to be adjusted 
to cater for the century roll over giving a resolution of only 50 
years.

Ideally, the validity period should be encoded in generalised 
time.  Has anyone else identified similar concerns?

Nick Pope

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

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517
(Continue reading)

Permalink | Reply | 1 comment |
headers
pgut001 | 3 Oct 1996 03:15
Picon
Picon
Picon
Favicon

Re: X.509 validity period

>I have a client who requires to be able to hold signed documents and their 
>certificates in a long term archive.
>
>This necessitates the validity period of the certificates to be potentially 
>longer than 50 years.  The current validity period is encoded in UTCTime 
>which has a 2 digit year, which has to be adjusted to cater for the century 
>roll over giving a resolution of only 50 years.
>
>Ideally, the validity period should be encoded in generalised time.  Has 
>anyone else identified similar concerns?

In all the code I've seen the practice is to add 100 years to the century if 
the year is < 70-90 (the exact threshold depends on the implementation.  I've 
never seen a pre-1990 cert so I've used 90).  This does mean, though, that you 
can't do a simple string compare on the encoded time to check date ranges.

This is one of the problems which I point out in my X.509 implementation 
notes.  I'll post these to the list for comment in a day or two, after I find 
a fork and some marshmellows for toasting :-).

Peter.
Permalink | Reply | 0 comments |
headers
Nick Pope | 2 Oct 1996 11:39
Picon
Picon

Re: X.509 Bug Regarding Policy Constraints

In reply to your message of 23 Sep 96, 16:44:

I disagree that making this change is appropriate to a defect.  It is removing 
functions from the agreed X.509 amendment.

Removing policySet from the extension no longer makes it possible to 
restrict the policies which may be governed by a CA.

The appropriate resolution is to describe how the field is used not 
remove agreed functionality.

Nick Pope

> An error has been uncovered regarding policy constraints in the X.509
> certificate extensions amendment.  I have drafted the attached defect
> report for consideration at the October meeting of the ISO/IEC/ITU
> Directory group. I would appreciate hearing from anyone who objects to
> policySet being deleted from policy constraints.
> 
> Thanks to John Pawling of JG VanDyke for finding the error.  
> 
> Warwick
> --------------------------------------
> 
>
......

> 10.	Nature of Defect:  (complete, concise explanation of the perceived
> problem)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Roe | 2 Oct 1996 16:14
Picon
Picon
Favicon

Re: X.509 validity period

> Ideally, the validity period should be encoded in generalised 
> time.  Has anyone else identified similar concerns?

Yes - this issue keeps coming up. My most recent re-encounter with this problem
was in the context of the (UK) National Health Service's network. The
year 2000 is only 4 years away, so it's necessary to do *something* about
this problem now, even if all you do is make an agreement that within your
domain the year '01' is 2001 not 1901. This quick fix buys you time, but
is storing up trouble for the future. If you have data that is likely to
live for more than 50 years, a proper solution is called for.

> This necessitates the validity period of the certificates to be 
> potentially longer than 50 years. 

Actually, I belive that it isn't necessary for the validity period to be
longer than 50 years, this arises out of the discussion we had on what
the validity period actually means. Revocation information is guaranteed to
be available in the Directory (if you have one :-) ) during the validity period,
but may be available by other means after the end of the validity period.
Thus, is may be possible to verify a historical document long after its
accompanying certificate has expired.

  (I don't intend to re-open the argument about the validity period!
   I'm just pointing out that some of the discussion we had might be relevent
   in this application).

Finally, if you intend on keeping documents for >50 years, I would recommend
using additonal methods over and above digital signature to ensure integrity.
(e.g. keeping a copy physically secure etc.).
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.Kesterson | 2 Oct 1996 18:11
Picon

Re[2]: X.509 Bug Regarding Policy Constraints

nick, i assume that you are unhappy with the solution proposed by the defect. do
you agree that there is a defect in the standard concerned with the handling of
policySet? if so, a defect would seem to be the appropriate way of handling it.

if we could come to a successful resolution of the defect, i hope to get an
approved tc in time for incorporation into the published standard (using the
delay imposed by the itu approval period)

  hoyt
_______________________________________________________________________________
Subject: Re: X.509 Bug Regarding Policy Constraints
From:    Nick Pope <pope <at> secstan.demon.co.uk> at AZ05-SMTP
Date:    10/2/96  8:42

In reply to your message of 23 Sep 96, 16:44:

I disagree that making this change is appropriate to a defect.  It is removing 
functions from the agreed X.509 amendment.

Removing policySet from the extension no longer makes it possible to 
restrict the policies which may be governed by a CA.

The appropriate resolution is to describe how the field is used not 
remove agreed functionality.

Nick Pope

> An error has been uncovered regarding policy constraints in the X.509
> certificate extensions amendment.  I have drafted the attached defect
> report for consideration at the October meeting of the ISO/IEC/ITU
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Jueneman | 2 Oct 1996 19:56
Picon
Favicon

Re: X.509 validity period -Reply

I have to add my two cents to Michael Roe's comments.

I think that it is absurd that we are still trying to save bits in some of these fields. Using 
generalized time everywhere, instead of UTC time, is something that should have been
fixed when we went to V3. The self-describing nature of ASN.1 would have made it easy,
and there weren't more than a small handful of certificates in existence, so backward
compatibility wouldn't have been a serious issue. Unfortunately, at the snail's pace with
which most standards progress, 2000 will be here before we get a fix, so ad hoc solutions
are going to be required. Maybe by 2100?

>> This necessitates the validity period of the certificates to be 
>> potentially longer than 50 years. 

>Actually, I believe that it isn't necessary for the validity period to be
longer than 50 years, this arises out of the discussion we had on what
the validity period actually means. Revocation information is guaranteed to
be available in the Directory (if you have one :-) ) during the validity period,
but may be available by other means after the end of the validity period.
Thus, is may be possible to verify a historical document long after its
accompanying certificate has expired.

I don't think Michael's comments were strong enough. (Maybe he was just 
exercising admirable British understatement and restraint. :-)

I believe it would be completely unreasonable to have a certificate validity 
period anywhere near 50 years. The primary purpose of the validity period is,
IMHO, to provide a limit as to the amount of bookkeeping that has to be done 
by a CA or trusted repository provider in terms of CRL management. If very
many certificates had 50 year validity periods, and were ever revoked, those
certificates would have to be included in the CA's CRL list for the next 50 years,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Williams | 2 Oct 1996 21:46
Picon
Favicon

RE: X.509 validity period -Reply

Bob,

We have offered clients, who have signed document longetivity requirements, that as
their CA, we put an additional field in the cert, namely a generalized time. This is not
used in practical signature validation, but, for no measurable cost, can be used as
another piece of ammunition in dispute handling, should there be any ambiguity claims.
As, in US law, *everything* is up for claim and counter-claim anyway, its the presence of additional
ammunition which practically matters when dispute handling, surely.

The number of clients who have required this service, given the informed choice, is zero. 
Perhaps this will change. We have also recommend to them that they date any material which
they sign if they intend the message signature to be contested in a law
setting, regardless of certs and signatures, etc. Its just good legally oriented
risk management.

In the case of CA signing their messages (namely certs) a commercial
CA has to maintain auditable records anyway, whose storage properties
are used (not arguable data element) to provide high-end assurnaces for
highly-contested evidence. ONe can argue that a 50 year ssigned-dlcument 
torage would be required to demonstrate such care, also, as its
unlikely the keying material or algoirhtm will be strong
enough over 50 years, anyway.

Remember, not everyone wants high-end assurnaces, or the
costs. Forcing high-end security on folk is like
ramming X.400 down  everyone's throat. It just
will not work.

The std currently allows for both *(and any additional) time services, each used when
there is need.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Warwick Ford | 2 Oct 1996 23:50
Picon

Re: X.509 Bug Regarding Policy Constraints

Nick:

The proposal is to remove policySet from the policy constraints extension -
not the certificate policies extension.  How do you see this impacting the
ability to restrict the policies that may be governed by a CA?

Warwick

At 09:39 AM 10/2/96 +0000, Nick Pope wrote:
>In reply to your message of 23 Sep 96, 16:44:
>
>I disagree that making this change is appropriate to a defect.  It is removing 
>functions from the agreed X.509 amendment.
>
>Removing policySet from the extension no longer makes it possible to 
>restrict the policies which may be governed by a CA.
>
>The appropriate resolution is to describe how the field is used not 
>remove agreed functionality.
>
>Nick Pope
>
>> An error has been uncovered regarding policy constraints in the X.509
>> certificate extensions amendment.  I have drafted the attached defect
>> report for consideration at the October meeting of the ISO/IEC/ITU
>> Directory group. I would appreciate hearing from anyone who objects to
>> policySet being deleted from policy constraints.
>> 
>> Thanks to John Pawling of JG VanDyke for finding the error.  
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kaye Caldwell | 2 Oct 1996 23:43
Picon

** 10/8 Digital Signatures Working Group Meeting ** RSVP REQUIRED

Apologies for duplicates - some of you I'm sure are on multiple notice lists
for this.

California Digital Signature Regulations Working Group
sponsored by the Software Industry Coalition and CommerceNet

THIS MEETING IS OPEN TO ANYONE WHO WISHES TO ATTEND
However, you MUST let me know if you will be attending via e-mail to:
kaye <at> ix.netcom.com or by replying to this message.
Those who RSVP will receive e-mail on the exact location and directions to
the meeting.  (Sorry about that but we MUST have a fairly accurate RSVP
count since the host is being so kind as to supply us with a working lunch.)
PLEASE RSVP by the end of the day on Thursday 10/3/96.

WHEN: Tuesday October 8th, 9:30 AM - 1 PM  (Working lunch will be provided.)
WHERE: Cupertino, CA

Note: For those of you trying to schedule these meetings, we are meeting
every other Tuesday, sometimes in the am, sometimes in the pm, usually in or
close to Silicon Valley. 

AGENDA 

I. Report on status of Secretary of State's Task Force 
II. Review of current draft of outline of regulations
III.  Consideration of additional topics: what is publication, what are
liability issues for subscriber

Web page for Background on the Working Group:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anil R. Gangolli | 3 Oct 1996 06:57
Picon

Re: X.509 implementation notes

On Oct 3,  3:02pm, <pgut001 <at> cs.auckland.ac.nz> wrote:
 > Subject: X.509 implementation notes

Thanks for posting these remarks.  Here are some comments.  I have
only included the relevant parts of your posting.

 > There appears to be some confusion about what format a Name in a certificate
 > should take.  In theory it should be a full, proper DN, which traces a path
 > through the X.500 DIT, eg:
 >
 > C=US/L=Area 51/O=Hanger 13/OU=X.500 Standards Designers/CN=John Doe
 >
 > but since the DIT's usually don't exist, exactly what format the DN
 > should take seems open to debate.  Some implementations seem to let
 > you stuff anything with an OID into a DN.
 >
 > => Are there any guidelines for this?
 >
 > DN's are a very awkward way to handle information about a certificate
 > because most people will want to associate an email address and a name
 > with a certificate and no more.  If you want to take the easy way out,
 > use an empty sequence for the subjectName, provide an email address as
 > a subjectAltName extension, and mark it critical.
 >

I would encourage everyone to start taking DNs and their use in
certificates seriously, and structuring their names accordingly.

There are a number of companies (including Netscape) that have
announced LDAP-based directory servers and I believe we can expect to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane