Subject: ** Nov. 5 Calif. Dig. Sig. Working Group Meeting **
From: Kaye Caldwell <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 31 Oct 1996 08:42:12 -0800

Interested Parties:

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

California Digital Signatures Regulations Working Group
=========================================
(sponsored by the Software Industry Coalition and CommerceNet)
         (Note: the Working Group is not the Task Force)

         MEETING DATE: Tuesday November 5, 9:30 AM - 12: 30 PM
MEETING LOCATION: Palo Alto, California

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:
[email-masked] 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 in order
to be sure we have adequate meeting space.)

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 regulations.
III. Topic: Non-repudiaton (if time allows).

Web page for Background on the Working Group:

 http://www.softwareIndustry.org/coalition/dswgopen.html

Digital Signature Background page:

http://www.softwareIndustry.org/issues/1digsig.html

For more information, e-mail Kaye Caldwell at [email-masked] or call
408-479-8743.

Kaye Caldwell
Software Industry Coalition Policy Director
CommerceNet Adovocacy and Public Policy Committee Chair

Date: Wed, 30 Oct 1996 15:40:02 -0500
To: FC97 Announcement List <[email-masked]>
From: Robert Hettinga <[email-masked]>
Subject: Financial Cryptography 1997 (FC97): General Announcement

=46inancial Cryptography 1997 (FC97):
The world's first financial cryptography conference, workshop, and exhibitio=
n!

General Announcement

Conference, and Exhibition,
=46ebruary 24-28, 1997

Workshop for Senior Managers and IS Professionals
=46ebruary 17-21, 1997

The Inter-Island Hotel
Anguilla, BWI

The world's  first peer-reviewed conference on financial cryptography,
=46C97, will be held Monday through Friday, February 24-28, 1997, from 8:30a=
m
until 12:30pm, at the Inter-Island Hotel on the Carribbean island of
Anguilla.

In conjunction with the conference, the Inter-Island Hotel will also be the
site of an intensive 40-hour workshop for senior managers and IS
professionals, during the week preceeding the conference (February 17-21),
and an exhibition for financial cryptography vendors, from 10am-6pm during
the week of conference itself.

The goals of the combined conference, workshop, and exhibition are to
provide a peer-reviewed forum for important research in financial
cryptography and the effects it will have on society,  to give senior
managers and IS professionals a solid understanding of the fundamentals of
strong cryptgraphy as applied to financial operations on public networks,
and to showcase the newest products in the field. In addition, plenty of
time has been left open in the afternoon and evening for sponsored
corporate functions and activities, for business networking, and, of
course, for recreational activities on Anguilla itself.

As one of the principals of the conference joked, "We hope that people will
treat the conference and the other activities more as a working vacation,
rather than, er, vacating work."

Conference participants are encouraged to bring their families.

The Conference

Ray Hirschfeld, the conference chair, has picked an outstanding group of
professionals and researchers, in financial cryptography, and in related
fields, to review the papers for this conference.

They are:

Chairman: Rafael Hirschfeld, CWI, Amsterdam, The Netherlands

Matthew Franklin, AT&T Laboratories--Research, Murray Hill, NJ, USA
Michael Froomkin, U. Miami School of Law, Coral Gables, FL, USA
Arjen Lenstra, Citibank, New York, NY, USA
Mark Manasse, Digital Equipment Corporation, Palo Alto, CA, USA
Kevin McCurley, Sandia Laboratories, Albuquerque, NM, USA
Charles Merrill, McCarter & English, Newark, NJ, USA
Clifford Neuman, Information Sciences Institute, Marina del Rey, CA, USA
Sholom Rosen, Citibank, New York, NY, USA
Israel Sendrovic, Federal Reserve Bank of New York, New York, NY, USA

Some of the names may be recognizable to you. But, if they're not, included
in that list are the inventor of Millicent, the head of EU's CAFE digital
cash project, the holders of Citicorp's digital cash patent, two famous
scholars in cryptography and digital commerce law, the Chair of Eurocrypt
'96, and the Chairman of the Taskforce on the Security of Electronic Money
for the Bank for International Settlements.

If we'd gotten any more talent, we couldn't have had a conference, because
the committee can't review the work of it's own members!

The actual agenda of the conference will be determined by the papers the
program committee selects, so we won't have a final schedule for the
conference until the middle of January. However, the conference committee
is selecting papers in what it considers the union, and not the
intersection, of the fields of finance and cryptography.

Examples of topics it will consider are:

    Anonymous Payments                      Fungibility
    Authentication                          Home Banking
    Communication Security                  Identification
    Conditional Access                      Implementations
    Copyright Protection                    Loss Tolerance
    Credit/Debit Cards                      Loyalty Mechanisms
    Currency Exchange                       Legal Aspects
    Digital Cash                            Micropayments
    Digital Receipts                        Network Payments
    Digital Signatures                      Privacy Issues
    Economic Implications                   Regulatory Issues
    Electronic Funds Transfer               Smart Cards
    Electronic Purses                       Standards
    Electronic Voting                       Tamper Resistance
    Electronic Wallets                      Transferability

=46inancial Cryptography '97 is held in cooperation with the
International Association for Cryptologic Research. The conference
proceedings will be published on the web by the Journal for Internet
Banking and Commerce. <http://www.arraydev.com/commerce/JIBC/>.

=46or further information on submitting a paper to the FC97, and other
details about the program of the conference, please see program committee's
web-page at <http://www.cwi.nl/conferences/FC97>.

On the lighter side, the conference will be covered by Wired Magazine, and
will be the featured conference in it's January 1997, (ahem...) "Deductible
Junkets" section. So, you might want to register, and make your plane and
hotel reservations, before the rush begins...

The price of a pass to the conference sessions and exhibits is $1,000 U.S.

(Since we're on Anguilla, and there are no taxes of any kind, we thought
we'd keep prices in nice round numbers, just to make things interesting.
:-).)

The price includes breakfast at the conference, some stipends for
presenters who need them, and the logistics of having a professional
conference with high-bandwidth internet connectivity in a location like
Anguilla. In looking around, however, the conference organizers *did*
notice that FC97 price is in keeping with other business and professional
technology conferences of similar total session length, so everything seems
to work out. The market *is* efficient, after all.

You can register, and pay for, your conference ticket at:

<http://www.offshore.com.ai/fc97/>

The Exhibition

Concurrent with the conference will be the the FC97 Exhibition, a small
trade show for financial cryptography products and services. Each booth
will have high bandwidth access to the internet (yes, there *are* T1s in
Anguilla), and will get 2 conference passes. Booth prices start at $5,000
US. Please contact Julie Rackliffe at <mailto: [email-masked]> for
further information . As space is limited, please register as soon as
possible if you plan to be there.

The Workshop

We are especially honored to have Ian Goldberg as the leader of the FC97
Workshop, which will run one week prior to the conference, February 17-21,
1997.

Ian, the cryptographer at Berkeley who was made famous last year (in
articles in both the Wall Street Journal and the New York Times) for
breaking Netscape's transaction security protocols, will be running an
intensive, 5-day workshop for senior managers and technology professionals.

While the workshop is still being developed, and will depend on the skills
of the planned participants, workshop topics will include, but not be
limited to:

The Internet (depending on the background of the participants)
Overview and background of cryptography
Survey of existing and proposed Internet payment systems
Details on some specific payment systems
Issues involved in setting up a secure Internet site

And, depending on whether Ian finishes coding it (it looks likely), a
step-by-step walkthrough of setting up an ecash-enabled Web server.

Ian has recruited strong roster of instructors with credentials similar to
his own, and, as he plans to maintain a 5-1 student/teacher ratio, the size
of the workshop will be restricted and 2 months advance registration well
be required.

=46urther information about the workshop can be found at:

<http://www.cs.berkeley.edu/~iang/fc97/workshop.html>

The planned price for the workshop is $5,000. This covers lab space,
hardware, network access, software, and, of course, 40 hours of instruction
and structured lab activity. The lab itself will be open 24 hours a day, if
demand warrants it.

Sponsorship Opportunities

=46C97 offers many exciting sponsorship opportunities at all levels.
Corporations are encouraged to to be an exclusive sponsor for lunch or
dinner, each of which will be followed by a recreational activity of some
kind. Sponsors will have the opportunity to permanently attach their name
to these important networking functions, which the organizers hope will be
a large part of the conference experience. There are 10 such events being
planned, and 10 corporations will be accepted for sponsorship. Corporate
sponsors of these events will also get a substantial initial discount on
exhibit space, and complementary conference tickets.

In-kind sponsorship is available at all levels of support, with
opportunities for companies to provide networking, bandwidth, hardware,
radio pocket modems and equipment, as well as design and print services,
transportation, entertainment, catering, sunscreen and, well, if you've got
it and you think we'll need it, let us know about it -- we probably do.

Please contact Julie Rackliffe at <mailto: [email-masked]> for further
sponsorship information.

Air Transportation and Hotels

Air travel to Anguilla is typically done through either St. Thomas for US
flights, or St. Maarten/Martin for flights from Europe. Several non-stop
flights a day from various US and European locations can be made to either
destination. Connection through to Anguilla can be made through American
Eagle, or through LIAT. See your travel agent for details. American Eagle
Airlines has agreed to increase their flights as needed to accomodate any
extra traffic the conference brings to the island.

Anguilla's runway is 3600 feet, with a displaced threshold of 600 feet, and
can accomodate business jets. Obviously, you should talk to your own FBO
for details about your own aircraft's capabilities in this regard.

Anguilla import duties are not imposed on hardware or software which will
leave the island again, so, as long as you take it with you when you leave
you won't pay taxes for leaving it there.

Hotels range from spartan to luxurious, and more information about hotels
on Anquilla can be obtained from your travel agent, or at
<http://offshore.com.ai/>.

Why Anguilla?

We picked Anguilla for two reasons, both of them mildly political. The
first is, of course, the US ITARs, which classify cryptography as a
"munition" and restrict it's export. Thus, every effort will be made to
highlight the absurdity of these regulations through the use of foriegn
software, "leaked" software, and, of course, where necessary, US-exportable
"crippleware", in the networking and server software of the conference and
workshop. Of course, the conference content itself is not a violation of
the ITARs, as the "munitions" being exported are in the heads of the
attendees, or on paper, and thus not (typically!) subject to the US ITARs.
Consider it a mild tweak on the nose of the Clinton Administration, in an
era of 56-bit exportable keysize maxima.

The other mildly political reason is that Anguilla is a tax haven. There
are no taxes except import duties. None. No income, capital gains, sales,
excise, or property taxes -- none. Anguilla's banking secrecy laws are about
the finest there are anywhere.

This is important to the organizers of the conference because most of the
other proposed regulations of financial cryptography, particularly those of
"token", or "note" based systems, are because they enable cash settlement,
even perfectly anonymous cash settlement, of transactions of practically
any size. Economic reality is not optional; if, in fact, the significantly
reduced cost of these technologies make auditable "book-entry" transaction
settlement obsolete, then there isn't much that the taxation or
law-enforcement authorities of the world's nation-states can do about it.
We consider countries like Anguilla an existance proof of the concept. Any
attempt to restrict these technologies will only backfire on nations
attempting to do so. Nation-states will simply have to develop taxation and
law enforcement methods other than auditing book-entries. In fact, most
central bankers and financial crime enforcement professionals who
understand the technology also realize this, so, of course, our point is
only *mildly* political, at this stage of the argument, anyway.

Of course, the fact that Anguilla's average daytime temperature in February
is in the low 80's farenheit, and that of, say, Boston, is in the low 20's,
and the fact that cyclonic storms are in the *other* hemisphere that time
of year, has *nothing*, we say, *nothing* to do with our decision to hold a
conference there. We're simply shocked you would suggest such a thing.
Neither, for that matter, does the fact that the average water visibility
on Anguilla's coral reefs can be measured in hundreds of feet (if you can
see that far for the blinding riot of color, that is...).

Registration for FC97

Again, if you're interested in coming to FC97 see:

<http://www.offshore.com.ai/fc97/>

=46or information on presenting papers at FC97 see:

<http://www.cwi.nl/conferences/FC97>

If you're interested in Exhibit space, please contact Julie Rackliffe:

<mailto:[email-masked]>

If you're interested in sponsoring FC97, also contact Julie Rackliffe:

<mailto:[email-masked]>

If you're interested in the FC97 Workshop for Senior Managers and IS
Professionals, see:

<http://www.cs.berkeley.edu/~iang/fc97/workshop.html>

See you in Anguilla!

The FC97 Organizing Committee

Vince Cate and Bob Hettinga, General Chairs
Ray Hirschfeld, Conference Chair
Ian Goldberg, Workshop Chair
Julie Rackliffe, Conference, Exhibit, and Sponsorship Manager

-----------------
Robert Hettinga ([email-masked])
e$, 44 Farquhar Street, Boston, MA 02131 USA
"The cost of anything is the foregone alternative" -- Walter Johnson
The e$ Home Page: http://www.vmeng.com/rah/

-----------------
Robert Hettinga ([email-masked])
e$, 44 Farquhar Street, Boston, MA 02131 USA
"The cost of anything is the foregone alternative" -- Walter Johnson
The e$ Home Page: http://www.vmeng.com/rah/

Subject: Re: X.509 key usage -Reply -Reply
To: Bob Jueneman <[email-masked]>
Date: Fri, 25 Oct 1996 06:53:09 +0100 (BST)
From: Ben Laurie <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Content-Length: 632       

Bob Jueneman wrote:
> This is not just a US issue, of course. Following the leadership
> of the French, the entire European community seems poised to 
> adopt the Royal-Holloway plan, which would require trusted 
> third party key escrow for all encrypted communications.

Really? News to me ... do you have a reference?

Cheers,

Ben.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: [email-masked]
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.            Apache Group member (http://www.apache.org)

Date: Thu, 24 Oct 1996 16:54:05 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: X.509 key usage -Reply -Reply -Reply

Peter, I'll forgive you the pejorative "crippled" adjective, as what 
we are trying to do is "uncripple" applications through an arguably 
reasonable set of political compromises or tradeoffs.

My real question was not necessarily aimed at whether we should 
submit an amendment to ISO, but rather whether there is anything we 
should do within the IETF to standardize on some of these usages.

Since you are the only one who has responded, I don't know
whether that means that everyone else in PKIX agrees with you, 
or that no one else cares one way or the other, or that everyone is
busy doing something else.

If the consensus is that this is not something that the IETF wants 
to deal with, then I won't feel bad taking it to more specialized groups 
such as the various alliances and consortiums that are forming, 
e.g., PICA. But I believe that will inevitably start to chip away at the 
relevance of the PKIX group and its efforts to date, so we should 
probably think about that for a while before jumping to a conclusion.

Bob

>>> Peter Williams <[email-masked]> 10/24/96 04:33pm >>>
Bob,

Should providers of crippled software coordinate to standardize their
enforcement labels - you ask. Of course. 

The purpose of the ISO key usage field does not serve to constrain "application"
purpose for a given key; it controls the X.800 mechanism only. If you want
an applicationKeyUsage extension, then define one. Then you
can super-constrain a signing key to only signing "passwords" over
"risk-level A" transactions, or any other community-defined label
designating the application of signing.

ISO has defined some std X.509 extensions, which exist for all layers of the stack
(not just application) which apply keying material, independent of application, environment
or layer purpose. Of course, one now defines per-application exensions for per-application
controls. If a class of application (e.g. export-crippled)  requires another suite
of class-common extensions, then one gets NSA/NIST or some other body
to specify and embody that new set of common-extensions for enforcing
crippled-export grade software. This is just as Microsoft defined a class of
"software-publisher" extensions for that class of application component. Similarly
by Netscape, for its https community.

From: Peter Williams <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 key usage -Reply -Reply
Date: Thu, 24 Oct 1996 15:33:42 -0700

Bob,

Should providers of crippled software coordinate to standardize their
enforcement labels - you ask. Of course. 

The purpose of the ISO key usage field does not serve to constrain "application"
purpose for a given key; it controls the X.800 mechanism only. If you want
an applicationKeyUsage extension, then define one. Then you
can super-constrain a signing key to only signing "passwords" over
"risk-level A" transactions, or any other community-defined label
designating the application of signing.

ISO has defined some std X.509 extensions, which exist for all layers of the stack
(not just application) which apply keying material, independent of application, environment
or layer purpose. Of course, one now defines per-application exensions for per-application
controls. If a class of application (e.g. export-crippled)  requires another suite
of class-common extensions, then one gets NSA/NIST or some other body
to specify and embody that new set of common-extensions for enforcing
crippled-export grade software. This is just as Microsoft defined a class of
"software-publisher" extensions for that class of application component. Similarly
by Netscape, for its https community.

 ----------
From: 	Bob Jueneman
Sent: 	Thursday, October 24, 1996 8:38 AM
To: 	[email-masked]
Cc: 	[email-masked]
Subject: 	RE: X.509 key usage -Reply -Reply

Peter,

I understand that the IETF community views the entire issue of key 
escrow with some repugnance, to say the least. Yet key escrow, 
at least some form of self-escrow, is increasingly a commercial 
requirement to ensure the continuity of a business in the event
an employee dies or is incapacitated, and never mind the possibility
of fraud and other criminal acts.

In addition, the international community certainly needs and deserves
better than 40 bit encryption -- I don't think there is any question about
that.

So if the US vendor community is going to try to satisfy those
requirements, rather than foregoing what in many cases amounts to 
50% of a vendor's revenue, then something has to be done. I'm not
crazy about the administration's current compromise proposal,
but it may be the best deal that we are able to get. 

This is not just a US issue, of course. Following the leadership
of the French, the entire European community seems poised to 
adopt the Royal-Holloway plan, which would require trusted 
third party key escrow for all encrypted communications.

So even the Swiss, South African, Japanese, etc. vendors 
will ultimately be faced with this question, either at the export level
or at time of import, or both.

The question, then, is whether Novell, Microsoft, IBM, Nortel, etc.,
should all go their own way and implement proprietary key
usage labels for these functions, or whether we should 
attempt to standardize them.

Remember, it isn't only the cryptographic function provider 
that is impacted by these functions, it is every application 
developer that wants to ease his own application's export
process that is affected. If we do nothing, then it is likely that 
every cryptography vendor will implement these functions 
differently, which would mean that applications being 
developed for different platforms and/or crypto API would 
probably have to be modified for each. This doesn't seem 
desirable.

Finally, I believe that a further refinement of the key usage flags 
may be of some benefit completely outside of the export/import
arena. The more specific a user can be regarding the intended 
usage of a key, the less likely it is that a key compromise 
will have far reaching consequences.

A key that is intended for use for signing modules, or for protecting
passwords, should not be used for digitally signing high-value
documents, and if someone presents a document that was 
allegedly signed with such a key, it should be rejected as an 
inappropriate usage. This helps to protect both the user and the CA.

So Peter, please go back and consider the proposed key usages for their
own sake, and if you choose to ignore the export/import issues (since
VeriSign is not developing software for export, to my knowledge),
I will understand.

Bob

>>> Peter Williams <[email-masked]> 10/22/96 05:57pm >>>
I honestly believe its not in the scope of an international interworking
standard to specify a mechanism for enforcing import/export
policy for products.

Its prefectly reasonable for a govt to specify a national extension that to
satisfy export regulations, a given NSA/NIST-registered extension shall be used,
and it shall be enforced by the end-system being exported. its also
a reasonable requirement, that the export-granting authority state the
rules for uniform treatment of export requests, under the law.

This approach to mandating escrow assumes that one can find a UA product which
conforms to X.509, and  v3 criticality, and the enforcement mechanism, of
course. To rely upon such a mechanism would require the exporter to make/undertake
a claim of conformance!

Perhaps, now, Im beginning to like the escrow and export issues. We
can get the export system to police such conformance. Export approval
can be used as defacto certification statement, without vendors having to bear the
costs of third-party evaluation.

----------
From: 	Bob Jueneman
Sent: 	Monday, October 21, 1996 11:08 AM
To: 	[email-masked]; [email-masked]
Cc: 	[email-masked]
Subject: 	RE: X.509 key usage -Reply

Peter asks a very valid, if troubling question. What keyUsage purposes should be
standardized, and which would be proprietary extensions?

Over the weekend, when Hoyt, Warwick, and I were attending the ABA 
Information Security committee meeting,  I observed that the import/export
people tended to differentiate between different kinds of key usages, 
and that getting export (or import, in the case of France, for example) 
approval would tend to be easier or harder based on the key usage 
and the degree to which different key usages were enforced.

To my knowledge, the various categories of key usage that they are 
concerned about would be the following (in approximately increasing
order of concern):

1.  Asymmetric private keys used for digital signatures (the burden of 
proof is on the applicant to show that such a key could never be used for
encryption).

2. Asymmetric or symmetric encryption keys used to protect intellectual 
property, such as an unlocking key for software encryption or for license
enforcement.

3. Asymmetric or symmetric encryption keys used for authentication, 
e.g., to protect passwords. I would hope, but cannot be sure, that 
the same status would be applied to keys used to communicate the 
secret variable used in salted hash algorithms and for secret-key MAC 
algorithms.

4. Encryption keys used to protect financial data exclusively, in particular
credit card numbers and similar data.

5. Key management keys used to protect working keys.

6. Protocol-specific encryption keys, where the raw key is never exposed 
to the user.

7. General, unrestricted usage data encryption keys.

We already have key usage bits defined for some of those usages, but
some are missing. Since inspectability and some form of a common 
enforcement mechanism might significantly ease the burden of export 
control, it seems to me that it might be worthwhile to define keyUsage bits 
for licensing/intellectual property protection, authentication encryption, 
financial data protection, and non-extractable keys (keys that cannot be 
presented to the user in the clear).

I haven't read X.800, but I strongly suspect that these usages would not 
fit that model.

The more important question, I believe, is whether that model should govern
such usages, or not. What do others think?

Bob

>>> Peter Williams <[email-masked]> 10/21/96 10:31am >>>
 
The key usage controls have to date restricted themselves to purpose/usages
which control the X.800 mechanism to which relate. To add send/receive
parameters breaks the layering model of X800 : services, mechanisms, facilities.

If we fail to hold this line, then there should be a general community-controlled
syntax for key usage, as there are a hundred usages which could be so coded as
keyUsage  bits for selection by key purpose.

I desire to control the selection of key, based on key length. So, lets have a bit
for 1024 size keys, versus 1028 bit keys. I desire to have select a public
key based on it being based on it being implemented only in a spyrus lynx
token. So lets have a bit for lynx token... lets have a bit whose for "known to
have escrowed private key", etc.

Why does selection for purpose send/receive (when encrypting/decrypting) merit
special attention at this mechanism/key-usage enforcement control point? 

As the requirement has been identified in a UK NHS pilot, why is there
need for international standardization? Could one not use a v3
application extension, defined locally, to control UK NHS send/receive policy
on key usage and selection?

Furthermore, has not the (long) comment period closed, except for minor editorial
bugs?

Peter.

----------
From: 	Nick Pope
Sent: 	Saturday, October 19, 1996 2:57 PM
To: 	'Denis Pinkas'; Peter Williams
Cc: 	[email-masked]
Subject: 	RE: X.509 key usage

In reply to your message of 18 Oct 96, 10:20 from Peter Williams:

Peter,

The reason for the required key usage flag is not from the view point 
of access control.  It is to enable the public key 
certificate to be selected for a specific usage.  If it is required 
to that different public key can be selected: 
a) to generate a key for decryption of data from the certified entity 
as sender,
b)  to generate the key used to encrypt data to the same entity as a 
recipient.

There is a need for a "key usage" flag in the certificate so that the 
appropriate public key can be selected.

I agree with Denis' suggestion to describe the usage in terms of 
generation of key used for encrypt / decrypt instead of send / 
receive may be more general.

Nick

> Denis,
> 
> I agree with you on the inappropriateness of the solution.
> 
> I understand X.800/509 to say that if the environment requires
> *application* of keying material to be restricted in its use for the
> purpose of establishing or using a named channel, then conventional
> access controls are used, not key usage controls.  The purpose of
> the application is, after all, just enforcement of access control to
> the channel's transport and connection- establishment capability.
> 
> Key usage control security mechanisms do not instrument an access
> control service, per se. If access control information is placed in
> an I&A certificate and used by an access control enforcment
> mechanism which is based on a cryptogprahic separation facility,
> then one uses an extension (or separate cert) for conventional
> statement of the access control information. As usual, such
> information constrains channels, classifications and compartments in
> a lattice designed to constrain the desired policy. Of course the
> lattice function is evaluated during a secure key exchange/agreement
> protocol.
> 
> The logical purpose of key usage controls is to control the raw
> encryption/decryption facility of an algorithm,  so that is
> correctly supports the required security mechanism when enforced by
> a trusted cryptotoken.
> 
> So I dont disgaree with Nick Pope on the need or enviornment of
> application of the access enforcement, but on the choice/placement
> of mechanism which which to signal the control information.
> 
> Peter.
> 
> 
> 
> To: 	Nick Pope
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: X.509 key usage
> 
> 
> 
> > A requirement has been identified in the UK for the use of 
> > public key certificates with a key agreement mechanism which uses
> > different Diffie-Hellman public keys for data sent and received.
> 
> While I agree to support Diffie-Hellman keys, the kind of use which
> is mentionned is not fully appropriate. Although the immediate need
> for the UK is to send and receive data, this is not the elementary
> use which can be made by these keys. It would be possible to use
> these keys to support long term encryption so that, for example to
> locally encrypt a contract that two parties would be able to read in
> the future, without sending or receiving it today, but simply
> storing it.
> 
> 
> > This requires additional key usage flags in the key usage 
> > extension fields.
> > 
> > 11.	Solution Proposed by the Source:  (optional)
> > 
> > Add to Key Usage BIT STRING
> > 		send         (7),
> > 		receive      (8) }
> > 
> > Add to end of item list:
> > 
> > 	h) send: for protecting data sent from the subject 
> > 		(used with key agreement)
> > 	i) receive: for protecting data for receipt by the 
> >             subject (used with key agreement)
> 
> The usage should be expressed in terms of encryption/decryption, not
> in terms of send /receive.
> 
> 
> Denis
> 
> 
> -- 
> 
> ====================================================================
> ========
>       Denis Pinkas                           E-mail :
>       [email-masked] Bull S.A.                               
>                                    Rue Jean Jaures  B.P. 68         
>             Phone : (33-1) 30 80 34 87 78340 Les Clayes sous Bois.
>       FRANCE       Fax  : (33-1) 30 80 33 21
> ====================================================================
> ========
> 
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

Date: Thu, 24 Oct 1996 09:38:17 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: X.509 key usage -Reply -Reply

Peter,

I understand that the IETF community views the entire issue of key 
escrow with some repugnance, to say the least. Yet key escrow, 
at least some form of self-escrow, is increasingly a commercial 
requirement to ensure the continuity of a business in the event
an employee dies or is incapacitated, and never mind the possibility
of fraud and other criminal acts.

In addition, the international community certainly needs and deserves
better than 40 bit encryption -- I don't think there is any question about
that.

So if the US vendor community is going to try to satisfy those
requirements, rather than foregoing what in many cases amounts to 
50% of a vendor's revenue, then something has to be done. I'm not
crazy about the administration's current compromise proposal,
but it may be the best deal that we are able to get. 

This is not just a US issue, of course. Following the leadership
of the French, the entire European community seems poised to 
adopt the Royal-Holloway plan, which would require trusted 
third party key escrow for all encrypted communications.

So even the Swiss, South African, Japanese, etc. vendors 
will ultimately be faced with this question, either at the export level
or at time of import, or both.

The question, then, is whether Novell, Microsoft, IBM, Nortel, etc.,
should all go their own way and implement proprietary key
usage labels for these functions, or whether we should 
attempt to standardize them.

Remember, it isn't only the cryptographic function provider 
that is impacted by these functions, it is every application 
developer that wants to ease his own application's export
process that is affected. If we do nothing, then it is likely that 
every cryptography vendor will implement these functions 
differently, which would mean that applications being 
developed for different platforms and/or crypto API would 
probably have to be modified for each. This doesn't seem 
desirable.

Finally, I believe that a further refinement of the key usage flags 
may be of some benefit completely outside of the export/import
arena. The more specific a user can be regarding the intended 
usage of a key, the less likely it is that a key compromise 
will have far reaching consequences.

A key that is intended for use for signing modules, or for protecting
passwords, should not be used for digitally signing high-value
documents, and if someone presents a document that was 
allegedly signed with such a key, it should be rejected as an 
inappropriate usage. This helps to protect both the user and the CA.

So Peter, please go back and consider the proposed key usages for their
own sake, and if you choose to ignore the export/import issues (since
VeriSign is not developing software for export, to my knowledge),
I will understand.

Bob

>>> Peter Williams <[email-masked]> 10/22/96 05:57pm >>>
I honestly believe its not in the scope of an international interworking
standard to specify a mechanism for enforcing import/export
policy for products.

Its prefectly reasonable for a govt to specify a national extension that to
satisfy export regulations, a given NSA/NIST-registered extension shall be used,
and it shall be enforced by the end-system being exported. its also
a reasonable requirement, that the export-granting authority state the
rules for uniform treatment of export requests, under the law.

This approach to mandating escrow assumes that one can find a UA product which
conforms to X.509, and  v3 criticality, and the enforcement mechanism, of
course. To rely upon such a mechanism would require the exporter to make/undertake
a claim of conformance!

Perhaps, now, Im beginning to like the escrow and export issues. We
can get the export system to police such conformance. Export approval
can be used as defacto certification statement, without vendors having to bear the
costs of third-party evaluation.

----------
From: 	Bob Jueneman
Sent: 	Monday, October 21, 1996 11:08 AM
To: 	[email-masked]; [email-masked]
Cc: 	[email-masked]
Subject: 	RE: X.509 key usage -Reply

Peter asks a very valid, if troubling question. What keyUsage purposes should be
standardized, and which would be proprietary extensions?

Over the weekend, when Hoyt, Warwick, and I were attending the ABA 
Information Security committee meeting,  I observed that the import/export
people tended to differentiate between different kinds of key usages, 
and that getting export (or import, in the case of France, for example) 
approval would tend to be easier or harder based on the key usage 
and the degree to which different key usages were enforced.

To my knowledge, the various categories of key usage that they are 
concerned about would be the following (in approximately increasing
order of concern):

1.  Asymmetric private keys used for digital signatures (the burden of 
proof is on the applicant to show that such a key could never be used for
encryption).

2. Asymmetric or symmetric encryption keys used to protect intellectual 
property, such as an unlocking key for software encryption or for license
enforcement.

3. Asymmetric or symmetric encryption keys used for authentication, 
e.g., to protect passwords. I would hope, but cannot be sure, that 
the same status would be applied to keys used to communicate the 
secret variable used in salted hash algorithms and for secret-key MAC 
algorithms.

4. Encryption keys used to protect financial data exclusively, in particular
credit card numbers and similar data.

5. Key management keys used to protect working keys.

6. Protocol-specific encryption keys, where the raw key is never exposed 
to the user.

7. General, unrestricted usage data encryption keys.

We already have key usage bits defined for some of those usages, but
some are missing. Since inspectability and some form of a common 
enforcement mechanism might significantly ease the burden of export 
control, it seems to me that it might be worthwhile to define keyUsage bits 
for licensing/intellectual property protection, authentication encryption, 
financial data protection, and non-extractable keys (keys that cannot be 
presented to the user in the clear).

I haven't read X.800, but I strongly suspect that these usages would not 
fit that model.

The more important question, I believe, is whether that model should govern
such usages, or not. What do others think?

Bob

>>> Peter Williams <[email-masked]> 10/21/96 10:31am >>>
 
The key usage controls have to date restricted themselves to purpose/usages
which control the X.800 mechanism to which relate. To add send/receive
parameters breaks the layering model of X800 : services, mechanisms, facilities.

If we fail to hold this line, then there should be a general community-controlled
syntax for key usage, as there are a hundred usages which could be so coded as
keyUsage  bits for selection by key purpose.

I desire to control the selection of key, based on key length. So, lets have a bit
for 1024 size keys, versus 1028 bit keys. I desire to have select a public
key based on it being based on it being implemented only in a spyrus lynx
token. So lets have a bit for lynx token... lets have a bit whose for "known to
have escrowed private key", etc.

Why does selection for purpose send/receive (when encrypting/decrypting) merit
special attention at this mechanism/key-usage enforcement control point? 

As the requirement has been identified in a UK NHS pilot, why is there
need for international standardization? Could one not use a v3
application extension, defined locally, to control UK NHS send/receive policy
on key usage and selection?

Furthermore, has not the (long) comment period closed, except for minor editorial
bugs?

Peter.

----------
From: 	Nick Pope
Sent: 	Saturday, October 19, 1996 2:57 PM
To: 	'Denis Pinkas'; Peter Williams
Cc: 	[email-masked]
Subject: 	RE: X.509 key usage

In reply to your message of 18 Oct 96, 10:20 from Peter Williams:

Peter,

The reason for the required key usage flag is not from the view point 
of access control.  It is to enable the public key 
certificate to be selected for a specific usage.  If it is required 
to that different public key can be selected: 
a) to generate a key for decryption of data from the certified entity 
as sender,
b)  to generate the key used to encrypt data to the same entity as a 
recipient.

There is a need for a "key usage" flag in the certificate so that the 
appropriate public key can be selected.

I agree with Denis' suggestion to describe the usage in terms of 
generation of key used for encrypt / decrypt instead of send / 
receive may be more general.

Nick

> Denis,
> 
> I agree with you on the inappropriateness of the solution.
> 
> I understand X.800/509 to say that if the environment requires
> *application* of keying material to be restricted in its use for the
> purpose of establishing or using a named channel, then conventional
> access controls are used, not key usage controls.  The purpose of
> the application is, after all, just enforcement of access control to
> the channel's transport and connection- establishment capability.
> 
> Key usage control security mechanisms do not instrument an access
> control service, per se. If access control information is placed in
> an I&A certificate and used by an access control enforcment
> mechanism which is based on a cryptogprahic separation facility,
> then one uses an extension (or separate cert) for conventional
> statement of the access control information. As usual, such
> information constrains channels, classifications and compartments in
> a lattice designed to constrain the desired policy. Of course the
> lattice function is evaluated during a secure key exchange/agreement
> protocol.
> 
> The logical purpose of key usage controls is to control the raw
> encryption/decryption facility of an algorithm,  so that is
> correctly supports the required security mechanism when enforced by
> a trusted cryptotoken.
> 
> So I dont disgaree with Nick Pope on the need or enviornment of
> application of the access enforcement, but on the choice/placement
> of mechanism which which to signal the control information.
> 
> Peter.
> 
> 
> 
> To: 	Nick Pope
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: X.509 key usage
> 
> 
> 
> > A requirement has been identified in the UK for the use of 
> > public key certificates with a key agreement mechanism which uses
> > different Diffie-Hellman public keys for data sent and received.
> 
> While I agree to support Diffie-Hellman keys, the kind of use which
> is mentionned is not fully appropriate. Although the immediate need
> for the UK is to send and receive data, this is not the elementary
> use which can be made by these keys. It would be possible to use
> these keys to support long term encryption so that, for example to
> locally encrypt a contract that two parties would be able to read in
> the future, without sending or receiving it today, but simply
> storing it.
> 
> 
> > This requires additional key usage flags in the key usage 
> > extension fields.
> > 
> > 11.	Solution Proposed by the Source:  (optional)
> > 
> > Add to Key Usage BIT STRING
> > 		send         (7),
> > 		receive      (8) }
> > 
> > Add to end of item list:
> > 
> > 	h) send: for protecting data sent from the subject 
> > 		(used with key agreement)
> > 	i) receive: for protecting data for receipt by the 
> >             subject (used with key agreement)
> 
> The usage should be expressed in terms of encryption/decryption, not
> in terms of send /receive.
> 
> 
> Denis
> 
> 
> -- 
> 
> ====================================================================
> ========
>       Denis Pinkas                           E-mail :
>       [email-masked] Bull S.A.                               
>                                    Rue Jean Jaures  B.P. 68         
>             Phone : (33-1) 30 80 34 87 78340 Les Clayes sous Bois.
>       FRANCE       Fax  : (33-1) 30 80 33 21
> ====================================================================
> ========
> 
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 key usage -Reply
Date: Tue, 22 Oct 1996 16:57:45 -0700

I honestly believe its not in the scope of an international interworking
standard to specify a mechanism for enforcing import/export
policy for products.

Its prefectly reasonable for a govt to specify a national extension that to
satisfy export regulations, a given NSA/NIST-registered extension shall be used,
and it shall be enforced by the end-system being exported. its also
a reasonable requirement, that the export-granting authority state the
rules for uniform treatment of export requests, under the law.

This approach to mandating escrow assumes that one can find a UA product which
conforms to X.509, and  v3 criticality, and the enforcement mechanism, of
course. To rely upon such a mechanism would require the exporter to make/undertake
a claim of conformance!

Perhaps, now, Im beginning to like the escrow and export issues. We
can get the export system to police such conformance. Export approval
can be used as defacto certification statement, without vendors having to bear the
costs of third-party evaluation.

----------
From: 	Bob Jueneman
Sent: 	Monday, October 21, 1996 11:08 AM
To: 	[email-masked]; [email-masked]
Cc: 	[email-masked]
Subject: 	RE: X.509 key usage -Reply

Peter asks a very valid, if troubling question. What keyUsage purposes should be
standardized, and which would be proprietary extensions?

Over the weekend, when Hoyt, Warwick, and I were attending the ABA 
Information Security committee meeting,  I observed that the import/export
people tended to differentiate between different kinds of key usages, 
and that getting export (or import, in the case of France, for example) 
approval would tend to be easier or harder based on the key usage 
and the degree to which different key usages were enforced.

To my knowledge, the various categories of key usage that they are 
concerned about would be the following (in approximately increasing
order of concern):

1.  Asymmetric private keys used for digital signatures (the burden of 
proof is on the applicant to show that such a key could never be used for
encryption).

2. Asymmetric or symmetric encryption keys used to protect intellectual 
property, such as an unlocking key for software encryption or for license
enforcement.

3. Asymmetric or symmetric encryption keys used for authentication, 
e.g., to protect passwords. I would hope, but cannot be sure, that 
the same status would be applied to keys used to communicate the 
secret variable used in salted hash algorithms and for secret-key MAC 
algorithms.

4. Encryption keys used to protect financial data exclusively, in particular
credit card numbers and similar data.

5. Key management keys used to protect working keys.

6. Protocol-specific encryption keys, where the raw key is never exposed 
to the user.

7. General, unrestricted usage data encryption keys.

We already have key usage bits defined for some of those usages, but
some are missing. Since inspectability and some form of a common 
enforcement mechanism might significantly ease the burden of export 
control, it seems to me that it might be worthwhile to define keyUsage bits 
for licensing/intellectual property protection, authentication encryption, 
financial data protection, and non-extractable keys (keys that cannot be 
presented to the user in the clear).

I haven't read X.800, but I strongly suspect that these usages would not 
fit that model.

The more important question, I believe, is whether that model should govern
such usages, or not. What do others think?

Bob

>>> Peter Williams <[email-masked]> 10/21/96 10:31am >>>
 
The key usage controls have to date restricted themselves to purpose/usages
which control the X.800 mechanism to which relate. To add send/receive
parameters breaks the layering model of X800 : services, mechanisms, facilities.

If we fail to hold this line, then there should be a general community-controlled
syntax for key usage, as there are a hundred usages which could be so coded as
keyUsage  bits for selection by key purpose.

I desire to control the selection of key, based on key length. So, lets have a bit
for 1024 size keys, versus 1028 bit keys. I desire to have select a public
key based on it being based on it being implemented only in a spyrus lynx
token. So lets have a bit for lynx token... lets have a bit whose for "known to
have escrowed private key", etc.

Why does selection for purpose send/receive (when encrypting/decrypting) merit
special attention at this mechanism/key-usage enforcement control point? 

As the requirement has been identified in a UK NHS pilot, why is there
need for international standardization? Could one not use a v3
application extension, defined locally, to control UK NHS send/receive policy
on key usage and selection?

Furthermore, has not the (long) comment period closed, except for minor editorial
bugs?

Peter.

----------
From: 	Nick Pope
Sent: 	Saturday, October 19, 1996 2:57 PM
To: 	'Denis Pinkas'; Peter Williams
Cc: 	[email-masked]
Subject: 	RE: X.509 key usage

In reply to your message of 18 Oct 96, 10:20 from Peter Williams:

Peter,

The reason for the required key usage flag is not from the view point 
of access control.  It is to enable the public key 
certificate to be selected for a specific usage.  If it is required 
to that different public key can be selected: 
a) to generate a key for decryption of data from the certified entity 
as sender,
b)  to generate the key used to encrypt data to the same entity as a 
recipient.

There is a need for a "key usage" flag in the certificate so that the 
appropriate public key can be selected.

I agree with Denis' suggestion to describe the usage in terms of 
generation of key used for encrypt / decrypt instead of send / 
receive may be more general.

Nick

> Denis,
> 
> I agree with you on the inappropriateness of the solution.
> 
> I understand X.800/509 to say that if the environment requires
> *application* of keying material to be restricted in its use for the
> purpose of establishing or using a named channel, then conventional
> access controls are used, not key usage controls.  The purpose of
> the application is, after all, just enforcement of access control to
> the channel's transport and connection- establishment capability.
> 
> Key usage control security mechanisms do not instrument an access
> control service, per se. If access control information is placed in
> an I&A certificate and used by an access control enforcment
> mechanism which is based on a cryptogprahic separation facility,
> then one uses an extension (or separate cert) for conventional
> statement of the access control information. As usual, such
> information constrains channels, classifications and compartments in
> a lattice designed to constrain the desired policy. Of course the
> lattice function is evaluated during a secure key exchange/agreement
> protocol.
> 
> The logical purpose of key usage controls is to control the raw
> encryption/decryption facility of an algorithm,  so that is
> correctly supports the required security mechanism when enforced by
> a trusted cryptotoken.
> 
> So I dont disgaree with Nick Pope on the need or enviornment of
> application of the access enforcement, but on the choice/placement
> of mechanism which which to signal the control information.
> 
> Peter.
> 
> 
> 
> To: 	Nick Pope
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: X.509 key usage
> 
> 
> 
> > A requirement has been identified in the UK for the use of 
> > public key certificates with a key agreement mechanism which uses
> > different Diffie-Hellman public keys for data sent and received.
> 
> While I agree to support Diffie-Hellman keys, the kind of use which
> is mentionned is not fully appropriate. Although the immediate need
> for the UK is to send and receive data, this is not the elementary
> use which can be made by these keys. It would be possible to use
> these keys to support long term encryption so that, for example to
> locally encrypt a contract that two parties would be able to read in
> the future, without sending or receiving it today, but simply
> storing it.
> 
> 
> > This requires additional key usage flags in the key usage 
> > extension fields.
> > 
> > 11.	Solution Proposed by the Source:  (optional)
> > 
> > Add to Key Usage BIT STRING
> > 		send         (7),
> > 		receive      (8) }
> > 
> > Add to end of item list:
> > 
> > 	h) send: for protecting data sent from the subject 
> > 		(used with key agreement)
> > 	i) receive: for protecting data for receipt by the 
> >             subject (used with key agreement)
> 
> The usage should be expressed in terms of encryption/decryption, not
> in terms of send /receive.
> 
> 
> Denis
> 
> 
> -- 
> 
> ====================================================================
> ========
>       Denis Pinkas                           E-mail :
>       [email-masked] Bull S.A.                               
>                                    Rue Jean Jaures  B.P. 68         
>             Phone : (33-1) 30 80 34 87 78340 Les Clayes sous Bois.
>       FRANCE       Fax  : (33-1) 30 80 33 21
> ====================================================================
> ========
> 
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

Date: Tue, 22 Oct 1996 10:40:38 +1000
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked] (Rolf Exner)
Subject: Re: X.509 validity period
Status:  O

Hi All,

I'd like to add my two cents worth to this discussion. My proposal is

- Define a version 4 Certificate with GeneralizedTime in place of UTCTime
  (no CHOICE).

- Don't do it yet, as it will destabilize X.509 adoption now to solve
  a problem we won't encounter for many years. Do it after 2005 or when we
  next have some other reason to define a version 4 certificate.

I strongly agree with Mark Bartel's point that a certificate should be
capable of validation without the original encoding being present. If there
are suddenly two representations of a v3 certificate (one using UTCTime,
one using GeneralizedTime) it complicates the validation unnecessarily. It
also makes a mockery of our new extensions mechanism for certificates (no
sooner do we have it than we find it necessary to extend a certificate in
some other way). Finally, if we need to keep the original encoding around
to validate a certificate then there's surely no need to use DER at all -
any old BER can be used, just sign the original encoding.

If a v4 is defined, then it can safely include a change to GeneralizedTime
as the presence of the v4 marker will signal the change.

There is a valid concern that changing to version 4 will make it harder to
sell the authentication community the idea of staying with X.509 or of
going to something other than v1. Changing v3 to v4 before v3 is adopted
anywhere will surely undermine confidence in X.509. It would be a real pity
to let this happen to solve a problem that is still many years away.

I therefore suggest that we define the semantics of UTCTime in certificates
as being a time within a range of 100 years (my preference would be
1950-2049), and to state that version 3 certificates cannot handle dates
beyond 2049, but that this deficiency will be addressed (via v4 or an
extension) once a real requirement for such dates arises. I don't believe
such a requirement currently exists or is likely to arise within the next
10 years.

Note that there is no ambiguity with the dates in a version 3 certificate
under this proposal. Even if archived for 100 years, the intended dates are
completely unambiguous. The only problem comes if someone needs a date
beyond the end date. But we will define version 4 well before that happens.
My suggestion here is that this be done when we next have a reason to
revise v3, or by 2005 if there is no reason before then.

Rolf.   ([email-masked])

Date: Mon, 21 Oct 1996 12:55:57 -0400
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: proposal for X.509 validity period
Status:   

Bob and Mark:

I take Mark's point re canonical encoding.  However, let me make a couple of
comments.

First, note that we currently have one ASN.1 type that defines all of
versions 1, 2, and 3.  This is the type referenced by all protocol
definitions, directory attributes, etc.  If a new type were defined that was
not backward compatible with the current type (e.g., just substitute
GeneralizedTime for UTCTime), that would break the whole migration plan.
This is the attraction of the CHOICE approach or a new extension, which
actually are backward compatible.  For similar reasons, changing the
encoding rules would be problematic and, I think, unnecessary.

Adding a new extension, as I originally proposed, still seems to be the
cleanest approach technically - I think the only real objection was
"inelegance".  

If we want to use the CHOICE approach, Mark's issue of canonicalization
needs to be dealt with.  Either we require implementations to maintain an
extra state bit indicating which encoding to use, or we introduce a
canonicalization rule.  For the latter, two approaches have been suggested:

(1) Use a new value in the version field to indicate use of the
GeneralizedTime option.
(2) Base it on year value, e.g., use UTCTime for years up to 1999,
GeneralizedTime for years 2000 onward.

Re (1), a big reason why many people do not want to change from V3 is that
all sorts of specifications currently call out "X.509 Version 3" and people
do not want to have to change them.  If we were to take this approach, I
would suggest we introduce the version encoding 3 and call the version, say,
"Version 3g", meaning "Version 3 but use the GeneralizedTime alternative for
encoding validity."  (Makes at least as much sense as encoding Version 4 as
3.)  Another objection to (1) is that it binds version no. to date encoding.
For example, PKIX has decided to keep using Version 1 into the future for
certs that do not have any extensions.  This would not work with approach (1).  

I think (2) is technically sound, but the particular cutover date mentioned
is problematic.  It could invalidate currently-issued certificates, and 3
years may be insufficient time to upgrade all certificate-using systems in
the field (note - these systems are under customer control; not vendor
control).  However, we could equally well define a different
canonicalization rule that gives us til, say, year 2005 to migrate.  The
rule would say that all dates prior to Jan 1, 2005, are encoded in UTCTime
(the yy represents 19yy for 1988 to 1999, and 20yy for 2000 to 2004), and
that all subsequent dates are encoded as GeneralizedTime.  I can see two
possible objections to (2) - one is "complexity".  The other is that all
environments are forced to have the same cutover date.  (For example, with
(1), SET could choose to start using GeneralizedTime immediately, PKIX could
wait til 2005, and MISSI could wait til 2020.)

Warwick

At 12:02 AM 10/21/96 -0400, Mark Bartel wrote:
>I agree with Bob here (as evidenced my own similar suggestion) that we 
>should move to v4 and specify just GeneralizedTime for the validity dates. 
> Several people have advised against advancing the version number; I must 
>admit I don't understand the problems alluded to.
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Mon, 21 Oct 1996 15:35:32 -0400
To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: proposal for X.509 validity period -Reply
Status:   

Bob:

At 12:54 PM 10/21/96 -0600, Bob Jueneman wrote:
>There might be another alternative.
>
>Because I don't like the way that the DER encoding of generalizedTime
>imposes an unnecessary restriction on the basic definition by not 
>supporting the local time format which is otherwise valid format, making 
>it difficult to determine the validity of the syntax at compile time,
>I would suggest that instead of using generalizedTime we adopt 
>some brand new type, say compromiseTime, WHOSE DER 
>ENCODING WOULD BE IDENTICAL TO UTCTime UNTIL 2087,
>and identical to generalizedTime after that time.

It would have to have the same UNIVERSAL tag as UTCTime, i.e., the ASN.1
standardizers would effectively have to change their definition/encoding of
UTCTime.  This is maybe a reasonable approach, but out of our hands.  I
think the CHOICE, with a fixed cutover date of 2087, achieves the same thing.

>Alternatively, is there a way that we can constrain the CHOICE
>in the attribute definition to use UTCTime until say 2020, and use
>generalizedTime afterwards?

Certainly.  That is what I was suggesting for approach (2), except that I
used the year 2005 as the example -  2020 is equally acceptable to me.

>Also, I believe that the IETF decision to stick with V1 for certificates 
>which don't contain extensions needs to be revisited. I never saw 
>the need for such a restriction in the first place, but now it makes even
>less sense.

PKIX is but one X.509 user community that chose this (quite reasonable)
arrangement. 

>At a minimum, we need to be specific that UTCTime only refers to 
>this century and part of the next, and to define the roll-over date.

Heartily agreed.  As an additional small step to close the issue once and
for all, I suggest also defining a new extension, which raises no encoding
nor backward-compatibility problems and which implementors can start using,
at their leisure, any time between now and the middle of the next century.

Warwick

>>>> Warwick Ford <[email-masked]> 10/21/96 10:55am >>>
>Bob and Mark:
>
>I take Mark's point re canonical encoding.  However, let me make a couple of
>comments.
>
>First, note that we currently have one ASN.1 type that defines all of
>versions 1, 2, and 3.  This is the type referenced by all protocol
>definitions, directory attributes, etc.  If a new type were defined that was
>not backward compatible with the current type (e.g., just substitute
>GeneralizedTime for UTCTime), that would break the whole migration plan.
>This is the attraction of the CHOICE approach or a new extension, which
>actually are backward compatible.  For similar reasons, changing the
>encoding rules would be problematic and, I think, unnecessary.
>
>Adding a new extension, as I originally proposed, still seems to be the
>cleanest approach technically - I think the only real objection was
>"inelegance".  
>
>If we want to use the CHOICE approach, Mark's issue of canonicalization
>needs to be dealt with.  Either we require implementations to maintain an
>extra state bit indicating which encoding to use, or we introduce a
>canonicalization rule.  For the latter, two approaches have been suggested:
>
>(1) Use a new value in the version field to indicate use of the
>GeneralizedTime option.
>(2) Base it on year value, e.g., use UTCTime for years up to 1999,
>GeneralizedTime for years 2000 onward.
>
>Re (1), a big reason why many people do not want to change from V3 is that
>all sorts of specifications currently call out "X.509 Version 3" and people
>do not want to have to change them.  If we were to take this approach, I
>would suggest we introduce the version encoding 3 and call the version, say,
>"Version 3g", meaning "Version 3 but use the GeneralizedTime alternative for
>encoding validity."  (Makes at least as much sense as encoding Version 4 as
>3.)  Another objection to (1) is that it binds version no. to date encoding.
>For example, PKIX has decided to keep using Version 1 into the future for
>certs that do not have any extensions.  This would not work with approach
(1).  
>
>I think (2) is technically sound, but the particular cutover date mentioned
>is problematic.  It could invalidate currently-issued certificates, and 3
>years may be insufficient time to upgrade all certificate-using systems in
>the field (note - these systems are under customer control; not vendor
>control).  However, we could equally well define a different
>canonicalization rule that gives us til, say, year 2005 to migrate.  The
>rule would say that all dates prior to Jan 1, 2005, are encoded in UTCTime
>(the yy represents 19yy for 1988 to 1999, and 20yy for 2000 to 2004), and
>that all subsequent dates are encoded as GeneralizedTime.  I can see two
>possible objections to (2) - one is "complexity".  The other is that all
>environments are forced to have the same cutover date.  (For example, with
>(1), SET could choose to start using GeneralizedTime immediately, PKIX could
>wait til 2005, and MISSI could wait til 2020.)
>
>Warwick
>
>
>At 12:02 AM 10/21/96 -0400, Mark Bartel wrote:
>>I agree with Bob here (as evidenced my own similar suggestion) that we 
>>should move to v4 and specify just GeneralizedTime for the validity dates. 
>> Several people have advised against advancing the version number; I must 
>>admit I don't understand the problems alluded to.
>-------------------------------------------------------------------
>Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
>-------------------------------------------------------------------
>
>
>
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Mon, 21 Oct 1996 12:54:23 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: proposal for X.509 validity period -Reply
Status:   

Warwick,

There might be another alternative.

Because I don't like the way that the DER encoding of generalizedTime
imposes an unnecessary restriction on the basic definition by not 
supporting the local time format which is otherwise valid format, making 
it difficult to determine the validity of the syntax at compile time,
I would suggest that instead of using generalizedTime we adopt 
some brand new type, say compromiseTime, WHOSE DER 
ENCODING WOULD BE IDENTICAL TO UTCTime UNTIL 2087,
and identical to generalizedTime after that time.

Alternatively, is there a way that we can constrain the CHOICE
in the attribute definition to use UTCTime until say 2020, and use
generalizedTime afterwards?

Also, I believe that the IETF decision to stick with V1 for certificates 
which don't contain extensions needs to be revisited. I never saw 
the need for such a restriction in the first place, but now it makes even
less sense.

At a minimum, we need to be specific that UTCTime only refers to 
this century and part of the next, and to define the roll-over date.

Bob

>>> Warwick Ford <[email-masked]> 10/21/96 10:55am >>>
Bob and Mark:

I take Mark's point re canonical encoding.  However, let me make a couple of
comments.

First, note that we currently have one ASN.1 type that defines all of
versions 1, 2, and 3.  This is the type referenced by all protocol
definitions, directory attributes, etc.  If a new type were defined that was
not backward compatible with the current type (e.g., just substitute
GeneralizedTime for UTCTime), that would break the whole migration plan.
This is the attraction of the CHOICE approach or a new extension, which
actually are backward compatible.  For similar reasons, changing the
encoding rules would be problematic and, I think, unnecessary.

Adding a new extension, as I originally proposed, still seems to be the
cleanest approach technically - I think the only real objection was
"inelegance".  

If we want to use the CHOICE approach, Mark's issue of canonicalization
needs to be dealt with.  Either we require implementations to maintain an
extra state bit indicating which encoding to use, or we introduce a
canonicalization rule.  For the latter, two approaches have been suggested:

(1) Use a new value in the version field to indicate use of the
GeneralizedTime option.
(2) Base it on year value, e.g., use UTCTime for years up to 1999,
GeneralizedTime for years 2000 onward.

Re (1), a big reason why many people do not want to change from V3 is that
all sorts of specifications currently call out "X.509 Version 3" and people
do not want to have to change them.  If we were to take this approach, I
would suggest we introduce the version encoding 3 and call the version, say,
"Version 3g", meaning "Version 3 but use the GeneralizedTime alternative for
encoding validity."  (Makes at least as much sense as encoding Version 4 as
3.)  Another objection to (1) is that it binds version no. to date encoding.
For example, PKIX has decided to keep using Version 1 into the future for
certs that do not have any extensions.  This would not work with approach (1).  

I think (2) is technically sound, but the particular cutover date mentioned
is problematic.  It could invalidate currently-issued certificates, and 3
years may be insufficient time to upgrade all certificate-using systems in
the field (note - these systems are under customer control; not vendor
control).  However, we could equally well define a different
canonicalization rule that gives us til, say, year 2005 to migrate.  The
rule would say that all dates prior to Jan 1, 2005, are encoded in UTCTime
(the yy represents 19yy for 1988 to 1999, and 20yy for 2000 to 2004), and
that all subsequent dates are encoded as GeneralizedTime.  I can see two
possible objections to (2) - one is "complexity".  The other is that all
environments are forced to have the same cutover date.  (For example, with
(1), SET could choose to start using GeneralizedTime immediately, PKIX could
wait til 2005, and MISSI could wait til 2020.)

Warwick

At 12:02 AM 10/21/96 -0400, Mark Bartel wrote:
>I agree with Bob here (as evidenced my own similar suggestion) that we 
>should move to v4 and specify just GeneralizedTime for the validity dates. 
> Several people have advised against advancing the version number; I must 
>admit I don't understand the problems alluded to.
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Tue, 22 Oct 1996 10:40:38 +1000
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked] (Rolf Exner)
Subject: Re: X.509 validity period

Hi All,

I'd like to add my two cents worth to this discussion. My proposal is

- Define a version 4 Certificate with GeneralizedTime in place of UTCTime
  (no CHOICE).

- Don't do it yet, as it will destabilize X.509 adoption now to solve
  a problem we won't encounter for many years. Do it after 2005 or when we
  next have some other reason to define a version 4 certificate.

I strongly agree with Mark Bartel's point that a certificate should be
capable of validation without the original encoding being present. If there
are suddenly two representations of a v3 certificate (one using UTCTime,
one using GeneralizedTime) it complicates the validation unnecessarily. It
also makes a mockery of our new extensions mechanism for certificates (no
sooner do we have it than we find it necessary to extend a certificate in
some other way). Finally, if we need to keep the original encoding around
to validate a certificate then there's surely no need to use DER at all -
any old BER can be used, just sign the original encoding.

If a v4 is defined, then it can safely include a change to GeneralizedTime
as the presence of the v4 marker will signal the change.

There is a valid concern that changing to version 4 will make it harder to
sell the authentication community the idea of staying with X.509 or of
going to something other than v1. Changing v3 to v4 before v3 is adopted
anywhere will surely undermine confidence in X.509. It would be a real pity
to let this happen to solve a problem that is still many years away.

I therefore suggest that we define the semantics of UTCTime in certificates
as being a time within a range of 100 years (my preference would be
1950-2049), and to state that version 3 certificates cannot handle dates
beyond 2049, but that this deficiency will be addressed (via v4 or an
extension) once a real requirement for such dates arises. I don't believe
such a requirement currently exists or is likely to arise within the next
10 years.

Note that there is no ambiguity with the dates in a version 3 certificate
under this proposal. Even if archived for 100 years, the intended dates are
completely unambiguous. The only problem comes if someone needs a date
beyond the end date. But we will define version 4 well before that happens.
My suggestion here is that this be done when we next have a reason to
revise v3, or by 2005 if there is no reason before then.

Rolf.   ([email-masked])

Date: Mon, 21 Oct 1996 15:35:32 -0400
To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: proposal for X.509 validity period -Reply

Bob:

At 12:54 PM 10/21/96 -0600, Bob Jueneman wrote:
>There might be another alternative.
>
>Because I don't like the way that the DER encoding of generalizedTime
>imposes an unnecessary restriction on the basic definition by not 
>supporting the local time format which is otherwise valid format, making 
>it difficult to determine the validity of the syntax at compile time,
>I would suggest that instead of using generalizedTime we adopt 
>some brand new type, say compromiseTime, WHOSE DER 
>ENCODING WOULD BE IDENTICAL TO UTCTime UNTIL 2087,
>and identical to generalizedTime after that time.

It would have to have the same UNIVERSAL tag as UTCTime, i.e., the ASN.1
standardizers would effectively have to change their definition/encoding of
UTCTime.  This is maybe a reasonable approach, but out of our hands.  I
think the CHOICE, with a fixed cutover date of 2087, achieves the same thing.

>Alternatively, is there a way that we can constrain the CHOICE
>in the attribute definition to use UTCTime until say 2020, and use
>generalizedTime afterwards?

Certainly.  That is what I was suggesting for approach (2), except that I
used the year 2005 as the example -  2020 is equally acceptable to me.

>Also, I believe that the IETF decision to stick with V1 for certificates 
>which don't contain extensions needs to be revisited. I never saw 
>the need for such a restriction in the first place, but now it makes even
>less sense.

PKIX is but one X.509 user community that chose this (quite reasonable)
arrangement. 

>At a minimum, we need to be specific that UTCTime only refers to 
>this century and part of the next, and to define the roll-over date.

Heartily agreed.  As an additional small step to close the issue once and
for all, I suggest also defining a new extension, which raises no encoding
nor backward-compatibility problems and which implementors can start using,
at their leisure, any time between now and the middle of the next century.

Warwick

>>>> Warwick Ford <[email-masked]> 10/21/96 10:55am >>>
>Bob and Mark:
>
>I take Mark's point re canonical encoding.  However, let me make a couple of
>comments.
>
>First, note that we currently have one ASN.1 type that defines all of
>versions 1, 2, and 3.  This is the type referenced by all protocol
>definitions, directory attributes, etc.  If a new type were defined that was
>not backward compatible with the current type (e.g., just substitute
>GeneralizedTime for UTCTime), that would break the whole migration plan.
>This is the attraction of the CHOICE approach or a new extension, which
>actually are backward compatible.  For similar reasons, changing the
>encoding rules would be problematic and, I think, unnecessary.
>
>Adding a new extension, as I originally proposed, still seems to be the
>cleanest approach technically - I think the only real objection was
>"inelegance".  
>
>If we want to use the CHOICE approach, Mark's issue of canonicalization
>needs to be dealt with.  Either we require implementations to maintain an
>extra state bit indicating which encoding to use, or we introduce a
>canonicalization rule.  For the latter, two approaches have been suggested:
>
>(1) Use a new value in the version field to indicate use of the
>GeneralizedTime option.
>(2) Base it on year value, e.g., use UTCTime for years up to 1999,
>GeneralizedTime for years 2000 onward.
>
>Re (1), a big reason why many people do not want to change from V3 is that
>all sorts of specifications currently call out "X.509 Version 3" and people
>do not want to have to change them.  If we were to take this approach, I
>would suggest we introduce the version encoding 3 and call the version, say,
>"Version 3g", meaning "Version 3 but use the GeneralizedTime alternative for
>encoding validity."  (Makes at least as much sense as encoding Version 4 as
>3.)  Another objection to (1) is that it binds version no. to date encoding.
>For example, PKIX has decided to keep using Version 1 into the future for
>certs that do not have any extensions.  This would not work with approach
(1).  
>
>I think (2) is technically sound, but the particular cutover date mentioned
>is problematic.  It could invalidate currently-issued certificates, and 3
>years may be insufficient time to upgrade all certificate-using systems in
>the field (note - these systems are under customer control; not vendor
>control).  However, we could equally well define a different
>canonicalization rule that gives us til, say, year 2005 to migrate.  The
>rule would say that all dates prior to Jan 1, 2005, are encoded in UTCTime
>(the yy represents 19yy for 1988 to 1999, and 20yy for 2000 to 2004), and
>that all subsequent dates are encoded as GeneralizedTime.  I can see two
>possible objections to (2) - one is "complexity".  The other is that all
>environments are forced to have the same cutover date.  (For example, with
>(1), SET could choose to start using GeneralizedTime immediately, PKIX could
>wait til 2005, and MISSI could wait til 2020.)
>
>Warwick
>
>
>At 12:02 AM 10/21/96 -0400, Mark Bartel wrote:
>>I agree with Bob here (as evidenced my own similar suggestion) that we 
>>should move to v4 and specify just GeneralizedTime for the validity dates. 
>> Several people have advised against advancing the version number; I must 
>>admit I don't understand the problems alluded to.
>-------------------------------------------------------------------
>Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
>-------------------------------------------------------------------
>
>
>
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Mon, 21 Oct 1996 12:54:23 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: proposal for X.509 validity period -Reply

Warwick,

There might be another alternative.

Because I don't like the way that the DER encoding of generalizedTime
imposes an unnecessary restriction on the basic definition by not 
supporting the local time format which is otherwise valid format, making 
it difficult to determine the validity of the syntax at compile time,
I would suggest that instead of using generalizedTime we adopt 
some brand new type, say compromiseTime, WHOSE DER 
ENCODING WOULD BE IDENTICAL TO UTCTime UNTIL 2087,
and identical to generalizedTime after that time.

Alternatively, is there a way that we can constrain the CHOICE
in the attribute definition to use UTCTime until say 2020, and use
generalizedTime afterwards?

Also, I believe that the IETF decision to stick with V1 for certificates 
which don't contain extensions needs to be revisited. I never saw 
the need for such a restriction in the first place, but now it makes even
less sense.

At a minimum, we need to be specific that UTCTime only refers to 
this century and part of the next, and to define the roll-over date.

Bob

>>> Warwick Ford <[email-masked]> 10/21/96 10:55am >>>
Bob and Mark:

I take Mark's point re canonical encoding.  However, let me make a couple of
comments.

First, note that we currently have one ASN.1 type that defines all of
versions 1, 2, and 3.  This is the type referenced by all protocol
definitions, directory attributes, etc.  If a new type were defined that was
not backward compatible with the current type (e.g., just substitute
GeneralizedTime for UTCTime), that would break the whole migration plan.
This is the attraction of the CHOICE approach or a new extension, which
actually are backward compatible.  For similar reasons, changing the
encoding rules would be problematic and, I think, unnecessary.

Adding a new extension, as I originally proposed, still seems to be the
cleanest approach technically - I think the only real objection was
"inelegance".  

If we want to use the CHOICE approach, Mark's issue of canonicalization
needs to be dealt with.  Either we require implementations to maintain an
extra state bit indicating which encoding to use, or we introduce a
canonicalization rule.  For the latter, two approaches have been suggested:

(1) Use a new value in the version field to indicate use of the
GeneralizedTime option.
(2) Base it on year value, e.g., use UTCTime for years up to 1999,
GeneralizedTime for years 2000 onward.

Re (1), a big reason why many people do not want to change from V3 is that
all sorts of specifications currently call out "X.509 Version 3" and people
do not want to have to change them.  If we were to take this approach, I
would suggest we introduce the version encoding 3 and call the version, say,
"Version 3g", meaning "Version 3 but use the GeneralizedTime alternative for
encoding validity."  (Makes at least as much sense as encoding Version 4 as
3.)  Another objection to (1) is that it binds version no. to date encoding.
For example, PKIX has decided to keep using Version 1 into the future for
certs that do not have any extensions.  This would not work with approach (1).  

I think (2) is technically sound, but the particular cutover date mentioned
is problematic.  It could invalidate currently-issued certificates, and 3
years may be insufficient time to upgrade all certificate-using systems in
the field (note - these systems are under customer control; not vendor
control).  However, we could equally well define a different
canonicalization rule that gives us til, say, year 2005 to migrate.  The
rule would say that all dates prior to Jan 1, 2005, are encoded in UTCTime
(the yy represents 19yy for 1988 to 1999, and 20yy for 2000 to 2004), and
that all subsequent dates are encoded as GeneralizedTime.  I can see two
possible objections to (2) - one is "complexity".  The other is that all
environments are forced to have the same cutover date.  (For example, with
(1), SET could choose to start using GeneralizedTime immediately, PKIX could
wait til 2005, and MISSI could wait til 2020.)

Warwick

At 12:02 AM 10/21/96 -0400, Mark Bartel wrote:
>I agree with Bob here (as evidenced my own similar suggestion) that we 
>should move to v4 and specify just GeneralizedTime for the validity dates. 
> Several people have advised against advancing the version number; I must 
>admit I don't understand the problems alluded to.
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Mon, 21 Oct 1996 12:08:58 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: X.509 key usage -Reply

Peter asks a very valid, if troubling question. What keyUsage purposes should be
standardized, and which would be proprietary extensions?

Over the weekend, when Hoyt, Warwick, and I were attending the ABA 
Information Security committee meeting,  I observed that the import/export
people tended to differentiate between different kinds of key usages, 
and that getting export (or import, in the case of France, for example) 
approval would tend to be easier or harder based on the key usage 
and the degree to which different key usages were enforced.

To my knowledge, the various categories of key usage that they are 
concerned about would be the following (in approximately increasing
order of concern):

1.  Asymmetric private keys used for digital signatures (the burden of 
proof is on the applicant to show that such a key could never be used for
encryption).

2. Asymmetric or symmetric encryption keys used to protect intellectual 
property, such as an unlocking key for software encryption or for license
enforcement.

3. Asymmetric or symmetric encryption keys used for authentication, 
e.g., to protect passwords. I would hope, but cannot be sure, that 
the same status would be applied to keys used to communicate the 
secret variable used in salted hash algorithms and for secret-key MAC 
algorithms.

4. Encryption keys used to protect financial data exclusively, in particular
credit card numbers and similar data.

5. Key management keys used to protect working keys.

6. Protocol-specific encryption keys, where the raw key is never exposed 
to the user.

7. General, unrestricted usage data encryption keys.

We already have key usage bits defined for some of those usages, but
some are missing. Since inspectability and some form of a common 
enforcement mechanism might significantly ease the burden of export 
control, it seems to me that it might be worthwhile to define keyUsage bits 
for licensing/intellectual property protection, authentication encryption, 
financial data protection, and non-extractable keys (keys that cannot be 
presented to the user in the clear).

I haven't read X.800, but I strongly suspect that these usages would not 
fit that model.

The more important question, I believe, is whether that model should govern
such usages, or not. What do others think?

Bob

>>> Peter Williams <[email-masked]> 10/21/96 10:31am >>>
 
The key usage controls have to date restricted themselves to purpose/usages
which control the X.800 mechanism to which relate. To add send/receive
parameters breaks the layering model of X800 : services, mechanisms, facilities.

If we fail to hold this line, then there should be a general community-controlled
syntax for key usage, as there are a hundred usages which could be so coded as
keyUsage  bits for selection by key purpose.

I desire to control the selection of key, based on key length. So, lets have a bit
for 1024 size keys, versus 1028 bit keys. I desire to have select a public
key based on it being based on it being implemented only in a spyrus lynx
token. So lets have a bit for lynx token... lets have a bit whose for "known to
have escrowed private key", etc.

Why does selection for purpose send/receive (when encrypting/decrypting) merit
special attention at this mechanism/key-usage enforcement control point? 

As the requirement has been identified in a UK NHS pilot, why is there
need for international standardization? Could one not use a v3
application extension, defined locally, to control UK NHS send/receive policy
on key usage and selection?

Furthermore, has not the (long) comment period closed, except for minor editorial
bugs?

Peter.

----------
From: 	Nick Pope
Sent: 	Saturday, October 19, 1996 2:57 PM
To: 	'Denis Pinkas'; Peter Williams
Cc: 	[email-masked]
Subject: 	RE: X.509 key usage

In reply to your message of 18 Oct 96, 10:20 from Peter Williams:

Peter,

The reason for the required key usage flag is not from the view point 
of access control.  It is to enable the public key 
certificate to be selected for a specific usage.  If it is required 
to that different public key can be selected: 
a) to generate a key for decryption of data from the certified entity 
as sender,
b)  to generate the key used to encrypt data to the same entity as a 
recipient.

There is a need for a "key usage" flag in the certificate so that the 
appropriate public key can be selected.

I agree with Denis' suggestion to describe the usage in terms of 
generation of key used for encrypt / decrypt instead of send / 
receive may be more general.

Nick

> Denis,
> 
> I agree with you on the inappropriateness of the solution.
> 
> I understand X.800/509 to say that if the environment requires
> *application* of keying material to be restricted in its use for the
> purpose of establishing or using a named channel, then conventional
> access controls are used, not key usage controls.  The purpose of
> the application is, after all, just enforcement of access control to
> the channel's transport and connection- establishment capability.
> 
> Key usage control security mechanisms do not instrument an access
> control service, per se. If access control information is placed in
> an I&A certificate and used by an access control enforcment
> mechanism which is based on a cryptogprahic separation facility,
> then one uses an extension (or separate cert) for conventional
> statement of the access control information. As usual, such
> information constrains channels, classifications and compartments in
> a lattice designed to constrain the desired policy. Of course the
> lattice function is evaluated during a secure key exchange/agreement
> protocol.
> 
> The logical purpose of key usage controls is to control the raw
> encryption/decryption facility of an algorithm,  so that is
> correctly supports the required security mechanism when enforced by
> a trusted cryptotoken.
> 
> So I dont disgaree with Nick Pope on the need or enviornment of
> application of the access enforcement, but on the choice/placement
> of mechanism which which to signal the control information.
> 
> Peter.
> 
> 
> 
> To: 	Nick Pope
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: X.509 key usage
> 
> 
> 
> > A requirement has been identified in the UK for the use of 
> > public key certificates with a key agreement mechanism which uses
> > different Diffie-Hellman public keys for data sent and received.
> 
> While I agree to support Diffie-Hellman keys, the kind of use which
> is mentionned is not fully appropriate. Although the immediate need
> for the UK is to send and receive data, this is not the elementary
> use which can be made by these keys. It would be possible to use
> these keys to support long term encryption so that, for example to
> locally encrypt a contract that two parties would be able to read in
> the future, without sending or receiving it today, but simply
> storing it.
> 
> 
> > This requires additional key usage flags in the key usage 
> > extension fields.
> > 
> > 11.	Solution Proposed by the Source:  (optional)
> > 
> > Add to Key Usage BIT STRING
> > 		send         (7),
> > 		receive      (8) }
> > 
> > Add to end of item list:
> > 
> > 	h) send: for protecting data sent from the subject 
> > 		(used with key agreement)
> > 	i) receive: for protecting data for receipt by the 
> >             subject (used with key agreement)
> 
> The usage should be expressed in terms of encryption/decryption, not
> in terms of send /receive.
> 
> 
> Denis
> 
> 
> -- 
> 
> ====================================================================
> ========
>       Denis Pinkas                           E-mail :
>       [email-masked] Bull S.A.                               
>                                    Rue Jean Jaures  B.P. 68         
>             Phone : (33-1) 30 80 34 87 78340 Les Clayes sous Bois.
>       FRANCE       Fax  : (33-1) 30 80 33 21
> ====================================================================
> ========
> 
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

Date: Mon, 21 Oct 1996 12:55:57 -0400
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: proposal for X.509 validity period

Bob and Mark:

I take Mark's point re canonical encoding.  However, let me make a couple of
comments.

First, note that we currently have one ASN.1 type that defines all of
versions 1, 2, and 3.  This is the type referenced by all protocol
definitions, directory attributes, etc.  If a new type were defined that was
not backward compatible with the current type (e.g., just substitute
GeneralizedTime for UTCTime), that would break the whole migration plan.
This is the attraction of the CHOICE approach or a new extension, which
actually are backward compatible.  For similar reasons, changing the
encoding rules would be problematic and, I think, unnecessary.

Adding a new extension, as I originally proposed, still seems to be the
cleanest approach technically - I think the only real objection was
"inelegance".  

If we want to use the CHOICE approach, Mark's issue of canonicalization
needs to be dealt with.  Either we require implementations to maintain an
extra state bit indicating which encoding to use, or we introduce a
canonicalization rule.  For the latter, two approaches have been suggested:

(1) Use a new value in the version field to indicate use of the
GeneralizedTime option.
(2) Base it on year value, e.g., use UTCTime for years up to 1999,
GeneralizedTime for years 2000 onward.

Re (1), a big reason why many people do not want to change from V3 is that
all sorts of specifications currently call out "X.509 Version 3" and people
do not want to have to change them.  If we were to take this approach, I
would suggest we introduce the version encoding 3 and call the version, say,
"Version 3g", meaning "Version 3 but use the GeneralizedTime alternative for
encoding validity."  (Makes at least as much sense as encoding Version 4 as
3.)  Another objection to (1) is that it binds version no. to date encoding.
For example, PKIX has decided to keep using Version 1 into the future for
certs that do not have any extensions.  This would not work with approach (1).  

I think (2) is technically sound, but the particular cutover date mentioned
is problematic.  It could invalidate currently-issued certificates, and 3
years may be insufficient time to upgrade all certificate-using systems in
the field (note - these systems are under customer control; not vendor
control).  However, we could equally well define a different
canonicalization rule that gives us til, say, year 2005 to migrate.  The
rule would say that all dates prior to Jan 1, 2005, are encoded in UTCTime
(the yy represents 19yy for 1988 to 1999, and 20yy for 2000 to 2004), and
that all subsequent dates are encoded as GeneralizedTime.  I can see two
possible objections to (2) - one is "complexity".  The other is that all
environments are forced to have the same cutover date.  (For example, with
(1), SET could choose to start using GeneralizedTime immediately, PKIX could
wait til 2005, and MISSI could wait til 2020.)

Warwick

At 12:02 AM 10/21/96 -0400, Mark Bartel wrote:
>I agree with Bob here (as evidenced my own similar suggestion) that we 
>should move to v4 and specify just GeneralizedTime for the validity dates. 
> Several people have advised against advancing the version number; I must 
>admit I don't understand the problems alluded to.
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

From: Peter Williams <[email-masked]>
To: "'Nick Pope'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 key usage
Date: Mon, 21 Oct 1996 09:31:59 -0700

The key usage controls have to date restricted themselves to purpose/usages
which control the X.800 mechanism to which relate. To add send/receive
parameters breaks the layering model of X800 : services, mechanisms, facilities.

If we fail to hold this line, then there should be a general community-controlled
syntax for key usage, as there are a hundred usages which could be so coded as
keyUsage  bits for selection by key purpose.

I desire to control the selection of key, based on key length. So, lets have a bit
for 1024 size keys, versus 1028 bit keys. I desire to have select a public
key based on it being based on it being implemented only in a spyrus lynx
token. So lets have a bit for lynx token... lets have a bit whose for "known to
have escrowed private key", etc.

Why does selection for purpose send/receive (when encrypting/decrypting) merit
special attention at this mechanism/key-usage enforcement control point? 

As the requirement has been identified in a UK NHS pilot, why is there
need for international standardization? Could one not use a v3
application extension, defined locally, to control UK NHS send/receive policy
on key usage and selection?

Furthermore, has not the (long) comment period closed, except for minor editorial
bugs?

Peter.

----------
From: 	Nick Pope
Sent: 	Saturday, October 19, 1996 2:57 PM
To: 	'Denis Pinkas'; Peter Williams
Cc: 	[email-masked]
Subject: 	RE: X.509 key usage

In reply to your message of 18 Oct 96, 10:20 from Peter Williams:

Peter,

The reason for the required key usage flag is not from the view point 
of access control.  It is to enable the public key 
certificate to be selected for a specific usage.  If it is required 
to that different public key can be selected: 
a) to generate a key for decryption of data from the certified entity 
as sender,
b)  to generate the key used to encrypt data to the same entity as a 
recipient.

There is a need for a "key usage" flag in the certificate so that the 
appropriate public key can be selected.

I agree with Denis' suggestion to describe the usage in terms of 
generation of key used for encrypt / decrypt instead of send / 
receive may be more general.

Nick

> Denis,
> 
> I agree with you on the inappropriateness of the solution.
> 
> I understand X.800/509 to say that if the environment requires
> *application* of keying material to be restricted in its use for the
> purpose of establishing or using a named channel, then conventional
> access controls are used, not key usage controls.  The purpose of
> the application is, after all, just enforcement of access control to
> the channel's transport and connection- establishment capability.
> 
> Key usage control security mechanisms do not instrument an access
> control service, per se. If access control information is placed in
> an I&A certificate and used by an access control enforcment
> mechanism which is based on a cryptogprahic separation facility,
> then one uses an extension (or separate cert) for conventional
> statement of the access control information. As usual, such
> information constrains channels, classifications and compartments in
> a lattice designed to constrain the desired policy. Of course the
> lattice function is evaluated during a secure key exchange/agreement
> protocol.
> 
> The logical purpose of key usage controls is to control the raw
> encryption/decryption facility of an algorithm,  so that is
> correctly supports the required security mechanism when enforced by
> a trusted cryptotoken.
> 
> So I dont disgaree with Nick Pope on the need or enviornment of
> application of the access enforcement, but on the choice/placement
> of mechanism which which to signal the control information.
> 
> Peter.
> 
> 
> 
> To: 	Nick Pope
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: X.509 key usage
> 
> 
> 
> > A requirement has been identified in the UK for the use of 
> > public key certificates with a key agreement mechanism which uses
> > different Diffie-Hellman public keys for data sent and received.
> 
> While I agree to support Diffie-Hellman keys, the kind of use which
> is mentionned is not fully appropriate. Although the immediate need
> for the UK is to send and receive data, this is not the elementary
> use which can be made by these keys. It would be possible to use
> these keys to support long term encryption so that, for example to
> locally encrypt a contract that two parties would be able to read in
> the future, without sending or receiving it today, but simply
> storing it.
> 
> 
> > This requires additional key usage flags in the key usage 
> > extension fields.
> > 
> > 11.	Solution Proposed by the Source:  (optional)
> > 
> > Add to Key Usage BIT STRING
> > 		send         (7),
> > 		receive      (8) }
> > 
> > Add to end of item list:
> > 
> > 	h) send: for protecting data sent from the subject 
> > 		(used with key agreement)
> > 	i) receive: for protecting data for receipt by the 
> >             subject (used with key agreement)
> 
> The usage should be expressed in terms of encryption/decryption, not
> in terms of send /receive.
> 
> 
> Denis
> 
> 
> -- 
> 
> ====================================================================
> ========
>       Denis Pinkas                           E-mail :
>       [email-masked] Bull S.A.                               
>                                    Rue Jean Jaures  B.P. 68         
>             Phone : (33-1) 30 80 34 87 78340 Les Clayes sous Bois.
>       FRANCE       Fax  : (33-1) 30 80 33 21
> ====================================================================
> ========
> 
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Mark Bartel <[email-masked]>
Subject: Re: generalizedTime not (very) well defined.
To: [email-masked] (peter)
Date: Mon, 21 Oct 1996 12:29:59 -0400 (EDT)
Cc: [email-masked]

> >4.  Midnight shall be "YYYYMMDD000000Z" (instead of "YYYYMMDD240000Z")
> 
> This may seem like a silly question, but:  Does this mean that midnight
> is interpreted as the beginning of day YYYYMMDD, and not as the end
> (which is how I'd read the 240000 format)?  Obviously, it is very
> important to know when midnight is (you'll note that in many countries,
> train schedules, contracts, etc., all use "one minute after midnight" to
> get around this ambiguity).

The actual text in X.690 is:

"11.7.4 Midnight (GMT) shall be represented in the form:

	"YYYYMMDD000000Z"

where "YYYYMMDD" represents the day following the midnight in
question."

- Mark Bartel ([email-masked])

X400-Received:   by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 21 Oct 1996 10:01:47 -0400 
X400-Received:   by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 21 Oct 1996 09:34:22 -0400 
X400-Received:   by /PRMD=BNR/ADMD= /C=GB/; Relayed; Mon, 21 Oct 1996 09:32:00 -0400 
X400-Received:   by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 21 Oct 1996 09:29:25 -0400 
X400-Received:   by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 21 Oct 1996 09:29:23 -0400 
Date:  Mon, 21 Oct 1996 09:29:23 -0400 
X400-Originator:  /dd.id=1660747/g=peter/i=pw/s=whittaker/@bnr.ca 
X400-MTS-Identifier:   [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<c=CA%a=_%p=NorTel_Secure_Ne%l=G] 
X400-Content-Type:  P2-1984 (2) 
Content-Identifier:  RE: generaliz... 
From: "peter (p.w.) whittaker" <[email-masked]>
To: "'bjueneman%novell.com@bnr400'" <[email-masked]>, "'mbartel%mag1.magmacom.com@bnr400'" <[email-masked]>
Cc: "'D.Boyce%isode.com@bnr400'" <[email-masked]>, "'ietf-pkix%tandem.com@bnr400'" <[email-masked]>
Subject:  RE: generalizedTime not (very) well defined. 
Encoding: 17 TEXT

>> David Boyce and I have been discussing the local vs. Z time options
>> in generalizedTime, and I think the issue is worth raising to a wider 
>
>Well, certificates must be DER encoded... are we using the definition
>of DER from X.690 (11.7)?  It specifies:
>
>4.  Midnight shall be "YYYYMMDD000000Z" (instead of "YYYYMMDD240000Z")

This may seem like a silly question, but:  Does this mean that midnight
is interpreted as the beginning of day YYYYMMDD, and not as the end
(which is how I'd read the 240000 format)?  Obviously, it is very
important to know when midnight is (you'll note that in many countries,
train schedules, contracts, etc., all use "one minute after midnight" to
get around this ambiguity).

pww

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Subject: Re: proposal for X.509 validity period
Date: Mon, 21 Oct 1996 00:02:57 -0400
Encoding: 206 TEXT

I agree with Bob here (as evidenced my own similar suggestion) that we 
should move to v4 and specify just GeneralizedTime for the validity dates. 
 Several people have advised against advancing the version number; I must 
admit I don't understand the problems alluded to.

To more clearly articulate the problem I perceive:

With a CHOICE in v3, there is no DER (or whatever the X.509 version of 
those rules is called) encoding of the certificate.  There are a number of 
encodings that are possible; to verify the certificate, you must keep track 
of which encoding was used in the first place instead of just keeping track 
of the values of the fields.  This complicates matters significantly; I 
don't see this as a minor matter.  The whole point of DER encoding the 
certificate was to ensure that there was only one possible representation. 
 Moving to v4 and specifying GeneralizedTime (with X.690 DER for the 
encoding of the GeneralizedTime) avoids adding any more problems than X.509 
already has here.

Since the CRL definition needs to be fixed as well, I would think changing 
the version number (for both) makes even more sense.

And perhaps we could even specify X.690 DER instead of the short list in 
X.509, and disambiguate further, although I admit to being ignorant of any 
additional ramifications that change might have.  Since UTCTime is the only 
ambiguous X.509 type encoding I can think of at the moment, there might be 
no need for this.

How does keeping the version number at 3 simplify matters such that it is 
worth losing the above simplification?

(I realize that we could specify rules for when to use UTCTime such that 
there is a distinguished encoding, but it would also be more complicated 
than moving to v4.)

- Mark Bartel ([email-masked])

Bob Jueneman wrote:

>Maybe the simplest approach would be to progress to v4, and
>simply change the definition of validity to be expressed in
>generalizedTime only.  The use of v1, v2, and v3  for notBefore
>dates after 1 January 2000 would be strongly deprecated.
>The (minor) complexity caused by CHOICE would be avoided.
>
>CAs could offer their customers a choice of v3 and v4
>certificates until the demand for v3 certificates subsides
>sufficiently.
>
>Implementations would be strongly encouraged (by competitive
>pressure) to support the most current version, v4, but they could
>also continue to use v3, handling notBefore and notAfter dates
>as explicitly 2000 + N, so as not to perpetuate this into the next
>century. (We can probably defer support for 10,000AD until v5+
>with relatively little risk. :-)
>
>With this scheme, the CRL format would also advance to v3,
>supporting generalizedTime only.
>
>I haven't thought about this too much, but would it be reasonable
>to suggest that v3 certs be rejected with a v3 CRL, and v4 certs
>in a v3 CRL, publishing two CRLs in two different formats until
>all of the v3 certs have either expired or been revoked?
>
>How many implementations are yet handling CRLs at all?  I think
>perhaps very few??? Maybe the CRL processing could jump to
>v3 immediately??
>
>Maybe CHOICE is more appropriate here? This obviously needs
>some more thought.
>
>Bob
>
>
>
>Robert R. Jueneman
>Security Architect
>NetWare Security R&D
>Internet Infrastructure Division
>Novell, Inc. M/S-PRV-D241
>122 East 1700 South
>Provo, UT 84606
>801/861-7387
>
>>>> <[email-masked]> 10/14/96 05:58am >>>
>In two weeks I will be chairing a directory meeting where one of the 
agenda
>items is to process defect reports. I would like to see a consensus on 
this
>problem so that I can get a technical corrigendum approved and maybe get 
that TC
>
>incorporated in the published edition. The procedure is defect report 
being
>accepted; writing a draft technical corrigendum containing the corrective 
text;
>
>submitting the DTC to a three month ballot; processing the national body 
 and
>liaison organization votes and comments; if the resulting text is 
acceptable
>producing the Technical Corrigendum; and finally incorporating that TC 
into the
>
>next published edition of the standard.
>
>[snip]
>
>
>>I believe the choice of methods come down to three
>
>>1) replace the UTCTime encoding with GeneralizedTime. As this would not 
only
>invalidate current implementations, but also currently issued 
certificates, this
>
>is not an acceptable solution.
>
>Assuming that we progress to v4, at the same time,  I believe that this IS
>and acceptable solution.
>
>>2) replace the current encoding with a CHOICE encoding of both UTCTime 
and
>GeneralizedTime. This would invalidate current implementations but not 
currently
>
>issued certificates. As mentioned, I don't believe that a new version 
would help
>
>interoperability. The only way that this would be acceptable is to get 
agreement
>
>that implementations would adopt this new encoding in their implementation 
right
>
>away. We have done this before. In fact this is the definition of normal 
defect
>
>resolution. The resulting Technical Corrigendum fixes an error and each
>implementation should incorporate that TC as quickly as possible. Where 
there is
>
>significant implementation interest, the defect resolution group has 
liaised
>with the implementation groups. Normally, this would be the implementor
>workshops. However, in this case I would also expect the blessing of at 
least
>also the PKIX and SET groups.
>
>Option 2 would be my second choice.
>
>>3) generate a new extension that has the validity date encoded in
>GeneralizedTime. This would not necessarily invalidate implementations. 
That
>would depend on whether or not an implementation could successfully 
process
>year 2000 and greater dates encoded in UTCTime. That is, if one did not 
mandate
>
>the understanding of the extension, e.g. via the critical flag, the 
encoder
>would still have encode the date in the existing Validity field and 
receivers
>would have to understand some sort of wrap rule.
>
>>I would like to make the following recommendation. I don't see the value 
of
>method three. Implementors would have to support both the extension and 
the wrap
>
>around rule for the existing Validity element. Unless we mandate support 
of the
>
>extension. If we are going to mandate anything, I recommend method two.
>
>Agreed. Option 3 seems really ugly. I wouldn't like to see the now-useless 
>UTCTime attribute carried around forever.
>
>>Although implementations would have to change, method two could turn out 
to be
>
>the cleanest. I suggest we implement the CHOICE (I don't believe a new 
version
>would help, but then it couldn't hurt). To keep it simple, I further 
suggest
>that we not adopt any wrap around rule. That is, the current UTCTime 
Validity
>field could only be used for dates that are before 1 January 2000. I also
>suggest that we don't mix the two forms. That is, if the notAfter value is 
after
>
>31 December 1999, both it and the notBefore value shall be encoded in
>GeneralizedTime even though the notBefore value is prior to 1 January 
2000.
>
>The only question is whether there are already certificates in existence
>that have notAfter dates that are post-2000, and/or a substantial number 
of
>certificates with three + year validity periods will have to be issued in 
1997.
>
>
>Bob
>
>
>
>

Date: Fri, 18 Oct 1996 08:40:19 UT
From: Michael Leahy <[email-masked]>
To: "'(MAILING LIST) ietf-pkix'" <[email-masked]>
Subject: Looking for Version 3 Certificates
Info: Evaluation version at ntdev.signet.org.au
Status:   

Hi

I'm looking for some X.509 Version 3 certificate(s) which have been signe=
d using the following algorithms

md5WithRSAEncryption	=09
shaWithRSAEncryption
ripemd160WithRSAEncryption

I want to be able to verify the signatures on these certificates so I wil=
l need the Sample certificate(s) + corresponding CA Certificate(s). Can a=
nyone help ?

Thanks in advance for all replies

Michael Leahy
ISOCOR=20

--------------------------------oOo------------------------------------
X.400    	: c=3Die; a=3Deirmail400; p=3Disocor; g=3DMichael; s=3DLeahy
Internet 	: [email-masked]
Tel     	: +353 1 676 0366=09
Fax     	: +353 1 676 0856
--------------------------------oOo------------------------------------=09

Date: Fri, 18 Oct 1996 08:40:19 UT
From: Michael Leahy <[email-masked]>
To: "'(MAILING LIST) ietf-pkix'" <[email-masked]>
Subject: Looking for Version 3 Certificates
Status:   

Hi

I'm looking for some X.509 Version 3 certificate(s) which have been signe=
d using the following algorithms

md5WithRSAEncryption	=09
shaWithRSAEncryption
ripemd160WithRSAEncryption

I want to be able to verify the signatures on these certificates so I wil=
l need the Sample certificate(s) + corresponding CA Certificate(s). Can a=
nyone help ?

Thanks in advance for all replies

Michael Leahy
ISOCOR=20

--------------------------------oOo------------------------------------
X.400    	: c=3Die; a=3Deirmail400; p=3Disocor; g=3DMichael; s=3DLeahy
Internet 	: [email-masked]
Tel     	: +353 1 676 0366=09
Fax     	: +353 1 676 0856
--------------------------------oOo------------------------------------=09

From: Nick Pope <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, Peter Williams <[email-masked]>
Date: Sat, 19 Oct 1996 21:57:30 +0000
Subject: RE: X.509 key usage
CC: "[email-masked]" <[email-masked]>
Priority: normal

In reply to your message of 18 Oct 96, 10:20 from Peter Williams:

Peter,

The reason for the required key usage flag is not from the view point 
of access control.  It is to enable the public key 
certificate to be selected for a specific usage.  If it is required 
to that different public key can be selected: 
a) to generate a key for decryption of data from the certified entity 
as sender,
b)  to generate the key used to encrypt data to the same entity as a 
recipient.

There is a need for a "key usage" flag in the certificate so that the 
appropriate public key can be selected.

I agree with Denis' suggestion to describe the usage in terms of 
generation of key used for encrypt / decrypt instead of send / 
receive may be more general.

Nick

> Denis,
> 
> I agree with you on the inappropriateness of the solution.
> 
> I understand X.800/509 to say that if the environment requires
> *application* of keying material to be restricted in its use for the
> purpose of establishing or using a named channel, then conventional
> access controls are used, not key usage controls.  The purpose of
> the application is, after all, just enforcement of access control to
> the channel's transport and connection- establishment capability.
> 
> Key usage control security mechanisms do not instrument an access
> control service, per se. If access control information is placed in
> an I&A certificate and used by an access control enforcment
> mechanism which is based on a cryptogprahic separation facility,
> then one uses an extension (or separate cert) for conventional
> statement of the access control information. As usual, such
> information constrains channels, classifications and compartments in
> a lattice designed to constrain the desired policy. Of course the
> lattice function is evaluated during a secure key exchange/agreement
> protocol.
> 
> The logical purpose of key usage controls is to control the raw
> encryption/decryption facility of an algorithm,  so that is
> correctly supports the required security mechanism when enforced by
> a trusted cryptotoken.
> 
> So I dont disgaree with Nick Pope on the need or enviornment of
> application of the access enforcement, but on the choice/placement
> of mechanism which which to signal the control information.
> 
> Peter.
> 
> 
> 
> To: 	Nick Pope
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: X.509 key usage
> 
> 
> 
> > A requirement has been identified in the UK for the use of 
> > public key certificates with a key agreement mechanism which uses
> > different Diffie-Hellman public keys for data sent and received.
> 
> While I agree to support Diffie-Hellman keys, the kind of use which
> is mentionned is not fully appropriate. Although the immediate need
> for the UK is to send and receive data, this is not the elementary
> use which can be made by these keys. It would be possible to use
> these keys to support long term encryption so that, for example to
> locally encrypt a contract that two parties would be able to read in
> the future, without sending or receiving it today, but simply
> storing it.
> 
> 
> > This requires additional key usage flags in the key usage 
> > extension fields.
> > 
> > 11.	Solution Proposed by the Source:  (optional)
> > 
> > Add to Key Usage BIT STRING
> > 		send         (7),
> > 		receive      (8) }
> > 
> > Add to end of item list:
> > 
> > 	h) send: for protecting data sent from the subject 
> > 		(used with key agreement)
> > 	i) receive: for protecting data for receipt by the 
> >             subject (used with key agreement)
> 
> The usage should be expressed in terms of encryption/decryption, not
> in terms of send /receive.
> 
> 
> Denis
> 
> 
> -- 
> 
> ====================================================================
> ========
>       Denis Pinkas                           E-mail :
>       [email-masked] Bull S.A.                               
>                                    Rue Jean Jaures  B.P. 68         
>             Phone : (33-1) 30 80 34 87 78340 Les Clayes sous Bois.
>       FRANCE       Fax  : (33-1) 30 80 33 21
> ====================================================================
> ========
> 
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Peter Williams <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Private key validity period
Date: Fri, 18 Oct 1996 12:45:13 -0700

Denis,

The final X.509 88 standard contains abstract syntaxes whose only consumer
was the X.400 88 suite of specifications. Said certs were obviously
intended to be used in X.400, which has a complete proof
of X with non-repudiation set of services defined, and
(additionally) definees a message notarization security service requiring
trusted third party timestamping and storage.

The model of validity in X.509, when viewed in terms of
the X.400 security model, has no problem other than
that identiifed here - a general long-term _potential_
ambiguity of which century is referred to. Many observers
view this as trivia, but it can be sorted simply enough to remove 
a source Ron Rivest's laughing fits, easily enough.

You cannot rely on an X.509 beyond its expiry date. if you
need to use it for any purpose , you must
take a risk by using (but not relying) on a cert which
is no longer valid. If you get stung, its your fault.

Alternatively, you just go and get from the person the new uptodate
cert for the key (for encryption cases). If they dont give it you, you are denied valid
access nad you are in the situation as per the last paragraph,

For signature cases, you use notary services to protect yourself
for reliance cases in the future, as per manual convention and X.400
model.

Private key validity extension doesnt come into it. I do agree private key
validity extension can interfere and cause confusion in the model if
mis-applied.
 
Peter.

----------
From: 	Denis Pinkas
Sent: 	Wednesday, October 16, 1996 1:24 AM
To: 	[email-masked]
Cc: 	[email-masked]; [email-masked]; [email-masked]
Subject: 	Re: Private key validity period

While we were finalizing the standard in Bristol many years ago 
we recognized that we were dealing with the use of certificates 
for the security of the Directory itself and not for the use by 
other applications for different purposes. At that time we talked 
about further contraints that would be needed for non repudiation 
purposes but they were not incorporated because non repudiation 
was not at this time a security service used by the Directory.

From: Peter Williams <[email-masked]>
To: Nick Pope <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 key usage
Date: Fri, 18 Oct 1996 10:20:12 -0700

Denis,

I agree with you on the inappropriateness of the solution.

I understand X.800/509 to say that if the environment requires *application* of keying
material to be restricted in its use for the purpose of establishing or using a named channel,
then conventional access controls are used, not key usage controls.  The purpose of the application
is, after all, just enforcement of access control to the channel's transport and connection-
establishment capability.

Key usage control security mechanisms do not instrument an access control service, per
se. If access control information is placed in an I&A certificate and used by an access control
enforcment mechanism which is based on a cryptogprahic separation facility, then one uses an
extension (or separate cert) for conventional statement of the access control information. As usual,
such information constrains channels, classifications and compartments in a lattice
designed to constrain the desired policy. Of course the lattice function is evaluated
during a secure key exchange/agreement protocol.

The logical purpose of key usage controls is to control the raw encryption/decryption facility
of an algorithm,  so that is correctly supports the required security mechanism when
enforced by a trusted cryptotoken.

So I dont disgaree with Nick Pope on the need or enviornment of application of the access
enforcement, but on the choice/placement of mechanism which which to signal the control
information.

Peter.

To: 	Nick Pope
Cc: 	[email-masked]; [email-masked]
Subject: 	Re: X.509 key usage

> A requirement has been identified in the UK for the use of 
> public key certificates with a key agreement mechanism which 
> uses different Diffie-Hellman public keys for data sent and 
> received.

While I agree to support Diffie-Hellman keys, the kind of use which is 
mentionned is not fully appropriate. Although the immediate need for the UK 
is to send and receive data, this is not the elementary use which can be 
made by these keys. It would be possible to use these keys to support long 
term encryption so that, for example to locally encrypt a contract that two 
parties would be able to read in the future, without sending or receiving 
it today, but simply storing it.

> This requires additional key usage flags in the key usage 
> extension fields.
> 
> 11.	Solution Proposed by the Source:  (optional)
> 
> Add to Key Usage BIT STRING
> 		send         (7),
> 		receive      (8) }
> 
> Add to end of item list:
> 
> 	h) send: for protecting data sent from the subject 
> 		(used with key agreement)
> 	i) receive: for protecting data for receipt by the 
>             subject (used with key agreement)

The usage should be expressed in terms of encryption/decryption, 
not in terms of send /receive.

Denis

-- 

============================================================================
      Denis Pinkas                           E-mail : [email-masked]
      Bull S.A.                                                             
      Rue Jean Jaures  B.P. 68                Phone : (33-1) 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE       Fax  : (33-1) 30 80 33 21
============================================================================

From: Nick Pope <[email-masked]>
To: Nick Pope <[email-masked]>, Denis Pinkas <[email-masked]>
Date: Fri, 18 Oct 1996 16:30:33 +0000
Subject: Re: X.509 key usage
CC: [email-masked], [email-masked]
Priority: normal

In reply to your message of 18 Oct 96, 13:05 from Denis Pinkas

I have no problem with re-expressing this in terms of encryption / 
decryption.  I can see it add more generality.

Do others agree with this alternative way of descibing this proposal.

Nick Pope

> 
> 
> > A requirement has been identified in the UK for the use of 
> > public key certificates with a key agreement mechanism which 
> > uses different Diffie-Hellman public keys for data sent and 
> > received.
> 
> While I agree to support Diffie-Hellman keys, the kind of use which is
> mentionned is not fully appropriate. Although the immediate need for
> the UK is to send and receive data, this is not the elementary use
> which can be made by these keys. It would be possible to use these
> keys to support long term encryption so that, for example to locally
> encrypt a contract that two parties would be able to read in the
> future, without sending or receiving it today, but simply storing it.
> 
> 
> > This requires additional key usage flags in the key usage 
> > extension fields.
> > 
> > 11.	Solution Proposed by the Source:  (optional)
> > 
> > Add to Key Usage BIT STRING
> > 		send         (7),
> > 		receive      (8) }
> > 
> > Add to end of item list:
> > 
> > 	h) send: for protecting data sent from the subject 
> > 		(used with key agreement)
> > 	i) receive: for protecting data for receipt by the 
> >             subject (used with key agreement)
> 
> The usage should be expressed in terms of encryption/decryption, not
> in terms of send /receive.
> 
> 
> Denis
> 
> 
> -- 
> 
> ======================================================================
> ======
>       Denis Pinkas                           E-mail :
>       [email-masked] Bull S.A.                                 
>                                  Rue Jean Jaures  B.P. 68             
>         Phone : (33-1) 30 80 34 87 78340 Les Clayes sous Bois. FRANCE 
>            Fax  : (33-1) 30 80 33 21
> ======================================================================
> ======
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: [email-masked] (Denis Pinkas)
Subject: Re: X.509 key usage
To: [email-masked] (Nick Pope)
Date: Fri, 18 Oct 1996 13:05:38 +0100 (NFT)
Cc: [email-masked], [email-masked]

> A requirement has been identified in the UK for the use of 
> public key certificates with a key agreement mechanism which 
> uses different Diffie-Hellman public keys for data sent and 
> received.

While I agree to support Diffie-Hellman keys, the kind of use which is 
mentionned is not fully appropriate. Although the immediate need for the UK 
is to send and receive data, this is not the elementary use which can be 
made by these keys. It would be possible to use these keys to support long 
term encryption so that, for example to locally encrypt a contract that two 
parties would be able to read in the future, without sending or receiving 
it today, but simply storing it.

> This requires additional key usage flags in the key usage 
> extension fields.
> 
> 11.	Solution Proposed by the Source:  (optional)
> 
> Add to Key Usage BIT STRING
> 		send         (7),
> 		receive      (8) }
> 
> Add to end of item list:
> 
> 	h) send: for protecting data sent from the subject 
> 		(used with key agreement)
> 	i) receive: for protecting data for receipt by the 
>             subject (used with key agreement)

The usage should be expressed in terms of encryption/decryption, 
not in terms of send /receive.

Denis

-- 

============================================================================
      Denis Pinkas                           E-mail : [email-masked]
      Bull S.A.                                                             
      Rue Jean Jaures  B.P. 68                Phone : (33-1) 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE       Fax  : (33-1) 30 80 33 21
============================================================================

Date: Fri, 18 Oct 1996 08:40:19 UT
From: Michael Leahy <[email-masked]>
To: "'(MAILING LIST) ietf-pkix'" <[email-masked]>
Subject: Looking for Version 3 Certificates

Hi

I'm looking for some X.509 Version 3 certificate(s) which have been signe=
d using the following algorithms

md5WithRSAEncryption	=09
shaWithRSAEncryption
ripemd160WithRSAEncryption

I want to be able to verify the signatures on these certificates so I wil=
l need the Sample certificate(s) + corresponding CA Certificate(s). Can a=
nyone help ?

Thanks in advance for all replies

Michael Leahy
ISOCOR=20

--------------------------------oOo------------------------------------
X.400    	: c=3Die; a=3Deirmail400; p=3Disocor; g=3DMichael; s=3DLeahy
Internet 	: [email-masked]
Tel     	: +353 1 676 0366=09
Fax     	: +353 1 676 0856
--------------------------------oOo------------------------------------=09

Organization: Consensus Development Corporation <http://www.consensus.com/>
Date: Thu, 17 Oct 1996 12:30:10 -0700
To: "Certificate Storage Working Group" <[email-masked]>
From: Christopher Allen <[email-masked]>
Subject: Minutes from Conference Call on Cert Storage 10/10/96
Cc: [email-masked], [email-masked], [email-masked], [email-masked], Marshall Clow <[email-masked]>, Eric Gundrum <[email-masked]>

Please do not reply directly to this email (as it has been sent to many
lists) -- instead, reply-to: Christopher Allen <[email-masked]>
or subscribe to the list below if you are interested.

I have set up a mailing list for this working group. Send mail to
<[email-masked]> with the subject "subscribe" or
"subscribe digest" to join.

Minutes from Conference Call on Cert Storage
10/10/96

Attending:
	Christopher Allen <[email-masked]>
	Robert Dickinson <[email-masked]>
	Tim Dierks <[email-masked]>
	Steve Dusse <[email-masked]>
	Laurence Lundblade <[email-masked]>
	Blake Ramsdell <[email-masked]>

This group was brought together to discuss interoperability issues
regarding exchange of certificates and private keys between products. A
file format is desired which specifies the storage of a certificate, the
chain of certificates supporting its authenticity, and a password-protected
private key object. This should be suitable for exporting certificates from
one application and importing them into another or for native storage for
products which choose to adopt it.

The call opened with a review of some history and background:

There was a draft of PKCS#12 that was loosely based on what was learned
from the old Apple PowerTalk signer file, however, it was never distributed.

Microsoft has proposed PFX (info at
<http://www.microsoft.com/INTDEV/SECURITY/PFX/PFX019SYNTAX.HTM>). PFX
attempts to solve more problems than merely certificate transport, but it
does propose an ASN.1-encoded format for transporting certificates and
keys; this subset of PFX would be a candidate for solving this problem. PFX
drew on the unpublished PKCS#12 draft.

Steve Dusse at RSA Data Security said that they and Netscape have looked at
the PFX proposal and feel there is some value in basing a real PKCS#12 on
the bits-on-the-wire portions of PFX, but are not sure about the protocols
or trust model specifics of PFX. Microsoft is committed to PFX, and Steve
Dusse reported after the meeting that Netscape may actually have some
PFX-like interchange code underway.

Christopher Allen and Tim Dierks of Consensus Development define the short
term problem as "How do you encapsulate single private key, it's cert and
cert chain into a single package that we can interchange." They have seen
four different "signer" files: the original PowerTalk-compatible signer
file (which Mac specific); single file binary file formats; two binary file
formats (private key in one and certs in the other); and ASCII armored
files similar to what PGP offers.

Consensus is open to either some ASN.1 encoded object or some type of ASCII
mime-like file, and work with any appropriate standards process, but wants
to get things rolling.

Deming said that they are willing to support some type of
interchange/export file format, adding that this could be in the form of a
PKCS#7 mime type that contains the all the different parts. Tim pointed out
that VeriSign only provided a certificate (not a PKCS#7 object) for any
PCKS#10 requests, and thus Consensus' current ASCII armored format uses
those.

There was some discussion that whatever approach that was taken needed to
fit in with with Netscape and Microsoft's plans. Steve Dusse recommends
taking a look at the ASN.1 in the PFX proposal and base an interchange file
on that.

Ray Sidney says that a new draft PKCS#12 document might be possible in the
next 3 or 4 months.

Both Deming and Consensus were concerned with this pace as they are
preparing to release products now, and only require a
least-common-denominator solution right now, i.e. a single private key,
certificate, and a certificate chain.

Tim Dierks added that there is probably a sub-requirement to specify
a better standard for password protected encryption beyond PKCS#5 as it
stands because it currently only supports DES encryption.

The meeting ended with an agreement to go look at the ASN.1 of the PFX
documents, exchange some email, and talk again next week schedule
permitting.

P.S. Many thanks to Qualcomm for sponsoring the call.

FYI: Enclosed is a prototype ASCII armored file for Consensus' SSL Plus
beta. The descriptive lines are ignored comments; the format is just block
specifiers formatted as below wrapping base64 encoded ASN.1 data. It could
easily be adapted to MIME style wrappers, or support other base64 binary
encoded formats.

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

SSL Plus test certificate
-----BEGIN X.509 CERTIFICATE-----
-----BEGIN X.509 CERTIFICATE-----

Consensus Test CA
-----BEGIN X.509 CERTIFICATE-----
-----BEGIN X.509 CERTIFICATE-----

SSL Plus test certificate private key
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<[email-masked]>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..

------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<[email-masked]>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..

Date: Wed, 16 Oct 1996 09:50:48 -0700
To: Warwick Ford <[email-masked]>
From: [email-masked] (Tony Bartoletti)
Subject: Re: Private key validity period
Cc: [email-masked]

Warwick:

Not exactly a charitable reply to what I felt was one of the more lucid
expositions of public/private key-usages and their respective validities.
Must be getting cold up there.  ___TONY___

>Denis:
>
>I agree with David's assessment of the discussion of this subject in
>Montreal.  You have raised and reraised your idea many times on the pkix
>list over the past 12 months or more and have discussed it at two pkix
>meetings, including giving a lengthy presentation in Montreal.  I have yet
>to see any support for it, so can't we please save the ietf-pkix bandwidth
>for more important things?
>
>Warwick
>
>
>At 09:24 AM 10/16/96 +0100, Denis Pinkas wrote:
>>
>>
>>
>>David Chadwick has expressed a disagreement about my presentation
>>of the concerns I had about the private key validity period. I
>>believe that we have a conflict on the terminology to be used,
>>but not on the basic concepts.
>-------------------------------------------------------------------
>Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
>-------------------------------------------------------------------

Tony Bartoletti                                             LL
SPI Project Leader                                       LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Wed, 16 Oct 1996 10:51:44 -0400
To: [email-masked] (Denis Pinkas), [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: Private key validity period
Cc: [email-masked], [email-masked]

Denis:

I agree with David's assessment of the discussion of this subject in
Montreal.  You have raised and reraised your idea many times on the pkix
list over the past 12 months or more and have discussed it at two pkix
meetings, including giving a lengthy presentation in Montreal.  I have yet
to see any support for it, so can't we please save the ietf-pkix bandwidth
for more important things?

Warwick

At 09:24 AM 10/16/96 +0100, Denis Pinkas wrote:
>
>
>
>David Chadwick has expressed a disagreement about my presentation 
>of the concerns I had about the private key validity period. I 
>believe that we have a conflict on the terminology to be used, 
>but not on the basic concepts. 
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

From: Nick Pope <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 16 Oct 1996 09:45:38 +0000
Subject: X.509 key usage
Priority: normal

A requirement has been identified in the UK for the use of 
public key certificates with a key agreement mechanism which 
uses different Diffie-Hellman public keys for data sent and 
received.

This requires additional key usage flags in the key usage 
extension fields.

I therefore would like to raise the following defect report at the 
Phoenix meeting.

DEFECT REPORT FORM

1.	Defect Report Number:	9594/

2.	Source:   	UK

3.	Addressed to:	ISO/IEC JTC1/SC21/WG4 and CCITT Study 
Group VII Editor Group on the Directory

4.	(a)  WG Secretariat:	Japan (JISC)
 (b)  CCITT WP:	SG VII/WP IV

5.	Date Circulated by WG Secretariat:

6.	Deadline for Response from Editor:

7.	Defect Report Concerning:
 (number and title of IS or DIS final text/CCITT 
recommendation)

X.509 & IS 9594-8 The Directory - Authentication Framework - 
Amendment 1 on Certificate Extensions

8.	Qualifier:   (e.g.: error, omission, clarification required)	

Omission

9.	References in Document:  (e.g.: page, clause/section, 
figure, and/or table numbers)

 12.2.2.3

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

The current key usage flags do not allow for public key usage 
with key agreement mechanism with different public keys for 
data sent and received.

11.	Solution Proposed by the Source:  (optional)

Add to Key Usage BIT STRING
		send	(7),
		receive      (8) }

Add to end of item list:

	h) send: for protecting data sent from the subject 
		(used with key agreement)
	i) receive: for protecting data for receipt by the 
            subject (used with key agreement)

12.	Editor's Response:

(any material proposed for processing as an erratum to, an 
amendment to, or a commentary on the IS or DIS final 
text/CCITT Recommendation or Draft Recommendation is attached 
separately to this completed report).

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: [email-masked] (Denis Pinkas)
Subject: Re: Private key validity period
To: [email-masked]
Date: Wed, 16 Oct 1996 09:24:14 +0100 (NFT)
Cc: [email-masked], [email-masked], [email-masked]

David Chadwick has expressed a disagreement about my presentation 
of the concerns I had about the private key validity period. I 
believe that we have a conflict on the terminology to be used, 
but not on the basic concepts. 

I think that in any case we need to improve the current text as 
it is obvious that we have problems with that text (otherwise we 
would not have that discussion !).

Within the core document (ITU-T Rec. X.509 (1993 E) section 8 
says :

" TA indicates the period of the validity of the certificate, and 
consists of two dates, the first and last on which the 
certificate is valid".

This is not crystal clear.

While we were finalizing the standard in Bristol many years ago 
we recognized that we were dealing with the use of certificates 
for the security of the Directory itself and not for the use by 
other applications for different purposes. At that time we talked 
about further contraints that would be needed for non repudiation 
purposes but they were not incorporated because non repudiation 
was not at this time a security service used by the Directory.

Basically public/private key were only used for "entity 
authentication" or "data origin authentication with integrity" 
and hence there were no difference between the period of use of 
the public key and of the private key, because they were 
identical. So no confusion arised.

Since then, we recognize two NEW different usages of the 
certificates. 

1) for long term encryption, and
2) for non repudiation purposes, which is similar to long term 
signatures.

Let us start by long term encryption. When we have a certificate 
which contains a key to be used for user data encryption we 
should make sure that the public key which is used to encrypt the 
data is valid. The validity period which is within the 
certificate corresponds to the period of validity of the public 
key (during which we can safely encrypt the data). The period of 
validity of the private key is NOT mentioned but is NOT 
IDENTICAL. If we encrypt something today under the public key of 
an entity then that entity should normally be allowed to decrypt 
it, let us say, two years later. If there is no other date 
present within the certificate then the period of validity of the 
private key is unlimited. If there is an additional date for the 
validity of the private key then one possible interpretation of 
it would be to say that the private key is no more valid after 
that date. This would mean that the data encrypted under that 
long term key is no more safe and thus should be either destroyed 
or re-encrypted under another safer key. We should notice that 
most of the time such data has lost its value and re-encryption 
is not always necessary.

This might give us one argument to consider if we support an 
extension for the validity of the private key.

Let us continue by non repudiation. Before talking about the 
validity periods, it is necessary to come back to the basics of 
non repudiation. Non repudiation allows to prove that some kind 
of event or action occurred and allows to prove it years after 
that event or action occured. This is a more complicated topic 
because some people do not yet make the difference between a 
digital signature (which is a security MECHANISM) and non 
repudiation (which is a security SERVICE). Without going into the 
full details, a digital signature just used alone does NOT 
provide non repudiation. Some kind of proof about WHEN the event 
or action really occured must be produced. One easy way (but not 
the single) to produce it, is to counter-sign the information 
signed by an entity with a counter-signature from an entity being 
trusted to place the right time within its counter-signature 
signature (this is the Time Stamping Authority). The original 
message from the entity may/must also contain an indication of 
the time. When both times are "closed enough" (e.g. 2, 12 or 24 
hours) then the evidence may be considered as valid provided that 
other conditions are met.

Starting from now we know exactly when the signature was 
generated with an error limited to, e.g., 2, 12 or 24 hours. The 
question is: which certificate should we use today to verify a 
digital signature which is ten years old ?

We should use a certificate with a validity period which covers 
the time when the digital signature was originally produced. We 
also have to make sure that it was not revoked at the time the 
digital signature was produced (it may have been revoked latter, 
but we do not care).

The certificate guarantees that the private key is allowed to be 
safely used to sign evidences during that period but that the 
public key may still be used long after to verify signatures 
issued during that period. In this way I said that the duration 
of use of the private key was indicated by the period of use 
which is within the certificate, but as the public was usable to 
verify old signatures long after, that its period of use was not 
limited, unless this was said otherwise by some additional 
information.

In the Draft Amendment 1 to ITU-T Rec. X.509 (1993 E) the text 
from secion 12.2.1, item d)  says :

"The private key corresponding to a certified public ley is 
typically used over a different period from the validity of the 
public key. For example, with digital signature keys, the usage 
period of the signing private key is typically shorter than that 
of the verifying public key".

I globally agree with this. But the text says thenafter:

" The validity period of the certificate indicates a period for 
which the public key may be used, which is necessarilly not the 
same as the usage period of the private key."

The problem is that the text omits to say what kind of use is 
permitted with the key, hence the confusion latter. The text 
continues with:

" In the event of a private key compromise, the period of 
exposure can be limited if the signature verifier knows the 
legitimate period of the private key. There is therefore a 
requirement to be able to indicate the usage period of the 
private key in the certificate."

I disagree with this. This makes the implicit assumption that 
such certificates would be long lived (e.g. the story on 50 years 
valid certificates) which is unnecessary and created the 
questions whether CRLs would be needed during 50 years. In the 
event of a private key compromise, there are two responses: if 
the key is compromised after the certificate has expired there is 
no problem. If it is compromised before the certificate has 
expired, then CRLs have to be used AND a proof about WHEN the 
event or action really occured must be produced. 

When there is a problem, the ISO rules state that first an 
explanation must be given AND then a proposed alternative text 
must be produced.

Here is my proposed text replacement for all that item.

"The private key corresponding to a certified public ley is 
typically used for a different use and over a different period of 
time from the use and the validity period of the public key. For 
example, with digital signature keys, the usage period of the 
signing private key is typically shorter than that of the 
verifying public key. The validity period of the certificate 
indicates a period for which the public key may be used, when it 
is an encryption key to encrypt data within the validity period 
of the certificate or when it is a signature verification key, to 
verify digital signatures generated during that validity period."

Then within the section 12.2.2.2. the privateKeyUsagePeriod is 
defined as :

" The privateKeyUsagePeriod field indicates the period of use of 
the private key corresponding to the certified public key."

This is vague enough to be acceptable or ... interpreted 
differently by every one.

"Notes"

Are the notes normative in an ISO document ? The answer is no. 
So there is nothing wrong in the normative part of the standard, 
... except that the two following informative notes are incorrect 
and misleading.

"1. The period of use of the private key may be different from 
the period of valid use of the corresponding public key which is 
indicated by the certificate validity period. "

What is that "valid use" is not defined.

"For example, with digital signature keys, the usage period for 
the signing private key is typically much shorter than that for 
the verifying public key."

Correct, by the use is different.

"2. Using the mechanisms described in this standard, a public key 
should only be used for signature verification if a valid 
certificate still exists."

No. Certificates can exist for ever but their validity periods 
may be different. The "existance" is not the concern. A correct 
statement would be : "Using the mechanisms described in this 
standard, a public key should only be used for signature 
verification if the time of the signature generation is included 
in the validity period indicated within the certificate.".

"Signature verification after all certificates for the 
verification of the public key has expired can only be achieved 
using additional mechanisms such as secure archival ot trusted 
notary services."

No. Unless we add a new field that would be called 
"publicKeyUsagePeriod" there is no limitation of use. An expired 
certificate can be used to verify signatures generated at the 
time the certificate was valid. Look at the Non Repudiation 
Framework from ISO / SC 21.

The single argument for having a privateKeyUsagePeriod field does 
NOT relate to signature purposes but to encryption purposes. 

However this field may be useful to indicate when the private key 
will be "invalid". This means that this key should not be used 
anymore for data DECRYPTION purposes because the data that is 
protected would become vulnerable. It indicates that before the 
expiration of this time period, the data encrypted under that 
public key had better to be destroyed or re-encrypted. Attaching 
the certificate to that data is an easy way to remember when such 
action should take place. An example would be to say that a 1200 
bits key is fine to be used from today till 2 years from now but 
that the data protected under it is safe during 6 years only. The 
certificate will be valid during 2 years while the private key 
extension would mention 6 years.

Proposed correction:

" The privateKeyUsagePeriod field indicates, for an encryption 
key, the period of use of the private key corresponding to the 
certified public key. It indicates when the data protected under 
that public will be considered to be unsafe. Actions like re-
encryption of that data or destruction of that data should 
normally take place before that date".

Now if we consider the case of the signature, the role of the 
public key and the private key are reversed. Hence we could 
define a publicKeyUsagePeriod field. That field may be useful to 
indicate when the public key will be "invalid". This means when 
this key should not be used anymore for signature verification 
purposes because the corresponding private key could be cracked 
at this time. It indicates that at this time, you had better to 
use a additional mechanisms such as secure archival or trusted 
notary services. 

Proposed text. 

"For a signature verification key, while the validity period of 
the certificate indicates a period for which the public key may 
be used to verify digital signatures generated during that 
validity period, the publicKeyUsagePeriod field indicates 
indicates a period for which the public key may be used to verify 
digital signatures".

This avoids the use of the terme "private key" in this statement, 
an alternative wording would however be :

" For a signature verification key, while the validity period of 
the certificate indicates a period for which the private key may 
be used to generate digital signatures during that period, the 
publicKeyUsagePeriod field indicates indicates a period for which 
the public key may be used to verify digital signatures".

May be there are other ways to express the same ideas and I do 
not care about the exact wording as long as it provides the right 
explanations.

Denis.
-- 

============================================================================
      Denis Pinkas                           E-mail : [email-masked]
      Bull S.A.                                                             
      Rue Jean Jaures  B.P. 68                Phone : (33-1) 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE       Fax  : (33-1) 30 80 33 21
============================================================================

Date: Tue, 15 Oct 1996 17:04:02 -0700 (PDT)
From: "Patrick C. Richard" <[email-masked]>
To: Tim Dean <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: certificates and CRLs - access and storage

> On Fri, 11 Oct 1996, Tim Dean wrote:
> 
> > Date: Fri, 11 Oct 1996 16:21:28 +0000
> > From: Tim Dean <[email-masked]>
> > To: [email-masked], [email-masked]
> > Subject: certificates and CRLs - access and storage
> > 
> > Has anyone out there had experience in storing 
> > X.509 certificates/certificate revocation lists on a slapd server?  Are 
> > there any pitfalls that we should know about?  What are the problems with 
> > using LDAP to retrieve certificates/CRLs? 
> 

The CA demo site at http://www.x509.com has always been using
LDAP/SSL-LDAP as the basis for it's PKI.

We have solved the access issues by using SSL LDAP and incorporating
client authentication with the native ACL mechanisms in the Umich 
implementation.

The beauty is that you can have a context-sensitive PKI (and for that
matter, object distribution) by basing the results of the LDAP query
on some portion of the connecting client DN, which is "guaranteed" by the
use of strong authentication.

Pat Richard
[email-masked]

> 
> > 
> > Any helpful hints/pointers gratefully received!
> > 
> > Tim Dean
> > DRA-Malvern
> > UK
> > 
> 

From: Peter Williams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: v4 suggestion
Date: Tue, 15 Oct 1996 16:29:44 -0700

My proposal to use the v4 version identifier, where the certificate =
contains
Extensions element is indeed not possible. The principal objections
seem to be coming from US Govt sources, and are to date without
stated grounds.

If extensions are provided, the version number must be v3. Unless a =
post-TC1
defect is agreed, no later version may use the extensions field.

The followign is a semi-sensible proposal, mainly put foward
to air issues and concerns. I can see no reason why
v4 certs should be avoided; in fact a clean break would
do wonders, I feel. v1, v2 and v3 certs are still usable in
such a framework, yet v4 semantics are clear.for v4 systems
which can process the changed syntax.

We should define a v4 cert. As required, the v3 extensions element shall
be empty. A v4 format might be introduced, as a v2 cert + the following
informal editing instruction which amends the TC1:

In the ASN.1 specification for Certificate, make the following changes:

.	In the comment for issuerUniqueID, replace "must be v2" with "must be =
v2 or v3"
.	In the comment for subjectUniqueID, replace "must be v2" with "must =
be v2 or v3"
.	Add the following as a new element to the end of the sequence:
=09
	extensions		[3]	Extensions OPTIONAL
					-- If present, version must be v3 --    }	}

	pkix			[4]	PublicKeyInfrastructureExtensions OPTIONAL
						-- If present, version must be v4 or later --    }	}

Add the following, immediately below the ASN.1 specification for =
SubjectPublicKeyInfo:

Extensions ::=3D SEQUENCE OF Extension

For those extensions where ordering of individual extensions within the =
SEQUENCE is significant, the specification of those individual =
extensions shall include the rules for the significance of the ordering.

Extension ::=3D SEQUENCE {
	extnId		EXTENSION.&id ({ExtensionSet}),
	critical		BOOLEAN DEFAULT FALSE,
	extnValue		OCTET STRING
				-- contains a DER encoding of a value of type &ExtnType
				-- for the extension object identified by extnId -- }

-- Definition of the following information object set is deferred, =
perhaps to=20
-- standardized profiles or to protocol implementation conformance =
statements.
	ExtensionSet	EXTENSION	::=3D	{  ... }

The extensions field allows addition of new fields to the structure =
without modification to the ASN.1 definition.  An extension field =
consists of an extension identifier, a criticality flag, and a canonical =
encoding of a data value of an ASN.1 type associated with the identified =
extension.  When an implementation processing a certificate does not =
recognize an extension, if the criticality flag is FALSE, it may ignore =
that extension.  If the criticality flag is TRUE, unrecognized =
extensions shall cause the structure to be considered invalid, i.e., in =
a certificate, an unrecognized critical extension would cause validation =
of a signature using that certificate to fail.

	Add the following, immediately below the ASN.1 specification for =
ExtensionSet:

PublicKeyInfrastructureExtensions ::=3D SEQUENCE {
	reliancePeriod	LifeTime OPTIONAL,=20
	extensions	Extensions OPTIONAL
	-- either lifetime or extensions shall be present
 }

The reliancePeriod field  consists of two generalized time fields, =
delimiting the period within which a user
may rely upon the certificate. If present, conforming certificate =
validation processes shall restrict valid use
of the certificate to the period specified

LifeTime ::=3D SEQUENCE {
	notUsedBefore		GeneralizedTime, -- local time is not permitted
	notUserAfter		GeneralizedTime -- local time is not permitted
 }

The following object class is used to define specific extensions.

Specificextensions may be defined in ITU-T Recommendations | =
International Standards or by any organizations which has a need.  The =
object indentifier which identifies an extension shall be defined in =
accordanc with ITU-T Rec. X.660 | ISO/IEC 9834-1.

EXTENSION ::=3D CLASS
{
	&id		OBJECT IDENTIFIER UNIQUE,
	&ExtnType
}
WITH SYNTAX
{
	SYNTAX		&ExtnType
	IDENTIFIED BY	&id
}

Date: Tue, 15 Oct 1996 16:18:42 -0400
From: "James A. Ruby" <[email-masked]>
Reply-To: [email-masked]
Organization: Computer Sciences Corporation
To: [email-masked]
Subject: list

list

To: Mark Bartel <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: X.509 validity period 
Date: Tue, 15 Oct 1996 12:37:33 -0400
From: "Charles W. Gardiner" <[email-masked]>

    The interpretation of the CHOICE should be a trivial matter to anyone who
uses an ASN.1 compiler.  It's a little easier to do than providing for v4.
Since v4 might open up a big can of worms and delay the solution into the next
millenium, I'd go with the CHOICE.

Charlie Gardiner

From: "Robin Garner" <[email-masked]>
To: <[email-masked]>
Subject: Unsubscribe
Date: Tue, 15 Oct 1996 09:07:35 +1000

As many others have found, the usual methods of unsubscribing to a list
haven't worked, so I apologize for adding to the noise.

Can someone please unsubscribe me, [email-masked]

Thanks in advance

From: ADRIAN GARCIA-SIERRA <[email-masked]>
To: ietf-pkix <[email-masked]>
Date: Tue, 15 Oct 1996 10:06:37 GMT
Subject: Re: Unsubscribe
Priority: normal

Likewise, could I also be removed from this list.....thank you.
Adrian 
<[email-masked]> <[email-masked]>

> From:          Robin Garner <[email-masked]>
> To:            ietf-pkix <[email-masked]>
> Subject:       Unsubscribe
> Date:          Tue, 15 Oct 1996 09:07:35 +1000

> As many others have found, the usual methods of unsubscribing to a list
> haven't worked, so I apologize for adding to the noise.
> 
> Can someone please unsubscribe me, [email-masked]
> 
> Thanks in advance
> 

       ------------------------------------------------------------------
Adrian J Garcia-Sierra            [email-masked] 
EC Innovation Centre	    tel:    +44 (0)1222 874271
University of Wales, Cardiff    fax: +44 (0)1222 874301
http://www.cf.ac.uk/uwcc/masts/ecic/
       ------------------------------------------------------------------

From: "Robin Garner" <[email-masked]>
To: <[email-masked]>
Subject: Unsubscribe
Date: Tue, 15 Oct 1996 09:07:35 +1000

As many others have found, the usual methods of unsubscribing to a list
haven't worked, so I apologize for adding to the noise.

Can someone please unsubscribe me, [email-masked]

Thanks in advance

From: "Robin Garner" <[email-masked]>
To: <[email-masked]>
Subject: Unsubscribe
Date: Tue, 15 Oct 1996 09:07:35 +1000

As many others have found, the usual methods of unsubscribing to a list
haven't worked, so I apologize for adding to the noise.

Can someone please unsubscribe me, [email-masked]

Thanks in advance

Date: Mon, 14 Oct 1996 13:23:32 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: proposal for validity period -Reply

Maybe the simplest approach would be to progress to v4, and 
simply change the definition of validity to be expressed in 
generalizedTime only.  The use of v1, v2, and v3  for notBefore 
dates after 1 January 2000 would be strongly deprecated.
The (minor) complexity caused by CHOICE would be avoided.

CAs could offer their customers a choice of v3 and v4 
certificates until the demand for v3 certificates subsides 
sufficiently.

Implementations would be strongly encouraged (by competitive 
pressure) to support the most current version, v4, but they could 
also continue to use v3, handling notBefore and notAfter dates 
as explicitly 2000 + N, so as not to perpetuate this into the next 
century. (We can probably defer support for 10,000AD until v5+
with relatively little risk. :-)

With this scheme, the CRL format would also advance to v3, 
supporting generalizedTime only.

I haven't thought about this too much, but would it be reasonable
to suggest that v3 certs be rejected with a v3 CRL, and v4 certs 
in a v3 CRL, publishing two CRLs in two different formats until 
all of the v3 certs have either expired or been revoked?

How many implementations are yet handling CRLs at all?  I think 
perhaps very few??? Maybe the CRL processing could jump to
v3 immediately??

Maybe CHOICE is more appropriate here? This obviously needs 
some more thought.

Bob

Robert R. Jueneman
Security Architect
NetWare Security R&D
Internet Infrastructure Division
Novell, Inc. M/S-PRV-D241
122 East 1700 South
Provo, UT 84606
801/861-7387

>>> <[email-masked]> 10/14/96 05:58am >>>
In two weeks I will be chairing a directory meeting where one of the agenda 
items is to process defect reports. I would like to see a consensus on this 
problem so that I can get a technical corrigendum approved and maybe get that TC 
incorporated in the published edition. The procedure is defect report being 
accepted; writing a draft technical corrigendum containing the corrective text; 
submitting the DTC to a three month ballot; processing the national body  and 
liaison organization votes and comments; if the resulting text is acceptable 
producing the Technical Corrigendum; and finally incorporating that TC into the 
next published edition of the standard.

[snip]

>I believe the choice of methods come down to three

>1) replace the UTCTime encoding with GeneralizedTime. As this would not only 
invalidate current implementations, but also currently issued certificates, this 
is not an acceptable solution.

Assuming that we progress to v4, at the same time,  I believe that this IS
and acceptable solution.

>2) replace the current encoding with a CHOICE encoding of both UTCTime and 
GeneralizedTime. This would invalidate current implementations but not currently 
issued certificates. As mentioned, I don't believe that a new version would help 
interoperability. The only way that this would be acceptable is to get agreement 
that implementations would adopt this new encoding in their implementation right 
away. We have done this before. In fact this is the definition of normal defect 
resolution. The resulting Technical Corrigendum fixes an error and each 
implementation should incorporate that TC as quickly as possible. Where there is 
significant implementation interest, the defect resolution group has liaised 
with the implementation groups. Normally, this would be the implementor 
workshops. However, in this case I would also expect the blessing of at least 
also the PKIX and SET groups.

Option 2 would be my second choice.

>3) generate a new extension that has the validity date encoded in 
GeneralizedTime. This would not necessarily invalidate implementations. That 
would depend on whether or not an implementation could successfully process  
year 2000 and greater dates encoded in UTCTime. That is, if one did not mandate 
the understanding of the extension, e.g. via the critical flag, the encoder 
would still have encode the date in the existing Validity field and receivers 
would have to understand some sort of wrap rule.

>I would like to make the following recommendation. I don't see the value of 
method three. Implementors would have to support both the extension and the wrap 
around rule for the existing Validity element. Unless we mandate support of the 
extension. If we are going to mandate anything, I recommend method two.

Agreed. Option 3 seems really ugly. I wouldn't like to see the now-useless 
UTCTime attribute carried around forever.

>Although implementations would have to change, method two could turn out to be 
the cleanest. I suggest we implement the CHOICE (I don't believe a new version 
would help, but then it couldn't hurt). To keep it simple, I further suggest 
that we not adopt any wrap around rule. That is, the current UTCTime Validity 
field could only be used for dates that are before 1 January 2000. I also 
suggest that we don't mix the two forms. That is, if the notAfter value is after 
31 December 1999, both it and the notBefore value shall be encoded in 
GeneralizedTime even though the notBefore value is prior to 1 January 2000.

The only question is whether there are already certificates in existence 
that have notAfter dates that are post-2000, and/or a substantial number of 
certificates with three + year validity periods will have to be issued in 1997.

Bob

Date: Mon, 14 Oct 1996 14:38:50 -0400
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: proposal for validity period
Cc: [email-masked], [email-masked]

Hoyt:

You have not covered the variation of your method 2) which includes a
wraparound rule for UTCTime.  This has two major advantages:

(a) it permits currently-issued certificates extending beyond 1999 to still
work;
(b) it lets us set a later date by which all certificate-processing systems
have to be upgraded to accommodate the GeneralizedTime option.  (For
example, we can declare, in implementors agreements, that no certificate
containing GeneralizedTime be issued before Jan 1, 2005.)

The implementation cost beyond your proposal is trivial.  In fact, I suspect
that all savvy implementors will implement the wraparound rule anyway, for
safety reasons and to be able to accept old certificates with dates beyond 1999.

The point I have been trying to make for some time is that we DON'T have a
year 2000 problem here - we have a year 2087 problem.  The wrong resolution
will CREATE for us a year 2000 problem.

There is no justification for causing a major upheaval to the stability of
X.509, which is inevitable if the CHOICE is introduced without a wraparound
rule and a provision such as (b).

I also recommend NOT to change the Version to 4 - this does not help, and
would cause its own set of problems.

Warwick

At 04:58 AM 10/14/96 MST, you wrote:
>In two weeks I will be chairing a directory meeting where one of the agenda 
>items is to process defect reports. I would like to see a consensus on this 
>problem so that I can get a technical corrigendum approved and maybe get
that TC 
>incorporated in the published edition. The procedure is defect report being 
>accepted; writing a draft technical corrigendum containing the corrective
text; 
>submitting the DTC to a three month ballot; processing the national body  and 
>liaison organization votes and comments; if the resulting text is acceptable 
>producing the Technical Corrigendum; and finally incorporating that TC into
the 
>next published edition of the standard.
>
>Although there has been some debate about whether it is necessary start
encoding 
>the validity period with a four digit year (thereby resolving this problem
until 
>the year 10000), I think that enough people have advocated solving the problem 
>in some fashion and solving it quickly.
>
>We must be careful about how generalized time is incorporated into the 
>certificate. I mentioned before that since the Validity element is not
optional, 
>is not possible to incorporate generalized time into a CHOICE under the
rules of 
>extensibility. I am not even sure the extensibility rules apply to the 
>certificate as the extension model used is closedr to that of X.400 rather
than 
>X.500). To understand how extensibility would apply, one must think as the 
>receiver. If an element were optional, the receiver must be prepared for the 
>absence of the element. If that element had been re-specified in a revision of 
>the ASN.1 as a CHOICE of it or another optional element, and if it were the
new 
>optional element of the CHOICE that was encoded and transmitted, the receiver 
>would, under the rules of extensibility, ignore the unknown element (unknown 
>since the receiver is processing according to the previous ASN.1
specification). 
>Even though the other element of the CHOICE is not present, the receiver would 
>still process correctly since the element is optional.
>
>However, as mentioned, since Validity is mandatory, the replacement of UTCTime 
>with GeneralizedTime would result in an encoding that would be viewed as 
>erroneous by a receiver processing via the earlier ASN.1 specification. Note 
>that calling this newer specification V4 still would not solve the 
>interoperability problem. That is, a V4 certificate would not be acceptable to 
>an implementation capable of processing only V3 and below. This is due to the 
>protocol being changed, i.e. GeneralizedTime instead of UTCTime, instead of 
>being extended, i.e. adding an additional Validity field constructed using 
>GeneralizedTime.
>
>I believe the choice of methods come down to three
>
>1) replace the UTCTime encoding with GeneralizedTime. As this would not only 
>invalidate current implementations, but also currently issued certificates,
this 
>is not an acceptable solution.
>
>2) replace the current encoding with a CHOICE encoding of both UTCTime and 
>GeneralizedTime. This would invalidate current implementations but not
currently 
>issued certificates. As mentioned, I don't believe that a new version would
help 
>interoperability. The only way that this would be acceptable is to get
agreement 
>that implementations would adopt this new encoding in their implementation
right 
>away. We have done this before. In fact this is the definition of normal
defect 
>resolution. The resulting Technical Corrigendum fixes an error and each 
>implementation should incorporate that TC as quickly as possible. Where
there is 
>significant implementation interest, the defect resolution group has liaised 
>with the implementation groups. Normally, this would be the implementor 
>workshops. However, in this case I would also expect the blessing of at least 
>also the PKIX and SET groups.
>
>(Note that use of IMPLICIT and EXPLICIT are not relevant in the CHOICE
decision; 
>it is only important that each element of the CHOICE be unambiguous with
respect 
>to each other, i.e. each element have a unique tag; UTCTime and
GeneralizedTime 
>each have unique UNIVERSAL tags.)
>
>3) generate a new extension that has the validity date encoded in 
>GeneralizedTime. This would not necessarily invalidate implementations. That 
>would depend on whether or not an implementation could successfully process  
>year 2000 and greater dates encoded in UTCTime. That is, if one did not
mandate 
>the understanding of the extension, e.g. via the critical flag, the encoder 
>would still have encode the date in the existing Validity field and receivers 
>would have to understand some sort of wrap rule.
>
>I would like to make the following recommendation. I don't see the value of 
>method three. Implementors would have to support both the extension and the
wrap 
>around rule for the existing Validity element. Unless we mandate support of
the 
>extension. If we are going to mandate anything, I recommend method two.
>
>Although implementations would have to change, method two could turn out to be 
>the cleanest. I suggest we implement the CHOICE (I don't believe a new version 
>would help, but then it couldn't hurt). To keep it simple, I further suggest 
>that we not adopt any wrap around rule. That is, the current UTCTime Validity 
>field could only be used for dates that are before 1 January 2000. I also 
>suggest that we don't mix the two forms. That is, if the notAfter value is
after 
>31 December 1999, both it and the notBefore value shall be encoded in 
>GeneralizedTime even though the notBefore value is prior to 1 January 2000.
>
>Of course we need to be sure we have a satisfactory DER for GeneralizedTime.
>
>Although I hope this approach is acceptable, what I believe is most
important is 
>coming to agreement quickly.
>
>  hoyt
>
>
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Mon, 14 Oct 1996 11:49:15 -0400
From: dave horvath <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: certificates and CRLs - access and storage

> 
> Has anyone out there had experience in storing 
> X.509 certificates/certificate revocation lists on a slapd server?  Are 
> there any pitfalls that we should know about?  What are the problems with 
> using LDAP to retrieve certificates/CRLs? 
> 
> Any helpful hints/pointers gratefully received!

	We have NOT been using sldapd, but here are some  
	general problem areas we encountered with LDAP V2 and QUIPU
	implementations :

		o String encoding -- be careful in LDAP V2 when storing 
		  signed items that are string encoded not to mistakenly
		  modify the Cert/CRL in the syntax handler either on the
		  client or server side.  
		  This could ultimately cause a problem during signature 
		  verification by producing a different DER encoding. 
		  We ran into everything from uppercasing of country
		  codes within DNs to changing of UTC times in the 
		  LDAP/DSAs we were using.

		  You should really avoid string handling of signed items
		  if possible by sending the actual ASN.1 over the wire.

		  LDAP V3 has the ;binary qualifier to enable that.

		o Watch the UTC time encodings.  We had one implementation
		  that was dropping seconds.

	Dave Horvath
	Chromatix, Inc.

> 
> Tim Dean
> DRA-Malvern
> UK
> 

From: [email-masked]
Date: Mon, 14 Oct 96 04:58:27 MST
To: [email-masked], [email-masked]
Subject: proposal for validity period

In two weeks I will be chairing a directory meeting where one of the agenda 
items is to process defect reports. I would like to see a consensus on this 
problem so that I can get a technical corrigendum approved and maybe get that TC 
incorporated in the published edition. The procedure is defect report being 
accepted; writing a draft technical corrigendum containing the corrective text; 
submitting the DTC to a three month ballot; processing the national body  and 
liaison organization votes and comments; if the resulting text is acceptable 
producing the Technical Corrigendum; and finally incorporating that TC into the 
next published edition of the standard.

Although there has been some debate about whether it is necessary start encoding 
the validity period with a four digit year (thereby resolving this problem until 
the year 10000), I think that enough people have advocated solving the problem 
in some fashion and solving it quickly.

We must be careful about how generalized time is incorporated into the 
certificate. I mentioned before that since the Validity element is not optional, 
is not possible to incorporate generalized time into a CHOICE under the rules of 
extensibility. I am not even sure the extensibility rules apply to the 
certificate as the extension model used is closedr to that of X.400 rather than 
X.500). To understand how extensibility would apply, one must think as the 
receiver. If an element were optional, the receiver must be prepared for the 
absence of the element. If that element had been re-specified in a revision of 
the ASN.1 as a CHOICE of it or another optional element, and if it were the new 
optional element of the CHOICE that was encoded and transmitted, the receiver 
would, under the rules of extensibility, ignore the unknown element (unknown 
since the receiver is processing according to the previous ASN.1 specification). 
Even though the other element of the CHOICE is not present, the receiver would 
still process correctly since the element is optional.

However, as mentioned, since Validity is mandatory, the replacement of UTCTime 
with GeneralizedTime would result in an encoding that would be viewed as 
erroneous by a receiver processing via the earlier ASN.1 specification. Note 
that calling this newer specification V4 still would not solve the 
interoperability problem. That is, a V4 certificate would not be acceptable to 
an implementation capable of processing only V3 and below. This is due to the 
protocol being changed, i.e. GeneralizedTime instead of UTCTime, instead of 
being extended, i.e. adding an additional Validity field constructed using 
GeneralizedTime.

I believe the choice of methods come down to three

1) replace the UTCTime encoding with GeneralizedTime. As this would not only 
invalidate current implementations, but also currently issued certificates, this 
is not an acceptable solution.

2) replace the current encoding with a CHOICE encoding of both UTCTime and 
GeneralizedTime. This would invalidate current implementations but not currently 
issued certificates. As mentioned, I don't believe that a new version would help 
interoperability. The only way that this would be acceptable is to get agreement 
that implementations would adopt this new encoding in their implementation right 
away. We have done this before. In fact this is the definition of normal defect 
resolution. The resulting Technical Corrigendum fixes an error and each 
implementation should incorporate that TC as quickly as possible. Where there is 
significant implementation interest, the defect resolution group has liaised 
with the implementation groups. Normally, this would be the implementor 
workshops. However, in this case I would also expect the blessing of at least 
also the PKIX and SET groups.

(Note that use of IMPLICIT and EXPLICIT are not relevant in the CHOICE decision; 
it is only important that each element of the CHOICE be unambiguous with respect 
to each other, i.e. each element have a unique tag; UTCTime and GeneralizedTime 
each have unique UNIVERSAL tags.)

3) generate a new extension that has the validity date encoded in 
GeneralizedTime. This would not necessarily invalidate implementations. That 
would depend on whether or not an implementation could successfully process  
year 2000 and greater dates encoded in UTCTime. That is, if one did not mandate 
the understanding of the extension, e.g. via the critical flag, the encoder 
would still have encode the date in the existing Validity field and receivers 
would have to understand some sort of wrap rule.

I would like to make the following recommendation. I don't see the value of 
method three. Implementors would have to support both the extension and the wrap 
around rule for the existing Validity element. Unless we mandate support of the 
extension. If we are going to mandate anything, I recommend method two.

Although implementations would have to change, method two could turn out to be 
the cleanest. I suggest we implement the CHOICE (I don't believe a new version 
would help, but then it couldn't hurt). To keep it simple, I further suggest 
that we not adopt any wrap around rule. That is, the current UTCTime Validity 
field could only be used for dates that are before 1 January 2000. I also 
suggest that we don't mix the two forms. That is, if the notAfter value is after 
31 December 1999, both it and the notBefore value shall be encoded in 
GeneralizedTime even though the notBefore value is prior to 1 January 2000.

Of course we need to be sure we have a satisfactory DER for GeneralizedTime.

Although I hope this approach is acceptable, what I believe is most important is 
coming to agreement quickly.

  hoyt

Date: Sun, 13 Oct 1996 22:47:03 -0700
From: [email-masked] (Venus Chow)
To: [email-masked]

To: Bob Jueneman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: generalizedTime not (very) well defined. 
Date: Sat, 12 Oct 1996 08:17:31 -0400
From: Bill Sommerfeld <[email-masked]>

> [I had mentioned that someone who logs on at 3:00 AM EST 
> probably deserves to be included in the audit log as a potentially 
> suspicious event, if they do so from within the Eastern time zone, but 
> not if they are located in London. There may be some merit in allowing a 
> certificate to define access rights in terms of local time of the user,
> especially for short-lived certificates granting temporary authority to
> someone, but clearly we also need to know the time in absolute
> terms.]

In this case, presumably the certificate must also need to list the
"normal" local time zone of the user as an offset from UTC --
otherwise the user could just lie about where they were at the time;
this implies application-specific certificate extensions.

I don't think you need to include/allow timezones in the certificate
validity timestamps to get this, and allowing timezones there
complicates *all* certificate validation code, not just code for apps
which care about timezones due to time-of-day based lockouts..

					- Bill

Date: Sat, 12 Oct 1996 13:58:01 -0700
To: [email-masked], [email-masked]
From: Kaye Caldwell <[email-masked]>
Subject: ** Oct. 22 Calif. Dig. Sig. Working Group Meeting **

Interested Parties:

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

California Digital Signatures Regulations Working Group
=========================================
(sponsored by the Software Industry Coalition and CommerceNet)
         (Note: the Working Group is not the Task Force)

         MEETING DATE: Tuesday October 22, 1PM-4PM 
MEETING LOCATION: Burlingame, California

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:
[email-masked] 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 in order
to be sure we have adequate meeting space.)
PLEASE RSVP by the end of the day on Thursday 10/17/96.

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.  Topic: Non-repudiaton.
III..  Topic: Certificate subscriber liability.
IV. Review of current draft of outline of regulations

Web page for Background on the Working Group:

 http://www.softwareIndustry.org/coalition/dswgopen.html

Digital Signature Background page:

http://www.softwareIndustry.org/issues/1digsig.html

For more information, e-mail Kaye Caldwell at [email-masked] or call
408-479-8743.

Kaye Caldwell
Software Industry Coalition Policy Director
CommerceNet Adovocacy and Public Policy Committee Chair

From: Mark Bartel <[email-masked]>
Subject: Re: generalizedTime not (very) well defined.
To: [email-masked] (Bob Jueneman)
Date: Fri, 11 Oct 1996 12:58:11 -0400 (EDT)
Cc: [email-masked], [email-masked]

> David Boyce and I have been discussing the local vs. Z time options
> in generalizedTime, and I think the issue is worth raising to a wider 

Well, certificates must be DER encoded... are we using the definition
of DER from X.690 (11.7)?  It specifies:

1.  The encoding shall terminate with a "Z"

2.  Fractional seconds shall omit trailing '0's, and the '.' if there
are no trailing '0's,

3.  The decimal point shall be the point (ie '.' not ',')

4.  Midnight shall be "YYYYMMDD000000Z" (instead of "YYYYMMDD240000Z")

- Mark Bartel ([email-masked])

Comments: Authenticated sender is <[email-masked]>
From: "Tim Dean" <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 11 Oct 1996 16:21:28 +0000
Subject: certificates and CRLs - access and storage
Priority: normal

Has anyone out there had experience in storing 
X.509 certificates/certificate revocation lists on a slapd server?  Are 
there any pitfalls that we should know about?  What are the problems with 
using LDAP to retrieve certificates/CRLs? 

Any helpful hints/pointers gratefully received!

Tim Dean
DRA-Malvern
UK

Date: Fri, 11 Oct 1996 10:15:02 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: X.509 validity period -Reply -Reply

I was assuming that both times would be expressed in the same format. 
If not, notBefore could continue to be UTCTime until 1 Jan 2000, but I'm 
not sure what that buys you. 

I was primarily addressing the issue of what the validity period was. If 
98% of the certificates only have a one year validity period, then we
could wait until notBefore= 1 Jan 1999 before requiring support for 
generalizedTime in applications.

Bob

>>> Nick Pope <[email-masked]> 10/11/96 03:54am >>>
In reply to your message of 10 Oct 96, 11:38 from Bob Jueneman

This proposal is fine (except possibly implementors may want a bit more 
time with the not before date having to be generalised time.  I would have 
thought up to the year 31 Dec 1999 would have been OK.)

> To address one of Peter William's concern's, I would suggest that we
> not include the CHOICE option in version 1 or version 2 certificates.
> Those horses are already out of the barn, and implementations will
> either deal with the year 2000 problem or the implementors will
> (deservedly) go out of business. The same is true for any v3
> certificates which have been issued or will be issued using UTCTime
> and a notAfter date of post 2000.
> 
> I would recommend that we do the following:
> 
> 1.  Clearly define the wraparound year in the standard, both X.509 and
> the pkix document, so that if UTCTime is used it will be completely
> unambiguous as to which century is meant. We certainly don't want to
> have this problem occur again. 1 January 87 is 1987, while 31 December
> 86 is 2086. 
> 
> 2. Issue a defect report and a Technical Corrigendum to X.509 v3,
> adding the CHOICE option for generalizedTime.
> 
> 3. Deprecate the use of (but not the support for) UTCTime for 
> certificates with notAfter dates that are post 2K. (2000, not 2048!
> :-)
> 
> 4. Strongly deprecate the use of (but not the support for) 
> generalizedTime in certificates with notAfter dates of post 2K and
> notBefore dates prior to 1 January 1998. This will give implementors
> at least a year to fix the problem. At the rate that new features are
> coming out, I don't believe that this would be a problem.
> 
> (If the vast preponderance of certificates being issued have one year
> validity periods, we could relax that constraint to 1 Jan 1999, giving
> implementors a very generous two years. And of course even though the
> use of UTCTime will be deprecated, it won't be forbidden, so it would
> still be OK for longer-lived certificates, so long as the century rule
> is made completely unambiguous.)
> 
> Bob
> 
> 
> >>> Warwick Ford <[email-masked]> 10/09/96 09:47pm >>>
> It's kinda neat how the substitution of the CHOICE becomes gracefully
> possible, due to the use of EXPLICIT tagging.  This would not be
> possible with contemporary ASN.1 protocols that use IMPLICIT or
> AUTOMATIC tagging. So, let's take advantage of this situation.
> 
> Nevertheless, my main point has been to choose the right wraparound
> rule, and we can do that with CHOICE as well as we could with a new
> extension. For the UTCTime option of the CHOICE, we can say that
> values 00-87 mean 20xx and values 88-99 mean 19xx.  This still
> achieves my main goal which is that implementors really have to do
> nothing for a looooong time. 
> 
> Warwick
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: "Anil R. Gangolli" <[email-masked]>
Date: Fri, 11 Oct 1996 10:21:58 -0700
Reply-To: [email-masked]
To: David Boyce <[email-masked]>, [email-masked]
Subject: Re: X.509 validity period
Cc: [email-masked]

On Oct 11, 12:20pm, David Boyce wrote:
 > Subject: Re: X.509 validity period
 > "Anil R. Gangolli" writes:
 >
 > >I agree with the above that we should allow the values to be
 > >encoded independently, but I would like to clarify some points
 > >that I feel are being confused.
 >
 > Yes, my use of 'cutoff date' and your use of 'rollover year' are
 > essentially the same, and rollover year is clearer for this.
 >
 > >If we go with the CHOICE of GeneralizedTime and UTCTime proposal,
 > >Some things we need to agree on are:
 > >
 > >- a rollover year R for interpretation of UTCTime.
 > >
 > >- a cutoff date C < R when all compliant implementations would accept
 > the
 > >  CHOICE of UTCTime and GeneralizedTime.
 > >
 > >- dates after the rollover year R, not the cutoff date C, must
 > >  be encoded in GeneralizedTime.
 > >
 > >- The choice of which choice to take for years between 2000 and
 > >  the rollover year R does not depend on the value to be encoded.
 > >  Rather it depends on the time of encoding with respect to the cutoff year
C.
 >
 >
 > As I understand it, you are suggesting that dates between C and R may
 > be encoded either as UTCtime or as GeneralizedTime, depending on when
 > the encoding is performed relative to C.
 >
 > It would be a lot simpler to tie the selection of the choice to take to
 > the rollover year, so that _all_ dates prior to R are UTCtime, and all
 > dates from R onwards are GeneralizedTime.
 >
 > This is clear and readily understandable, makes comparisons easier
 > (don't have to muck about with multiple representations of the same
 > time) and likely to result in fewer mis-implementations.  A cutoff year
 > C is still required, to ensure that implementations will be ready for
 > the rollover year.

As usual I've not been clear enough.

Before time C it is not safe to use GeneralizedTime no matter what
value you are encoding because there are still compliant implementations
out there that won't recognize it.

After C, it is safe to use GeneralizedTime in both places and all compliant
implementations are guaranteed to understand it.  At that point use of
UTCTime in new encodings should be deprecated but must still be understood.

Hopefully C < R by a lot.

In both cases the choice depends on the encoders time relative to C
not on the value being encoded.  The rollover year R is just necessary
for encoding times after R when the encoding is performed before
time C.

--a.

Date: Fri, 11 Oct 1996 09:29:27 -0700
To: "Charles W. Gardiner" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: X.509 validity period 
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

All I really meant to convey was that we are fortunate to be able to
substitute a CHOICE for a primitive component of a SEQUENCE - this is not
something that you could get away with in many protocols (owing to IMPLICIT
tagging).

Warwick

At 11:52 AM 10/10/96 -0400, you wrote:
>
>    I'm a little puzzled about the statement that IMPLICIT tagging of a CHOICE
>in the validity dates would produce different encoding from EXPLICIT tagging.
>As I read the specs (I don't recall the chapter & verse), a CHOICE must always
>encode the tag of the chosen member.  Since the two alternatives are both
>universals, there is no differnece between IMPLICIT and EXPLICIT.  Were they 
>tagged with, say, context-specific tags, then there would be trouble.
>
>    Is this right?
>
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

To: Mark Bartel <[email-masked]>
cc: [email-masked] (Bob Jueneman), [email-masked]
Subject: Re: generalizedTime not (very) well defined.
Date: Fri, 11 Oct 1996 18:14:41 +0100
From: David Boyce <[email-masked]>

Mark Bartel writes:
>> David Boyce and I have been discussing the local vs. Z time options
>> in generalizedTime, and I think the issue is worth raising to a 
wider 
>
>Well, certificates must be DER encoded... are we using the definition
>of DER from X.690 (11.7)?  It specifies:
>
>1.  The encoding shall terminate with a "Z"
>
>2.  Fractional seconds shall omit trailing '0's, and the '.' if there
>are no trailing '0's,
>
>3.  The decimal point shall be the point (ie '.' not ',')
>
>4.  Midnight shall be "YYYYMMDD000000Z" (instead of "YYYYMMDD240000Z")
>
>- Mark Bartel ([email-masked])

Well, my comment that Bob quoted was intended to be illustrative of the 
precedent of constraining types by comments, but I confess I had 
overlooked the DER issues involved here;  anyway, this DER 
specification seems to settle the multiple representation question 
nicely.  Thanks, Mark.

David.
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	IC's WWW: http://www.isode.com/
X.400:	i=D;s=Boyce;o=ISODE Consortium;p=ISODE;a=MAILNET;c=FI;

Date: Fri, 11 Oct 1996 10:39:37 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: generalizedTime not (very) well defined.

David Boyce and I have been discussing the local vs. Z time options
in generalizedTime, and I think the issue is worth raising to a wider 
audience. I'm therefore quoting some of his points, and my response.

>>> David Boyce <[email-masked]> 10/11/96 09:35am >>>

Bob, thanks for clearing up those points.

Bob Jueneman writes:
>>the only point I would make is by restricting the syntax of 
generalizedTime 
>as has been proposed, we are really inventing a new data type.

>Well, perhaps a new sub-type.  There is precedent for this in X.501 
relating to Timestamps for Directory entries, where there is a comment 
after the attribute definition

>"... WITH SYNTAX GeneralizedTime ... -- as per clause 34.3 b) or c) of 
CCITT X.208 -- ..."

>following up the reference to X.208 (which for some reason appears to 
be clause 32.3 rather than 34.3), GeneralizedTime can be defined ..

	"a) ...., and with no terminating Z

	b) the characters in a) above followed by Z

	c) the characters in a) above followed by ... a local time 
	differential

	In case a), the time shall represent the local time.  In case b) the 
	time shall represent UTC time.  In case c), ... the time differential 
	enables UTC time to be determined."

>Interestingly, this constraint aligns with your suggestion rather well.

[I had mentioned that someone who logs on at 3:00 AM EST 
probably deserves to be included in the audit log as a potentially 
suspicious event, if they do so from within the Eastern time zone, but 
not if they are located in London. There may be some merit in allowing a 
certificate to define access rights in terms of local time of the user,
especially for short-lived certificates granting temporary authority to
someone, but clearly we also need to know the time in absolute terms.]

>From the standpoint of time in a certificate, obviously subtype 
(a) is out of the question. Both (b) and (c) are acceptable. 
Subtype (b) is simpler, but constitutes yet a further departure/restriction
from the basic definition of generalizedTime. Subtype (c) may convey
some useful information vis a vis audit and access control, and I think
it may be worth including.

However, from a philosophical standpoint, I am strongly opposed to 
defining allowable syntax in comments. I don't even like it much
with semantics, but we certainly have the ability to say precisely
what we mean in ASN.1, so the compiler can check the validity.

Maybe Bancroft Scott or someone who can write ASN.1 better than
I can could propose a tighter definition that would include options (b) and (c), 
but exclude (a).

Bob

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 validity period -Reply
Date: Fri, 11 Oct 1996 09:58:51 -0700

Peter Williams recommends the version v4 be used be used to signal
to all conforming systems that the authentication framework being
agreed between the parties is using v3 procedures, along with v4 format
which is the same as v3 format except for "the new validity date coding and handling procedures".

Peter Williams further recommends v4 simply replace UTCTime with GeneralizedTime.

Peter Williams further suggests that ISO clarify whether cert encodings should
use the rules in the X.509 std, else the rules in some other std. X.509 v2
currently says cert to be signed must be encoded in BER, as constrained by the rules
which X.509 (alone) lists. Peter suggests an explcit rule be added by defect for
the encoding Generalizedtime for use in signing.
 
I assume ISO will effect the validity date syntax issues (and hopefully
introduce v4 to signal the format change), and IETF profile will handle the handling rules for its
profile, if there is to be any downgrade in vendor systems to the (present) v3 rules. An ISO std with
2000 years ahead of it should not be tied to the 20th or 21st century.

Make a clean break, and just go to v4. It can be introduced by defect report as
was v3, to circumvent the horrendous ISO process. the AM which merely
introduced std extensions is unaffected. Any text which might be 
"v3" specific shoudl be cleanedup up during the current process of
incorporating the AM into X.500 version 3, if the AM is accepted by ISO.

then, its upto IETF vendors, not ISO, if they wish to supprot v3 and their UTC dates, and
Mark's/Bob's/Warwick's date downgrade rules, and how they  supprot and migrate their existing
communties with mixed older and new software. Mark should write up the rules
and get it posted to the IDs for the WG.
 
Peter Williams also recommends that the X.509 text on validity be improved in X.509 so
that validity of the security service claiming NR is clarifed, when the a v3 std
extension indicating key usage/prupose  with value of signature vs non-repudiation
is present. Does a valid certificate have different semantics upon the nature
of a security service defined to provide NR when the purpose bit value is different,
in this dinstinct manner?

Peter.

----------
From: 	Nick Pope
Sent: 	Friday, October 11, 1996 2:54 AM
To: 	[email-masked]; Bob Jueneman
Cc: 	[email-masked]; [email-masked]
Subject: 	RE: X.509 validity period -Reply

In reply to your message of 10 Oct 96, 11:38 from Bob Jueneman

This proposal is fine (except possibly implementors may want a bit more 
time with the not before date having to be generalised time.  I would have 
thought up to the year 31 Dec 1999 would have been OK.)

> To address one of Peter William's concern's, I would suggest that we
> not include the CHOICE option in version 1 or version 2 certificates.
> Those horses are already out of the barn, and implementations will
> either deal with the year 2000 problem or the implementors will
> (deservedly) go out of business. The same is true for any v3
> certificates which have been issued or will be issued using UTCTime
> and a notAfter date of post 2000.
> 
> I would recommend that we do the following:
> 
> 1.  Clearly define the wraparound year in the standard, both X.509 and
> the pkix document, so that if UTCTime is used it will be completely
> unambiguous as to which century is meant. We certainly don't want to
> have this problem occur again. 1 January 87 is 1987, while 31 December
> 86 is 2086. 
> 
> 2. Issue a defect report and a Technical Corrigendum to X.509 v3,
> adding the CHOICE option for generalizedTime.
> 
> 3. Deprecate the use of (but not the support for) UTCTime for 
> certificates with notAfter dates that are post 2K. (2000, not 2048!
> :-)
> 
> 4. Strongly deprecate the use of (but not the support for) 
> generalizedTime in certificates with notAfter dates of post 2K and
> notBefore dates prior to 1 January 1998. This will give implementors
> at least a year to fix the problem. At the rate that new features are
> coming out, I don't believe that this would be a problem.
> 
> (If the vast preponderance of certificates being issued have one year
> validity periods, we could relax that constraint to 1 Jan 1999, giving
> implementors a very generous two years. And of course even though the
> use of UTCTime will be deprecated, it won't be forbidden, so it would
> still be OK for longer-lived certificates, so long as the century rule
> is made completely unambiguous.)
> 
> Bob
> 
> 
> >>> Warwick Ford <[email-masked]> 10/09/96 09:47pm >>>
> It's kinda neat how the substitution of the CHOICE becomes gracefully
> possible, due to the use of EXPLICIT tagging.  This would not be
> possible with contemporary ASN.1 protocols that use IMPLICIT or
> AUTOMATIC tagging. So, let's take advantage of this situation.
> 
> Nevertheless, my main point has been to choose the right wraparound
> rule, and we can do that with CHOICE as well as we could with a new
> extension. For the UTCTime option of the CHOICE, we can say that
> values 00-87 mean 20xx and values 88-99 mean 19xx.  This still
> achieves my main goal which is that implementors really have to do
> nothing for a looooong time. 
> 
> Warwick
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Mark Bartel <[email-masked]>
Subject: Re: X.509 validity period
To: [email-masked]
Date: Fri, 11 Oct 1996 12:40:36 -0400 (EDT)

[Sorry I'm not responding to other messages on the list, but they all
ended up on my home machine, and aren't accessible here]

I think I've changed my mind...  I'm beginning to think that a better
solution than the CHOICE one would be to:

1) specify that UTCTime covers the years 1988-2087 when v3
certificates are being used;

2) specify v4 certificates with GeneralizedTime.

3) depreciate v3

This

1) forces another version... but we're doing that anyway (essentially)

2) removes the need for interpretation of the CHOICE type

3) explicitly declares the UTCTime validity period to be obsolete, so
that vendors will be obligated to change

4) allows the implementor to choose UTCTime or GeneralizedTime based
purely on the version number and not any strange criteria

I hope this hasn't already been discussed and I just missed it.

What do people think?

Btw, it's thanksgiving here this weekend (Canadian) so I won't be back
until wednesday (probably).

- Mark Bartel ([email-masked])

To: [email-masked]
cc: [email-masked]
Subject: Re: X.509 validity period
Date: Fri, 11 Oct 1996 12:20:16 +0100
From: David Boyce <[email-masked]>

"Anil R. Gangolli" writes:

>I agree with the above that we should allow the values to be
>encoded independently, but I would like to clarify some points
>that I feel are being confused.

Yes, my use of 'cutoff date' and your use of 'rollover year' are 
essentially the same, and rollover year is clearer for this.

>If we go with the CHOICE of GeneralizedTime and UTCTime proposal,
>Some things we need to agree on are:
>
>- a rollover year R for interpretation of UTCTime.
>
>- a cutoff date C < R when all compliant implementations would accept 
the
>  CHOICE of UTCTime and GeneralizedTime.
>
>- dates after the rollover year R, not the cutoff date C, must
>  be encoded in GeneralizedTime.
>
>- The choice of which choice to take for years between 2000 and
>  the rollover year R does not depend on the value to be encoded.
>  Rather it depends on the time of encoding with respect to the cutoff year C.

As I understand it, you are suggesting that dates between C and R may 
be encoded either as UTCtime or as GeneralizedTime, depending on when 
the encoding is performed relative to C.

It would be a lot simpler to tie the selection of the choice to take to 
the rollover year, so that _all_ dates prior to R are UTCtime, and all 
dates from R onwards are GeneralizedTime.

This is clear and readily understandable, makes comparisons easier 
(don't have to muck about with multiple representations of the same 
time) and likely to result in fewer mis-implementations.  A cutoff year 
C is still required, to ensure that implementations will be ready for 
the rollover year.

>  For interoperability/compatiblity any early adopters should not
>  choose GeneralizedTime until after year C, regardless of the value
>  being encoded.   This probably needs to be part of the standard.

David.
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	IC's WWW: http://www.isode.com/
X.400:	i=D;s=Boyce;o=ISODE Consortium;p=ISODE;a=MAILNET;c=FI;

From: Nick Pope <[email-masked]>
To: [email-masked], Bob Jueneman <[email-masked]>
Date: Fri, 11 Oct 1996 09:54:48 +0000
Subject: RE: X.509 validity period -Reply
CC: [email-masked], [email-masked]
Priority: normal

In reply to your message of 10 Oct 96, 11:38 from Bob Jueneman

This proposal is fine (except possibly implementors may want a bit more 
time with the not before date having to be generalised time.  I would have 
thought up to the year 31 Dec 1999 would have been OK.)

> To address one of Peter William's concern's, I would suggest that we
> not include the CHOICE option in version 1 or version 2 certificates.
> Those horses are already out of the barn, and implementations will
> either deal with the year 2000 problem or the implementors will
> (deservedly) go out of business. The same is true for any v3
> certificates which have been issued or will be issued using UTCTime
> and a notAfter date of post 2000.
> 
> I would recommend that we do the following:
> 
> 1.  Clearly define the wraparound year in the standard, both X.509 and
> the pkix document, so that if UTCTime is used it will be completely
> unambiguous as to which century is meant. We certainly don't want to
> have this problem occur again. 1 January 87 is 1987, while 31 December
> 86 is 2086. 
> 
> 2. Issue a defect report and a Technical Corrigendum to X.509 v3,
> adding the CHOICE option for generalizedTime.
> 
> 3. Deprecate the use of (but not the support for) UTCTime for 
> certificates with notAfter dates that are post 2K. (2000, not 2048!
> :-)
> 
> 4. Strongly deprecate the use of (but not the support for) 
> generalizedTime in certificates with notAfter dates of post 2K and
> notBefore dates prior to 1 January 1998. This will give implementors
> at least a year to fix the problem. At the rate that new features are
> coming out, I don't believe that this would be a problem.
> 
> (If the vast preponderance of certificates being issued have one year
> validity periods, we could relax that constraint to 1 Jan 1999, giving
> implementors a very generous two years. And of course even though the
> use of UTCTime will be deprecated, it won't be forbidden, so it would
> still be OK for longer-lived certificates, so long as the century rule
> is made completely unambiguous.)
> 
> Bob
> 
> 
> >>> Warwick Ford <[email-masked]> 10/09/96 09:47pm >>>
> It's kinda neat how the substitution of the CHOICE becomes gracefully
> possible, due to the use of EXPLICIT tagging.  This would not be
> possible with contemporary ASN.1 protocols that use IMPLICIT or
> AUTOMATIC tagging. So, let's take advantage of this situation.
> 
> Nevertheless, my main point has been to choose the right wraparound
> rule, and we can do that with CHOICE as well as we could with a new
> extension. For the UTCTime option of the CHOICE, we can say that
> values 00-87 mean 20xx and values 88-99 mean 19xx.  This still
> achieves my main goal which is that implementors really have to do
> nothing for a looooong time. 
> 
> Warwick
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Peter Williams <[email-masked]>
To: "'Mark Bartel'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 validity period -Reply -Reply
Date: Thu, 10 Oct 1996 14:35:00 -0700

Mark,

Could you perhaps write an I-D and post it, so we decide the issue
based on stable and evolutionary positions? It doesn't have to be very long,
and can be pulled together from your previous mails; then we
can regain change control and some stability of all
the issues and mechanisms being addressed.

----------
From: 	Mark Bartel
Sent: 	Thursday, October 10, 1996 1:06 PM
To: 	Bob Jueneman
Cc: 	[email-masked]; [email-masked]
Subject: 	Re: X.509 validity period -Reply -Reply

> Regarding your implementation issue, I understand the need
> to parse the certificate into a form that may be more efficient 
> for processing. But couldn't you just keep the original string, 
> with  the offset, or else store the offset in a second variable?

Isn't that what I said?  Umm, no, I said that I'd need to keep track
of what form it used.  <shrug> You are correct that it isn't difficult
to deal with.  In any case, my intention was not to explain why such a
DER encoding was *necessary*, merely why it was *specified*. :)

I think the idea is that converting between UTC time and local time is
easier than having to keep around information about what form the time
was in, and in many cases the conversion to local time might not even
be necessary.  Standards should be as simple as possible, but no
simpler. :)

- Mark Bartel ([email-masked])

> 
> "SMOP" -- Small Matter of Programming.
> 
> Bob
> 
> >>> Mark Bartel <[email-masked]> 10/10/96 12:03pm >>>
> > I would also not be in any particular rush to prohibit the use of 
> > local time (GMT plus offset). Since the DER encoding will be 
> > unambiguous in any case, the use of local time may provide 
> > some additional and useful semantics, in particular to human users, 
> > and especially in the case of relatively short-lived certificates 
> > (such as for a watch officer.)
> 
> Doesn't the DER for GeneralizedTime specify that it must be in UTC
> time (ie. end with "Z")?  See 11.7.1 of X.690.
> 
> And the reason for this is so that an implementation can parse the
> certificate into whatever representation it wants, and then later on
> verify it by reconstiting the contents (my implementation does this,
> in fact).  If UTC wasn't specified, then I would have to keep track of
> whether it read a local time form with offset or UTC time.  As it is,
> I need to keep track of whether I've read GeneralizedTime or UTCTime.
> 
> - Mark Bartel ([email-masked])
> 
> 

Date: Thu, 10 Oct 1996 14:55:26 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: X.509 validity period -Reply -Reply

Did you see my set of four or five specific recommendations vis a vis 
deprecated vs. allowed, or have our messages crossed in the mail?

I suggested that we explicitly fix the UTCTime century ambiguity 
along the lines that Warwick recently suggested, i.e., that any time
after 1 Jan "87" and before 31 Dec "99" be unambiguously
defined to be 19xx, and everything else 20xx. The use of UTCTime 
for 2000 and beyond would be deprecated in favor of 
generalizedTime, and the inclusion of generalizedTime in certificates 
for dates prior to 1 January 1998 would be strongly deprecated.

Since deprecated doesn't imply "forbidden", neither applications
nor certificates should be rejected because they don't conform --
they should just be looked at with some distaste.

If we had had this discussion last year, this probably wouldn't be 
an issue. But now an ad hoc solution ("hack") is inescapable. 
That doesn't meant that we shouldn't fix the standard, though.

Bob

>>> Peter Williams <[email-masked]> 10/10/96 02:36pm >>>
Will a conforming cert validation program in 2000+ reject a cert
with a UTCTime tag on either of invalidity or syntax grounds?

Bob, I honestly think you just said no; it passes it as valid,
as non-conforming CAs/old-cets must be assumed.

Fun to see this group in a drop-dead-date discussion, like
all standards of merit!

Peter.

----------
From: 	Bob Jueneman
Sent: 	Thursday, October 10, 1996 1:15 PM
To: 	[email-masked]
Cc: 	[email-masked]
Subject: 	RE: X.509 validity period -Reply

Assuming that we determine an unambiguous roll-over year and 
merely deprecate the use of UTCTime after 2000, the certificate 
should not be rejected at all.

Bob

>>> Peter Williams <[email-masked]> 10/10/96 01:05pm >>>
Does this mean that X.500 DAP and conforming software receiving a cert in 2001 with
a UTCTime validity data should reject the cert as having a syntax error,
or a signature-invalid error? It affects the audit trails, and the handling
procedures for class of failures.

----------
From: 	Mark Bartel
Sent: 	Thursday, October 10, 1996 8:39 AM
To: 	David Boyce
Cc: 	[email-masked]
Subject: 	Re: X.509 validity period

> During encoding, the _value_ of notAfter (which is later in the 
> Validity sequence) is required for determining the _type_ of notBefore. 
>  This could be awkward in implementation, and seems unnecessary, since 
> a Validity which 'straddles' the cutoff date could equally well be 
> represented by a notBefore UTCtime and a notAfter GeneralizedTime.

I agree.  It just seemed inelegant to have one date of UTCTime and
another of GeneralizedTime.  But I don't think it's acceptable to have
the type of the notBefore date dependent upon the value of the
notAfter date (when you put it that way).  So I'd say we should remove
the restriction.  Of course, if applications *do* wish to always use
one or the other for both, this is fine too.

- Mark Bartel ([email-masked])

From: Peter Williams <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 validity period -Reply
Date: Thu, 10 Oct 1996 13:36:34 -0700

Will a conforming cert validation program in 2000+ reject a cert
with a UTCTime tag on either of invalidity or syntax grounds?

Bob, I honestly think you just said no; it passes it as valid,
as non-conforming CAs/old-cets must be assumed.

Fun to see this group in a drop-dead-date discussion, like
all standards of merit!

Peter.

----------
From: 	Bob Jueneman
Sent: 	Thursday, October 10, 1996 1:15 PM
To: 	[email-masked]
Cc: 	[email-masked]
Subject: 	RE: X.509 validity period -Reply

Assuming that we determine an unambiguous roll-over year and 
merely deprecate the use of UTCTime after 2000, the certificate 
should not be rejected at all.

Bob

>>> Peter Williams <[email-masked]> 10/10/96 01:05pm >>>
Does this mean that X.500 DAP and conforming software receiving a cert in 2001 with
a UTCTime validity data should reject the cert as having a syntax error,
or a signature-invalid error? It affects the audit trails, and the handling
procedures for class of failures.

----------
From: 	Mark Bartel
Sent: 	Thursday, October 10, 1996 8:39 AM
To: 	David Boyce
Cc: 	[email-masked]
Subject: 	Re: X.509 validity period

> During encoding, the _value_ of notAfter (which is later in the 
> Validity sequence) is required for determining the _type_ of notBefore. 
>  This could be awkward in implementation, and seems unnecessary, since 
> a Validity which 'straddles' the cutoff date could equally well be 
> represented by a notBefore UTCtime and a notAfter GeneralizedTime.

I agree.  It just seemed inelegant to have one date of UTCTime and
another of GeneralizedTime.  But I don't think it's acceptable to have
the type of the notBefore date dependent upon the value of the
notAfter date (when you put it that way).  So I'd say we should remove
the restriction.  Of course, if applications *do* wish to always use
one or the other for both, this is fine too.

- Mark Bartel ([email-masked])

Date: Thu, 10 Oct 1996 19:30:26 -0700
To: Mark Bartel <[email-masked]>, [email-masked] (Bob Jueneman)
From: Tim Dierks <[email-masked]>
Subject: Re: X.509 validity period -Reply
Cc: [email-masked], [email-masked]

At 11:03 AM -0700 10/10/96, Mark Bartel wrote:

>> I would also not be in any particular rush to prohibit the use of
>> local time (GMT plus offset). Since the DER encoding will be
>> unambiguous in any case, the use of local time may provide
>> some additional and useful semantics, in particular to human users,
>> and especially in the case of relatively short-lived certificates
>> (such as for a watch officer.)
>
>Doesn't the DER for GeneralizedTime specify that it must be in UTC
>time (ie. end with "Z")?  See 11.7.1 of X.690.
>
>And the reason for this is so that an implementation can parse the
>certificate into whatever representation it wants, and then later on
>verify it by reconstiting the contents (my implementation does this,
>in fact).  If UTC wasn't specified, then I would have to keep track of
>whether it read a local time form with offset or UTC time.  As it is,
>I need to keep track of whether I've read GeneralizedTime or UTCTime.

That's why I'd prefer that there be exactly one distinguished way to
correctly encode a time into a certificate; I don't want to have to
remember a whole bunch of information about the encoding in order to
reconstruct it. Thus, I propose that we go with the CHOICE proposal with
the restrictions that:
  - UTC times with years 00-86 represent the years 2000-2086.
  - Only times on or after 2087.01.01 should be encoded using GeneralizedTime.
    (Or before 1987, if someone should wish to do so).
  - All times should be encoded with seconds if and only if seconds is not
    equal to zero.
  - All times must have hours and minutes.

This means that there is exactly one correct encoding for any specifiable time.

Also, I don't have ISO 2014 or ISO 3307 (as referenced by GeneralizedTime
in X.208), so I don't know what parts are optional. I'd recommend that
tenths of seconds be treated like seconds: encoded only if non-zero. I
believe we should also specify a DER encoding for the seperator. (X.690
probably deals with this; I don't have that, either.) [Doesn't working with
unavailable standards suck?]

 - Tim

Tim Dierks - Software Haruspex - [email-masked]

"And I tell you, we are here on earth to fart around, and don't let anybody
tell you any different." - Kurt Vonnegut quoted in "Inc. Technology",
January 1996

From: Peter Williams <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 validity period -Reply -Reply
Date: Thu, 10 Oct 1996 14:19:12 -0700

So post 2000, does 02 mean 2002 or 3002, or... 

I know noone is supposed to issue such things (and no
govt reistered CA would ever do such a thing, and only
govt registered CA-issued certs will be ever recognised
by law, a citizen, or the local 30th robot) but what if they do?

Will NSA latest and greatest secure messaging protocol
say the signature on the mail is good both in 2002, and 3002,
and 4002? If I issue a cert from 00-99, does that
mean its good forever?

At what point will software reject UTC, and solve the problem
which Mark indentifies - (which doesnt really exist, as any serious
risk matter will be supported by timestamping notary systems
anyway)

If there is no cutoff date, the proposal to make any change
of syntax just seems silly.

peter.

I suggested that we explicitly fix the UTCTime century ambiguity 
along the lines that Warwick recently suggested, i.e., that any time
after 1 Jan "87" and before 31 Dec "99" be unambiguously
defined to be 19xx, and everything else 20xx.  

so

Date: Thu, 10 Oct 1996 15:35:17 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: X.509 validity period -Reply -Reply -Reply

02 means 2002, now and forevermore, even in the year 10000 
(assuming the continuing use of the Christian Era as a numbering 
scheme).

So you can still use UTCTime in 10,000 AD, but only if you want 
to refer events in the very distant past. That's what I meant by being
completely unambiguous. The roll-over date applies to one century 
only. 

Bob

>>> Peter Williams <[email-masked]> 10/10/96 03:19pm >>>
So post 2000, does 02 mean 2002 or 3002, or... 

I know noone is supposed to issue such things (and no
govt reistered CA would ever do such a thing, and only
govt registered CA-issued certs will be ever recognised
by law, a citizen, or the local 30th robot) but what if they do?

Will NSA latest and greatest secure messaging protocol
say the signature on the mail is good both in 2002, and 3002,
and 4002? If I issue a cert from 00-99, does that
mean its good forever?

At what point will software reject UTC, and solve the problem
which Mark indentifies - (which doesnt really exist, as any serious
risk matter will be supported by timestamping notary systems
anyway)

If there is no cutoff date, the proposal to make any change
of syntax just seems silly.

peter.

I suggested that we explicitly fix the UTCTime century ambiguity 
along the lines that Warwick recently suggested, i.e., that any time
after 1 Jan "87" and before 31 Dec "99" be unambiguously
defined to be 19xx, and everything else 20xx.  

so

Date: Thu, 10 Oct 1996 14:15:47 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: X.509 validity period -Reply

Assuming that we determine an unambiguous roll-over year and 
merely deprecate the use of UTCTime after 2000, the certificate 
should not be rejected at all.

Bob

>>> Peter Williams <[email-masked]> 10/10/96 01:05pm >>>
Does this mean that X.500 DAP and conforming software receiving a cert in 2001 with
a UTCTime validity data should reject the cert as having a syntax error,
or a signature-invalid error? It affects the audit trails, and the handling
procedures for class of failures.

----------
From: 	Mark Bartel
Sent: 	Thursday, October 10, 1996 8:39 AM
To: 	David Boyce
Cc: 	[email-masked]
Subject: 	Re: X.509 validity period

> During encoding, the _value_ of notAfter (which is later in the 
> Validity sequence) is required for determining the _type_ of notBefore. 
>  This could be awkward in implementation, and seems unnecessary, since 
> a Validity which 'straddles' the cutoff date could equally well be 
> represented by a notBefore UTCtime and a notAfter GeneralizedTime.

I agree.  It just seemed inelegant to have one date of UTCTime and
another of GeneralizedTime.  But I don't think it's acceptable to have
the type of the notBefore date dependent upon the value of the
notAfter date (when you put it that way).  So I'd say we should remove
the restriction.  Of course, if applications *do* wish to always use
one or the other for both, this is fine too.

- Mark Bartel ([email-masked])

From: Mark Bartel <[email-masked]>
Subject: Re: X.509 validity period -Reply -Reply
To: [email-masked] (Bob Jueneman)
Date: Thu, 10 Oct 1996 16:06:11 -0400 (EDT)
Cc: [email-masked], [email-masked]

> Regarding your implementation issue, I understand the need
> to parse the certificate into a form that may be more efficient 
> for processing. But couldn't you just keep the original string, 
> with  the offset, or else store the offset in a second variable?

Isn't that what I said?  Umm, no, I said that I'd need to keep track
of what form it used.  <shrug> You are correct that it isn't difficult
to deal with.  In any case, my intention was not to explain why such a
DER encoding was *necessary*, merely why it was *specified*. :)

I think the idea is that converting between UTC time and local time is
easier than having to keep around information about what form the time
was in, and in many cases the conversion to local time might not even
be necessary.  Standards should be as simple as possible, but no
simpler. :)

- Mark Bartel ([email-masked])

> 
> "SMOP" -- Small Matter of Programming.
> 
> Bob
> 
> >>> Mark Bartel <[email-masked]> 10/10/96 12:03pm >>>
> > I would also not be in any particular rush to prohibit the use of 
> > local time (GMT plus offset). Since the DER encoding will be 
> > unambiguous in any case, the use of local time may provide 
> > some additional and useful semantics, in particular to human users, 
> > and especially in the case of relatively short-lived certificates 
> > (such as for a watch officer.)
> 
> Doesn't the DER for GeneralizedTime specify that it must be in UTC
> time (ie. end with "Z")?  See 11.7.1 of X.690.
> 
> And the reason for this is so that an implementation can parse the
> certificate into whatever representation it wants, and then later on
> verify it by reconstiting the contents (my implementation does this,
> in fact).  If UTC wasn't specified, then I would have to keep track of
> whether it read a local time form with offset or UTC time.  As it is,
> I need to keep track of whether I've read GeneralizedTime or UTCTime.
> 
> - Mark Bartel ([email-masked])
> 
> 

Date: Thu, 10 Oct 1996 13:24:30 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: X.509 validity period -Reply -Reply

I don't have X.609, so I'm not sure. I was under the perhaps
 incorrect impression that it allowed a specific offset. I'm sure 
that Bancroft Scott will straighten me out.

Regarding your implementation issue, I understand the need
to parse the certificate into a form that may be more efficient 
for processing. But couldn't you just keep the original string, 
with  the offset, or else store the offset in a second variable?

"SMOP" -- Small Matter of Programming.

Bob

>>> Mark Bartel <[email-masked]> 10/10/96 12:03pm >>>
> I would also not be in any particular rush to prohibit the use of 
> local time (GMT plus offset). Since the DER encoding will be 
> unambiguous in any case, the use of local time may provide 
> some additional and useful semantics, in particular to human users, 
> and especially in the case of relatively short-lived certificates 
> (such as for a watch officer.)

Doesn't the DER for GeneralizedTime specify that it must be in UTC
time (ie. end with "Z")?  See 11.7.1 of X.690.

And the reason for this is so that an implementation can parse the
certificate into whatever representation it wants, and then later on
verify it by reconstiting the contents (my implementation does this,
in fact).  If UTC wasn't specified, then I would have to keep track of
whether it read a local time form with offset or UTC time.  As it is,
I need to keep track of whether I've read GeneralizedTime or UTCTime.

- Mark Bartel ([email-masked])

From: Peter Williams <[email-masked]>
To: "'Mark Bartel'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 validity period
Date: Thu, 10 Oct 1996 12:05:59 -0700

Does this mean that X.500 DAP and conforming software receiving a cert in 2001 with
a UTCTime validity data should reject the cert as having a syntax error,
or a signature-invalid error? It affects the audit trails, and the handling
procedures for class of failures.

----------
From: 	Mark Bartel
Sent: 	Thursday, October 10, 1996 8:39 AM
To: 	David Boyce
Cc: 	[email-masked]
Subject: 	Re: X.509 validity period

> During encoding, the _value_ of notAfter (which is later in the 
> Validity sequence) is required for determining the _type_ of notBefore. 
>  This could be awkward in implementation, and seems unnecessary, since 
> a Validity which 'straddles' the cutoff date could equally well be 
> represented by a notBefore UTCtime and a notAfter GeneralizedTime.

I agree.  It just seemed inelegant to have one date of UTCTime and
another of GeneralizedTime.  But I don't think it's acceptable to have
the type of the notBefore date dependent upon the value of the
notAfter date (when you put it that way).  So I'd say we should remove
the restriction.  Of course, if applications *do* wish to always use
one or the other for both, this is fine too.

- Mark Bartel ([email-masked])

From: Mark Bartel <[email-masked]>
Subject: Re: X.509 validity period -Reply
To: [email-masked] (Bob Jueneman)
Date: Thu, 10 Oct 1996 14:03:19 -0400 (EDT)
Cc: [email-masked], [email-masked]

> I would also not be in any particular rush to prohibit the use of 
> local time (GMT plus offset). Since the DER encoding will be 
> unambiguous in any case, the use of local time may provide 
> some additional and useful semantics, in particular to human users, 
> and especially in the case of relatively short-lived certificates 
> (such as for a watch officer.)

Doesn't the DER for GeneralizedTime specify that it must be in UTC
time (ie. end with "Z")?  See 11.7.1 of X.690.

And the reason for this is so that an implementation can parse the
certificate into whatever representation it wants, and then later on
verify it by reconstiting the contents (my implementation does this,
in fact).  If UTC wasn't specified, then I would have to keep track of
whether it read a local time form with offset or UTC time.  As it is,
I need to keep track of whether I've read GeneralizedTime or UTCTime.

- Mark Bartel ([email-masked])

Date: Thu, 10 Oct 1996 11:45:42 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: X.509 validity period -Reply

David, I'm not sure that Mark meant to imply that the "for both" 
requirement was to be included in the ASN.1. Since the tagging 
is explicit, it should _not_ be necessary to examine notAfter in 
order to determine the type of notBefore. That would be ugly indeed.

I would also not be in any particular rush to prohibit the use of 
local time (GMT plus offset). Since the DER encoding will be 
unambiguous in any case, the use of local time may provide 
some additional and useful semantics, in particular to human users, 
and especially in the case of relatively short-lived certificates 
(such as for a watch officer.)

Bob

>>> David Boyce <[email-masked]> 10/10/96 05:20am >>>

[Note: Mark's original message was addressed to a number of 
destinations, but ietf-pkix is where I see this discussion, so have 
sent it there in the first place.  If this contribution seems sensible, 
please let me know and I'll forward it to the other destinations.  
[email-masked]]

Mark Bartel writes:

>
>My preference would be to redefine Validity:
>
>Validity ::= SEQUENCE {
>    notBefore     CertificateValidityDate,
>    notAfter      CertificateValidityDate }
>
>CertificateValidityDate ::= CHOICE {
>    utcTime       UTCTime,
>    generalTime   GeneralizedTime }
>
>Additionally, specify that UTCTime should be used for both if notAfter
>is before the year 2000, otherwise GeneralizedTime should be used (for
>both).  Also specify that generalTime must be specified in coordinated
>universal time (ie. no local time!).
>
>I think this solution has the advantage of maintaining compatibility
>for certificates in the short term without adding a lot of complexity
>in the long term.
>
>Mark Bartel ([email-masked])

I've been lurking on ietf-pkix for a while and it's about time I 
contributed.  IMHO, this is the right way to go.  

One practical point which arises from the condition represented by the 
phrase 'for both', which requires GeneralizedTime to be used for both 
notAfter _and_ notBefore whenever notAfter follows the 'cutoff' date 
(above, the year 2000, but this is yet to be agreed) is the following:

During encoding, the _value_ of notAfter (which is later in the 
Validity sequence) is required for determining the _type_ of notBefore. 
 This could be awkward in implementation, and seems unnecessary, since 
a Validity which 'straddles' the cutoff date could equally well be 
represented by a notBefore UTCtime and a notAfter GeneralizedTime.

By relaxing the "for both" condition, decoding each of these fields can 
be handled independently.  I don't think this relaxation poses greater 
problems for checking the Validity of a certificate than does the basic 
introduction of GeneralizedTime originally proposed.

Is there a good reason why the 'for both' condition should not be 
relaxed in this way?

We have the situation (notBefore, notAfter) type pairs:

	(UTCtime, UTCtime)			- both dates before 'cutoff'
	(UTCtime, GeneralizedTime)		- straddle cutoff date
	(GeneralizedTime, GeneralizedTime)	- both dates after 'cutoff'.

The fourth case, (GeneralizedTime, UTCtime) can be deprecated.

We may define a date which is exactly on the cutoff date to be 
GeneralizedTime.  I support the proposal that we should use only the Z 
(without offset) form of GeneralizedTime throughout.

David Boyce
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	IC's WWW: http://www.isode.com/
X.400:	i=D;s=Boyce;o=ISODE Consortium;p=ISODE;a=MAILNET;c=FI;

Date: Thu, 10 Oct 1996 11:38:09 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: X.509 validity period -Reply

To address one of Peter William's concern's, I would suggest that 
we not include the CHOICE option in version 1 or version 2 
certificates. Those horses are already out of the barn, and 
implementations will either deal with the year 2000 problem or the 
implementors will (deservedly) go out of business. The same is 
true for any v3 certificates which have been issued or 
will be issued using UTCTime and a notAfter date of post 2000.

I would recommend that we do the following:

1.  Clearly define the wraparound year in the standard, both X.509
and the pkix document, so that if UTCTime is used it will be completely
unambiguous as to which century is meant. We certainly don't want to 
have this problem occur again. 1 January 87 is 1987, while 
31 December 86 is 2086. 

2. Issue a defect report and a Technical Corrigendum to X.509 v3, 
adding the CHOICE option for generalizedTime.

3. Deprecate the use of (but not the support for) UTCTime for 
certificates with notAfter dates that are post 2K. (2000, not 2048! :-)

4. Strongly deprecate the use of (but not the support for) 
generalizedTime in certificates with notAfter dates of post 2K and
notBefore dates prior to 1 January 1998. This will give 
implementors at least a year to fix the problem. At the rate that new 
features are coming out, I don't believe that this would be a problem.

(If the vast preponderance of certificates being issued have one year 
validity periods, we could relax that constraint to 1 Jan 1999, giving
implementors a very generous two years. And of course even 
though the use of UTCTime will be deprecated, it won't be forbidden, 
so it would still be OK for longer-lived certificates, so long as the 
century rule is made completely unambiguous.)

Bob

>>> Warwick Ford <[email-masked]> 10/09/96 09:47pm >>>
It's kinda neat how the substitution of the CHOICE becomes gracefully
possible, due to the use of EXPLICIT tagging.  This would not be possible
with contemporary ASN.1 protocols that use IMPLICIT or AUTOMATIC tagging.
So, let's take advantage of this situation.

Nevertheless, my main point has been to choose the right wraparound rule,
and we can do that with CHOICE as well as we could with a new extension.
For the UTCTime option of the CHOICE, we can say that values 00-87 mean 20xx
and values 88-99 mean 19xx.  This still achieves my main goal which is that
implementors really have to do nothing for a looooong time. 

Warwick
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Thu, 10 Oct 1996 10:51:09 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: CRLs indefintely? -Reply

Tal,

One other point which Steve might have made is that because 
CRLs are not guaranteed to be issued and disseminated instantaneously,
it is necessary to wait until the next release of a CRL from the 
CA, which will conclusively show that the certificate was still valid 
at that later time. These is an even worse problem if a certificate is 
revoked 1 microsecond before the certificate was due to expire. 
(As I recall we fixed that by requiring the CA to publish at least one CRL
containing that certificate's serial, even though it had expired, but I 
don't remember the details. Maybe someone will correct me if I'm 
wrong on this point.)

The need to avoid these kinds of race conditions is awkward, but
a consequence of our fundamental decision not to impose an on-line
validation model. Of course, for certain applications like stock
transaction, imposing effectively a two-week recision period while 
waiting for the CA  to post its next regularly scheduled CRL would
be intolerable, and in that case it will be necessary to ask the CA to 
explicitly confirm the validity of the certificate in real time. It can do that
conclusively by signing both a statement to that effect _together with_ 
the digital signature of the document in question, although it is still 
necessary to validate the CA's own certificate.

Bob

Robert R. Jueneman
Security Architect
NetWare Security R&D
Internet Infrastructure Division
Novell, Inc. M/S-PRV-D241
122 East 1700 South
Provo, UT 84606
801/861-7387

>>> Stephen Kent <[email-masked]> 10/09/96 03:53pm >>>
Tal,

        The model usually advocated for use of CRLs in support of
non-repudiation calls for retaining the relevant CRL as a part of the
"evidence."  Thus Bob needs to be able to show that the document in
question was signed at a point in time when Alice's key was not reported as
compromised.  This attestation of the time at which the contract was signed
must be provided by a third party, not by Bob or Alice.   The relevant CRL
is the one that covers the time interval at which the contract was signed.
So, the fact that Alice's cert serial number is removed from the CRL when
her certificate is no longer valid anyway, should not be a problem.  The
fundamental model is that a party who wants to prevent repudiation is the
party responsible for collecting the necessary "receipts" e.g.,
certificates and CRLs and timestamps.

Steve

From: "Anil R. Gangolli" <[email-masked]>
Date: Thu, 10 Oct 1996 09:47:04 -0700
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: X.509 validity period
Cc: David Boyce <[email-masked]>

 > One practical point which arises from the condition represented by the
 > phrase 'for both', which requires GeneralizedTime to be used for both
 > notAfter _and_ notBefore whenever notAfter follows the 'cutoff' date
 > (above, the year 2000, but this is yet to be agreed) is the following:
 >
 > During encoding, the _value_ of notAfter (which is later in the
 > Validity sequence) is required for determining the _type_ of notBefore.
 >  This could be awkward in implementation, and seems unnecessary, since
 > a Validity which 'straddles' the cutoff date could equally well be
 > represented by a notBefore UTCtime and a notAfter GeneralizedTime.
 >
 > By relaxing the "for both" condition, decoding each of these fields can
 > be handled independently.  I don't think this relaxation poses greater
 > problems for checking the Validity of a certificate than does the basic
 > introduction of GeneralizedTime originally proposed.
 >
 > Is there a good reason why the 'for both' condition should not be
 > relaxed in this way?
 >
 > We have the situation (notBefore, notAfter) type pairs:
 >
 > 	(UTCtime, UTCtime)			- both dates before 'cutoff'
 > 	(UTCtime, GeneralizedTime)		- straddle cutoff date
 > 	(GeneralizedTime, GeneralizedTime)	- both dates after 'cutoff'.
 >
 > The fourth case, (GeneralizedTime, UTCtime) can be deprecated.
 >
 > We may define a date which is exactly on the cutoff date to be
 > GeneralizedTime.  I support the proposal that we should use only the Z
 > (without offset) form of GeneralizedTime throughout.
 >
 > David Boyce
 > --
 > David Boyce
 >
 > Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
 > I'net:	[email-masked]	IC's WWW: http://www.isode.com/
 > X.400:	i=D;s=Boyce;o=ISODE Consortium;p=ISODE;a=MAILNET;c=FI;
 >

I agree with the above that we should allow the values to be
encoded independently, but I would like to clarify some points
that I feel are being confused.

If we go with the CHOICE of GeneralizedTime and UTCTime proposal,
Some things we need to agree on are:

- a rollover year R for interpretation of UTCTime.

- a cutoff date C < R when all compliant implementations would accept the
  CHOICE of UTCTime and GeneralizedTime.

- dates after the rollover year R, not the cutoff date C, must
  be encoded in GeneralizedTime.

- The choice of which choice to take for years between 2000 and
  the rollover year R does not depend on the value to be encoded.
  Rather it depends on the time of encoding with respect to the cutoff year C.
  For interoperability/compatiblity any early adopters should not
  choose GeneralizedTime until after year C, regardless of the value
  being encoded.   This probably needs to be part of the standard.

--a.

To: Warwick Ford <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: X.509 validity period 
Date: Thu, 10 Oct 1996 11:52:57 -0400
From: "Charles W. Gardiner" <[email-masked]>

    I'm a little puzzled about the statement that IMPLICIT tagging of a CHOICE
in the validity dates would produce different encoding from EXPLICIT tagging.
As I read the specs (I don't recall the chapter & verse), a CHOICE must always
encode the tag of the chosen member.  Since the two alternatives are both
universals, there is no differnece between IMPLICIT and EXPLICIT.  Were they 
tagged with, say, context-specific tags, then there would be trouble.

    Is this right?

Charlie Gardiner

From: Mark Bartel <[email-masked]>
Subject: Re: X.509 validity period
To: [email-masked] (David Boyce)
Date: Thu, 10 Oct 1996 11:39:59 -0400 (EDT)
Cc: [email-masked]

> During encoding, the _value_ of notAfter (which is later in the 
> Validity sequence) is required for determining the _type_ of notBefore. 
>  This could be awkward in implementation, and seems unnecessary, since 
> a Validity which 'straddles' the cutoff date could equally well be 
> represented by a notBefore UTCtime and a notAfter GeneralizedTime.

I agree.  It just seemed inelegant to have one date of UTCTime and
another of GeneralizedTime.  But I don't think it's acceptable to have
the type of the notBefore date dependent upon the value of the
notAfter date (when you put it that way).  So I'd say we should remove
the restriction.  Of course, if applications *do* wish to always use
one or the other for both, this is fine too.

- Mark Bartel ([email-masked])

From: Mark Bartel <[email-masked]>
Subject: Re: X.509 validity period
To: [email-masked] (Warwick Ford)
Date: Thu, 10 Oct 1996 10:34:11 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

> Nevertheless, my main point has been to choose the right wraparound rule,
> and we can do that with CHOICE as well as we could with a new extension.
> For the UTCTime option of the CHOICE, we can say that values 00-87 mean 20xx
> and values 88-99 mean 19xx.  This still achieves my main goal which is that
> implementors really have to do nothing for a looooong time. 

I like this.  I'd really like it if we could assume that UTCTime meant
19xx, no testing required whatsoever, but if there will be a lot of
certs out there with post-2K dates by the time people can change it,
it is the best solution.  The only major systems I know of are MS and
Netscape, and they would be able to change; but I have no idea of what
else is out there.

Btw, I realized that I was not quite accurate in saying the Entrust
was closed... since the toolkit can generate PEM headers presumably a
PEM mailreader could verify an Entrust signature.  I was thinking of
the fact that you can't currently import certificates (although I
understand that's going to change in the next version).  So those
Entrust/Lite certificates with 10 years validity periods could
theoretically be seen by other applications, although I don't know if
it is ever used this way.

- Mark Bartel ([email-masked])

From: Nick Pope <[email-masked]>
To: Warwick Ford <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 10 Oct 1996 14:15:49 +0000
Subject: RE: X.509 validity period
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Priority: normal

In reply to your message of  9 Oct 96, 20:47 from Warwick:

Your suggestion would be OK if some implementos did not feel it 
necessary to use Generalised time before 2087 to remove 100% any ambiguity.  
I have a feeling that if the capability is there to use Generalised 
time that some communities would want to use it which could lead to 
divergence of implementations.

I would be happy if post 2000 any certificates received with UTCTime 
could be interpreted as you suggest.  However, post 2000 it should be 
possible for a Generalised time certificate to be generated and 
understood by others.

Nick

P.S.

Did you see my response  Re: X.509 Bug Regarding Policy Constraints?  
Is my suggested resolution acceptable?

> It's kinda neat how the substitution of the CHOICE becomes gracefully
> possible, due to the use of EXPLICIT tagging.  This would not be
> possible with contemporary ASN.1 protocols that use IMPLICIT or
> AUTOMATIC tagging. So, let's take advantage of this situation.
> 
> Nevertheless, my main point has been to choose the right wraparound
> rule, and we can do that with CHOICE as well as we could with a new
> extension. For the UTCTime option of the CHOICE, we can say that
> values 00-87 mean 20xx and values 88-99 mean 19xx.  This still
> achieves my main goal which is that implementors really have to do
> nothing for a looooong time. 
> 
> Warwick
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

To: Mark Bartel <[email-masked]>
cc: [email-masked]
Subject: Re: X.509 validity period
Date: Thu, 10 Oct 1996 12:20:26 +0100
From: David Boyce <[email-masked]>

[Note: Mark's original message was addressed to a number of 
destinations, but ietf-pkix is where I see this discussion, so have 
sent it there in the first place.  If this contribution seems sensible, 
please let me know and I'll forward it to the other destinations.  
[email-masked]]

Mark Bartel writes:

>
>My preference would be to redefine Validity:
>
>Validity ::= SEQUENCE {
>    notBefore     CertificateValidityDate,
>    notAfter      CertificateValidityDate }
>
>CertificateValidityDate ::= CHOICE {
>    utcTime       UTCTime,
>    generalTime   GeneralizedTime }
>
>Additionally, specify that UTCTime should be used for both if notAfter
>is before the year 2000, otherwise GeneralizedTime should be used (for
>both).  Also specify that generalTime must be specified in coordinated
>universal time (ie. no local time!).
>
>I think this solution has the advantage of maintaining compatibility
>for certificates in the short term without adding a lot of complexity
>in the long term.
>
>Mark Bartel ([email-masked])

I've been lurking on ietf-pkix for a while and it's about time I 
contributed.  IMHO, this is the right way to go.  

One practical point which arises from the condition represented by the 
phrase 'for both', which requires GeneralizedTime to be used for both 
notAfter _and_ notBefore whenever notAfter follows the 'cutoff' date 
(above, the year 2000, but this is yet to be agreed) is the following:

During encoding, the _value_ of notAfter (which is later in the 
Validity sequence) is required for determining the _type_ of notBefore. 
 This could be awkward in implementation, and seems unnecessary, since 
a Validity which 'straddles' the cutoff date could equally well be 
represented by a notBefore UTCtime and a notAfter GeneralizedTime.

By relaxing the "for both" condition, decoding each of these fields can 
be handled independently.  I don't think this relaxation poses greater 
problems for checking the Validity of a certificate than does the basic 
introduction of GeneralizedTime originally proposed.

Is there a good reason why the 'for both' condition should not be 
relaxed in this way?

We have the situation (notBefore, notAfter) type pairs:

	(UTCtime, UTCtime)			- both dates before 'cutoff'
	(UTCtime, GeneralizedTime)		- straddle cutoff date
	(GeneralizedTime, GeneralizedTime)	- both dates after 'cutoff'.

The fourth case, (GeneralizedTime, UTCtime) can be deprecated.

We may define a date which is exactly on the cutoff date to be 
GeneralizedTime.  I support the proposal that we should use only the Z 
(without offset) form of GeneralizedTime throughout.

David Boyce
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	IC's WWW: http://www.isode.com/
X.400:	i=D;s=Boyce;o=ISODE Consortium;p=ISODE;a=MAILNET;c=FI;

Date: Wed, 09 Oct 1996 20:47:59 -0700
To: Nick Pope <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: RE: X.509 validity period
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

It's kinda neat how the substitution of the CHOICE becomes gracefully
possible, due to the use of EXPLICIT tagging.  This would not be possible
with contemporary ASN.1 protocols that use IMPLICIT or AUTOMATIC tagging.
So, let's take advantage of this situation.

Nevertheless, my main point has been to choose the right wraparound rule,
and we can do that with CHOICE as well as we could with a new extension.
For the UTCTime option of the CHOICE, we can say that values 00-87 mean 20xx
and values 88-99 mean 19xx.  This still achieves my main goal which is that
implementors really have to do nothing for a looooong time. 

Warwick
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Wed, 9 Oct 1996 17:53:59 -0400
To: Tal Rabin <[email-masked]>
From: [email-masked] (Stephen Kent)
Subject: Re: CRLs indefintely?
Cc: [email-masked]

Tal,

        The model usually advocated for use of CRLs in support of
non-repudiation calls for retaining the relevant CRL as a part of the
"evidence."  Thus Bob needs to be able to show that the document in
question was signed at a point in time when Alice's key was not reported as
compromised.  This attestation of the time at which the contract was signed
must be provided by a third party, not by Bob or Alice.   The relevant CRL
is the one that covers the time interval at which the contract was signed.
So, the fact that Alice's cert serial number is removed from the CRL when
her certificate is no longer valid anyway, should not be a problem.  The
fundamental model is that a party who wants to prevent repudiation is the
party responsible for collecting the necessary "receipts" e.g.,
certificates and CRLs and timestamps.

Steve

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Tal Rabin'" <[email-masked]>
Subject: RE: CRLs indefintely?
Date: Wed, 9 Oct 1996 14:19:28 -0700

The KeyUsage/Purposes field distinguishes between uses of a
signing key in "signature" security services, and uses of a signing key
in a "non-repudiation" grade security service. The bit flag to
guide usage of a signing key for _Cert issuing_ (And CRL issuing)
is distinct, once again, semantically, and in value..

How does this affect your argument, if at all?

I dont disagree, by the way with the proposal. You seem to be saying such a persistent
CRL is "the mother of all notary" systems. Lawyers will hate you! A perhaps
simpler way is to have what the law already recognises - have the digital signature
confirmed (and recorded) by a notary at a given moment
in time. Such a notary might use Surety technology, possibly, in an
online notarising service, to avoid syncronised reliance on trusted clocks in
general.

USPS has just such a notary/timestamping service in pilot....

Peter.

What follows is a little tounge in cheek, for fun.

All this comes down to the mere fact that there are
divergent opinion on the nature of the validity field which
X.509 does not standardize, yet ABA does when
applied to digital signatures  (as applied to
certs signature themeselves, on digitally-signed messages, 
and anywhere else a signing key is used, infact).

Those that are new wish the field to have some (or other...)
meaning with respect to the object being signed.
The majority of the people in this camp seem to be software
types. The folk who directly gain economicially are the software/telco
industry as online authorization and revocation checking of the cert
becomes necessary. The benefactors are corporate users.
(Sell trustworthy systems!)

Those that are older in the area argue for the field to limit
the lifetime of a cert when parties may rely upon the cert
for any purpose, unless notarised. The majority of the people
in this camp are lawyers. The folk who directly gain economicially
are lawyers.The benefactors are all persons, everywhere.
(Sell trusted services!)

----------
From: 	Tal Rabin
Sent: 	Wednesday, October 09, 1996 8:33 AM
To: 	[email-masked]
Subject: 	CRLs indefintely?

There might be a need to maintain some form of revocation lists indefinitely.
This is due to the validity of the key in the certificate as a "signature key".

Problem: 
*  Alice gets a cert from a CA  with dates notBefore 1.1.96 and notAfter 1.1.98.  
*  On 1.1.97 she learns that her key has been compromised by Bob,
   and asks the CA to add her cert to the CRL.  
*  Bob signs some contract using Alice's key on 1.1.97 and gets a time stamp for 1.1.97 
*  When the original time on Alice's cert expires (1.1.98) her cert is removed from 
   the CRL.
*  Now Bob has a valid signature and a valid cert indicating that the key
   *was* valid on 1.1.97.

A simply fix to this problem would be to maintain the CRL's indefinitely,
though this has its ramifications.  
The second option which would solve the problem only partially would be
to maintain a distributed CRL indefinitely.  That is that the CA would issue
Alice (for example) an "anti"-cert for her certificate, which would indicate 
that she had broken the binding on a certain date. (Note that these cannot be 
issued retroactively to avoid the problem of Alice denying her own signatures.)
This would solve the problem when Bob confronts Alice directly, then she can show 
her "anti"-cert, yet it will not solve the problem of Bob showing the signature
to a third party.

I am new to the mailing list, and must admit that I haven't read all
the archive, so if this problem has been previously addressed, pls
give me the ref to where I may read the discussion.

Tal Rabin (IBM)

Date: Wed, 9 Oct 1996 11:33:14 -0400
From: Tal Rabin <[email-masked]>
To: [email-masked]
Subject: CRLs indefintely?

There might be a need to maintain some form of revocation lists indefinitely.
This is due to the validity of the key in the certificate as a "signature key".

Problem: 
*  Alice gets a cert from a CA  with dates notBefore 1.1.96 and notAfter 1.1.98.  
*  On 1.1.97 she learns that her key has been compromised by Bob,
   and asks the CA to add her cert to the CRL.  
*  Bob signs some contract using Alice's key on 1.1.97 and gets a time stamp for 1.1.97 
*  When the original time on Alice's cert expires (1.1.98) her cert is removed from 
   the CRL.
*  Now Bob has a valid signature and a valid cert indicating that the key
   *was* valid on 1.1.97.

A simply fix to this problem would be to maintain the CRL's indefinitely,
though this has its ramifications.  
The second option which would solve the problem only partially would be
to maintain a distributed CRL indefinitely.  That is that the CA would issue
Alice (for example) an "anti"-cert for her certificate, which would indicate 
that she had broken the binding on a certain date. (Note that these cannot be 
issued retroactively to avoid the problem of Alice denying her own signatures.)
This would solve the problem when Bob confronts Alice directly, then she can show 
her "anti"-cert, yet it will not solve the problem of Bob showing the signature
to a third party.

I am new to the mailing list, and must admit that I haven't read all
the archive, so if this problem has been previously addressed, pls
give me the ref to where I may read the discussion.

Tal Rabin (IBM)

From: Mark Bartel <[email-masked]>
Subject: Re: X.509 validity period
To: [email-masked] (Peter Rostin)
Date: Wed, 9 Oct 1996 10:08:13 -0400 (EDT)
Cc: [email-masked]

> Maybe I'm missing something (due to not fully understanding all the issues),
> but even if it is clear that the CHOICE solution would make it possible to
> use certificates with pre-2K After and Before dates with current
> implementations it will still get us problems already today as certificates
> already made could have NotAfter dates which are post 2K (We are at least in
> this situation, with customers already using certificates with notAfter
> dates which are post 2K (which are obviously not made with the COICHE
> type)).
> 
> >Almost all current certificates won't have a post-2K notAfter, and so don't 
> >need to change.
> 
> Even if that was the case, your change would mean that software out there
> today would not be able to handle certificates made next year and so on.
> Warwicks suggestion gives us at least 50 years to implement the change.

Peter, I already responded to this by email, but I'd meant to respond
to the list.  So I'll give my thoughts on both this and your answer
here.

I believe that Netscape and MS certificates currently just have a one
year validity.  It seemed to me that this would be the major installed
base, and since both companies release at least once a year, having
the change before Y2K won't be a problem.

In most other cases, I think the certificates are still used in a
application-specific fashion.  The certificates may conform to a
standard, but don't are never actually parsed by any software besides
the vendor's.  And so current hacks can be used *in those specific
applications*... without requiring everybody to worry about testing
the year in perpetuity.  Individual apps can use certs requiring the >
8x test and still interoperate with certs that use the CHOICE option,
just as long as the certs that require > 8x aren't seen by other apps.

Entrust (currently) is an example here... the system is closed.

It seems to me that SSL is the major place that X.509 is used in a way
that requires interoperability.  I hope your product isn't an SLL
one...

And so Hoyt's solution (that I re-proposed) doesn't break as much as
might appear.

Of course, my understanding just comes from my view of my little
corner of the universe...

- Mark Bartel ([email-masked])

From: Nick Pope <[email-masked]>
To: "Miklos Sue A." <[email-masked]>, Mark Bartel <[email-masked]>, "'Nick Pope'" <[email-masked]>, Peter Williams <[email-masked]>
Date: Wed, 9 Oct 1996 11:09:01 +0000
Subject: RE: X.509 validity period
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Priority: normal

In reply to your message of  8 Oct 96, 10:09:

> Does a choice have automatic explicit tags?
> 

Me reading of ASN.1 is that:

The CHOICE with UTCTime and Generalised time will result in encoding
ip to 31 dec 1999:

[UNIVERSAL 23]followed by yymmddhhmm(ss)Z
(or a local time -/+ hhmm)

which is exactly as for the current certificate, and after 2000 the 
endoding for Generalised Time which is:

[UNIVERSAL 24] followed by yyyymmmddhhmm(ss.s)Z
(or a local time -/+ hhmm or a local time)

The use of the local time variant of generalised time could be a 
problem thus I suggest that this be not allowed in the X.509 
certificate.

Nick

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Nick Pope <[email-masked]>
To: Nick Pope <[email-masked]>, Stephen Kent <[email-masked]>
Date: Wed, 9 Oct 1996 10:58:37 +0000
Subject: Re: X.509 validity period
CC: "Miklos Sue A." <[email-masked]>, Mark Bartel <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Priority: normal

In reply to your message of  8 Oct 96, 20:05: from steve kent

> Nick,
> 
>         I agree with your support for Warwick's suggestion. 

I presume that you mean the Mark / Hoyt suggestion which was a counter 
to Warwicks suggestion.

> While it
>         is
> not the most elegant approach to dealing with the problem, it is
> backward compatible and it gives implementors time to deal with the
> problem.
> 
> Steve
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Nick Pope <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Mark Bartel'" <[email-masked]>, Peter Williams <[email-masked]>
Date: Wed, 9 Oct 1996 11:14:41 +0000
Subject: RE: X.509 validity period
Priority: normal

In reply to your message of  8 Oct 96, 15:15:

> 
> Mark,
> 
>......

> As I said last memo to fully specify the change now made, we now need
> to change X.500 Bind  syntax declaration, and text, so that the strong
> authentication will work with the change in time synchronization model
> for cert reliance and  general handling of clock syncronization. Im
> understanding the move to GeneralizedTime to be one in which not only
> is there a 4 digit year, but the parties are not bound to any a priori
> rules of clock synchronization.

Generalised Time allows for either local time or "Coordinated unversal 
time" (with 4 digit year) ot local time -/+ adjustment for coordinated 
time.  All that I believe is necessary is to place 
a restriction on the use of Generalised time to allow only coordinated 
time (and possibly local +/- adjustment - although I see no need to use 
this variant.)

Nick

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

Date: Wed, 9 Oct 96 10:47:54 +0200
From: [email-masked] (Peter Rostin)
To: [email-masked]
Subject: Re: X.509 validity period
Newsgroups: local.ietf-pkix-list

In local.ietf-pkix-list Mark Bartel <[email-masked]> write:
>Arrgghh!  I realize I was ambiguous.  The certs generated with the CHOICE 
>scheme will look exactly the same as old certificates, as long as the 
>notAfter date is pre-2K.  Is that more clear?  So current software will 
>work *fine* with them.  Only post-2K certificates will cause problems.  The 
>type tags on UTCTime and GeneralizedTime provide distinctness; no 
>additional tag (or implicit tag) is necessary.

Maybe I'm missing something (due to not fully understanding all the issues),
but even if it is clear that the CHOICE solution would make it possible to
use certificates with pre-2K After and Before dates with current
implementations it will still get us problems already today as certificates
already made could have NotAfter dates which are post 2K (We are at least in
this situation, with customers already using certificates with notAfter
dates which are post 2K (which are obviously not made with the COICHE
type)).

>Almost all current certificates won't have a post-2K notAfter, and so don't 
>need to change.

Even if that was the case, your change would mean that software out there
today would not be able to handle certificates made next year and so on.
Warwicks suggestion gives us at least 50 years to implement the change.
-- 
 Peter Rostin                            Email: [email-masked]
 DynaSoft AB                             Phone: +46-8-725 09 00
 Address: Arenav 29, Box 10704           Fax: +46-8-649 49 70
 Address: S-121 29 STOCKHOLM, SWEDEN

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Subject: Re: X.509 validity period
Date: Wed, 9 Oct 1996 00:57:50 -0400
Encoding: 31 TEXT

>The checking of timestamps as mentioned in the following clauses only 
applies
>when either synchronized clocks are used in a local environment, or
>if clocks are logically synchronized by bilateral agreements. In any case, 
it is
>eecommended that Coordinated Universal Time be used":

<chuckle>  I almost quoted this in my previous message, because it was the 
only reference to time sources I could find!  But since these rules apply 
for the one-, two-, and three-way authentication protocols, not to the 
X.509 certificate dates, I didn't see the relevance to the validity 
argument.  The timestamps referred to are the timestamps in the exchanged 
authentication messages, not the validity dates on the certificates.

In any case, from the overview for that clause (10.1):

"In general it is the business of a specific application to determine the 
appropriate procedures, so as to meet the security policy of the 
application.  This clause describes three particular authentication 
procedures, which may be found useful across a range of applications."

In other words, that section is only a suggestion of how you might use 
X.509.

See Brian Korver's message for a response to your concerns about the CHOICE 
idea.  Basically, the encoding for a CHOICE type is just the encoding for 
the underlying type, with the restriction that the tags for the types in 
the CHOICE must be distinct.  Since the tags for GeneralizedTime and 
UTCTime are distinct, no problem.

- Mark Bartel ([email-masked])

From: Brian Korver <[email-masked]>
Subject: Re: X.509 validity period
To: [email-masked] (Peter Williams)
Date: Tue, 8 Oct 1996 19:33:46 -0700 (PDT)
Cc: [email-masked], [email-masked]
Content-Length: 2200

Comments below....

Peter Williams writes:
> 
> Mark,
> 
> Im worry Mark, Im just not good enough at this ASN.1
> stuff. You say:
> 
> Validity ::= SEQUENCE {
>     notBefore     CertificateValidityDate,
>     notAfter      CertificateValidityDate }
> 
> CertificateValidityDate ::= CHOICE {
>     utcTime       UTCTime,
>     generalTime   GeneralizedTime }
> 
> 
> If a X.509 v1 decoder (which is already deployed in 15 million copies of
> navigator) sees a cert valdiity field of this form, with an explicit tag
> introduced by virtue of the choice, it will fail to decode no?

No.

> It will fail even if the UTCTime option is that chosen
> by the CA, no?

No.

> Are not all choice elements distinguished by an intermediate tag?

Nope, at least not with DER or BER.  A cert that uses
CertificateValidityDate.UTCTime will be identical (at least in this regard)
to a cert using bare UTCTime.  Since signature validation requires DER,
this substition should work.

Actually, you were onto something above.  If notBefore (or notAfter) were
IMPLICIT-ly tagged, then substituting 'notBefore  CHOICE{...}' for 
'notBefore  UTCTime' wouldn't work.  Luckily, notBefore and notAfter aren't
so tagged.

> I suspect what you are trying to assert is this:
> 
> Validity := SEQUENCE {
> 		notBefore ANY,
> 		notAfter ANY
> 	}
> 
> with the proviso that ANY is constrained to be UTCTime for
> issuing/expiry date prior to 2000, and is constained to be
> GeneralizedTime post 2000. Noone is ever allowed to issue
> a cert which straddles a century! Is this the complete statement
> of the problem, requirement and proposed solution?
> 
> (All this to solve a problem which does not even exist! Two
> digit year credit card straddle the century, but certs can't!
> 
> I still say its easier to stuff in a non-critical extension and leave
> the existing X.509 stuff alone. The extension adds everything ones
> needs, and allows for greater expression freedom in time
> issues anyway. One makes it critical in all certs
> issued post-2000. 4 years is time for people to migrate
> their (customer's) software if they used static linking of cert
> coders to handle the criticality)

brian
[email-masked]

Date: Tue, 8 Oct 1996 20:06:34 -0500
To: [email-masked]
From: [email-masked] (Stephen Kent)
Subject: agenda for San jose

Folks,

        We have two time slots in San Jose: Monday and Tuesday, both
starring at 1PM.  I have four agenda item requests so far:

        - a status update on the Part 1 I-D (which we shoud be moving
forward to last call RSN!)
        - a presentation on Part 3, describing changes made in response to
comments, document status and plans for progress
        - a presentation on a new area, Part 4, dealing with one view of
certificate policies
        - a presentation on an API for certificate and CRL management

Since the last two presentations are on new topics and will take fair
amounts of time, I expect we have a fairly full schedule, but there is
certainly room for a few more topics if needed.  Please send e-mail to
Warwick and me to request an agenda time slot.

Steve

Date: Tue, 8 Oct 1996 20:05:44 -0500
To: Nick Pope <[email-masked]>
From: [email-masked] (Stephen Kent)
Subject: Re: X.509 validity period
Cc: "Miklos Sue A." <[email-masked]>, Mark Bartel <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Nick,

        I agree with your support for Warwick's suggestion.  While it is
not the most elegant approach to dealing with the problem, it is backward
compatible and it gives implementors time to deal with the problem.

Steve

From: Peter Williams <[email-masked]>
To: "'Mark Bartel'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: X.509 validity period
Date: Tue, 8 Oct 1996 16:21:53 -0700

Mark,

Im worry Mark, Im just not good enough at this ASN.1
stuff. You say:

Validity ::= SEQUENCE {
    notBefore     CertificateValidityDate,
    notAfter      CertificateValidityDate }

CertificateValidityDate ::= CHOICE {
    utcTime       UTCTime,
    generalTime   GeneralizedTime }

If a X.509 v1 decoder (which is already deployed in 15 million copies of
navigator) sees a cert valdiity field of this form, with an explicit tag
introduced by virtue of the choice, it will fail to decode no?

It will fail even if the UTCTime option is that chosen
by the CA, no?

Are not all choice elements distinguished by an intermediate tag?

I suspect what you are trying to assert is this:

Validity := SEQUENCE {
		notBefore ANY,
		notAfter ANY
	}

with the proviso that ANY is constrained to be UTCTime for
issuing/expiry date prior to 2000, and is constained to be
GeneralizedTime post 2000. Noone is ever allowed to issue
a cert which straddles a century! Is this the complete statement
of the problem, requirement and proposed solution?

(All this to solve a problem which does not even exist! Two
digit year credit card straddle the century, but certs can't!

I still say its easier to stuff in a non-critical extension and leave
the existing X.509 stuff alone. The extension adds everything ones
needs, and allows for greater expression freedom in time
issues anyway. One makes it critical in all certs
issued post-2000. 4 years is time for people to migrate
their (customer's) software if they used static linking of cert
coders to handle the criticality)

	

Peter.

----------
From: 	Mark Bartel
Sent: 	Tuesday, October 08, 1996 1:50 PM
To: 	'Miklos Sue A.'; 'Mark Bartel'; 'Peter Williams'
Cc: 	[email-masked]'; [email-masked]'; [email-masked]'
Subject: 	Re: X.509 validity period

>The Hoyt "choice proposal" is clearly now a given. The cert generated 
using
>this scheme will not be accepted by X.509 v1 systems such
>as 15 million navigator clients, and ~4 million IE clients. The explicit
>context tag added to the front of the time primitive (or the type
>checking on the UTCTime primitive)  will break the X.509 decoders.

Arrgghh!  I realize I was ambiguous.  The certs generated with the CHOICE 
scheme will look exactly the same as old certificates, as long as the 
notAfter date is pre-2K.  Is that more clear?  So current software will 
work *fine* with them.  Only post-2K certificates will cause problems.  The 
type tags on UTCTime and GeneralizedTime provide distinctness; no 
additional tag (or implicit tag) is necessary.

Almost all current certificates won't have a post-2K notAfter, and so don't 
need to change.

Sorry for the confusion...

- Mark Bartel ([email-masked])

>Its tough on those users of older software (i.e. software massively 
distirbuted
>2 months ago). For Microsoft, they should be able to issue
>a new DLL for the X.509 v1+ module over the web given
>the way they architected the solution. Entrust should
>be able to replace the v1-based systems for its numerous
>corporate organizational CAs pretty fast also to conform
>to the registered defect report/resolution (when it passes ISO).
>
>Should I  start work on preparing the secure server community to
>request a renewal of the SSL server certs to change the encoding (and find
>a message of why this is now needed). Its going
>to be nasty with a mix of old format and new format
>browsers out there  - on the server operations folk. Some
>enterprising company can perhaps sell them some tools ...
>on how to migrate standards.
>
>At what point do you believe VeriSign should reissue its
>250,000 client certs (Currently conformant to the ratified X.509 v2
>edition and the additional TC1 defect report)?
>
>Peter.
>
>
>----------
>From: 	Mark Bartel
>Sent: 	Tuesday, October 08, 1996 12:02 PM
>To: 	'Miklos Sue A.'; 'Mark Bartel'; 'Nick Pope'; 'Peter Williams'
>Cc: 	[email-masked]'; [email-masked]'; 
[email-masked]'
>Subject: 	Re: X.509 validity period
>
>>Does a choice have automatic explicit tags?
>>
>>Could a pre-Mark cert be decoded by a post-Mark cert bit decoder?
>
>The tags must be distinct, but since UTCTime and GeneralizedTime have
>different tags already, this is ok.
>
>In other words, software that parses certificates according to the old
>definition won't recognize the difference unless notAfter is post-2K.
>
>And as an aside, I understand that Hoyt came up with the CHOICE option
>first; I came in after that and hadn't seen Hoyt's post.  "Mark cert" is a 
>misnomer. :)
>
>>I think we have just said there will be two cert formats. You will
>>find out which one you are using by looking for the presence
>>of a context tag value in one or other of the the validity fields.
>>
>>Warwick suggestion adds no more complexity than
>>does any use of a v3 extension. It is certainly less
>>complex that looking for tags to switch which
>>std format one is using.
>
>I disagree.  With the CHOICE option you merely need to check tags.  With
>the extension option, you have to (a) have extensions, (b) parse the
>extensions, (c) determine whether one of them is the century extension, 
and
>(d) add that information onto the dates if it is there.  Think about
>hardware; extensions complicate it enough (with having to check for
>criticality etc.) without having to parse yet another extension.
>
>>Dont forget (as if one would) to do the same to X.509 CRLs.
>
>Yes.  All dates in CRLs should really be changed similarly.  This is not
>nearly so bad as the certificate problem, though, because CRLs are 
supposed
>to be updated frequently (so the old versions shouldn't persist like old
>certificates).  I propose that the same change be made there.
>
>- Mark Bartel ([email-masked])
>
>
>

From: Peter Williams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Mark Bartel'" <[email-masked]>
Subject: RE: X.509 validity period
Date: Tue, 8 Oct 1996 15:15:17 -0700

Mark,

Im just an programmer; so please do correct me; I just do
what I understand the standards to say; I dont write them! Its
a very rare occurance that we have access to the people
who actually write this ISO stuff!

I come from having used (valid) certs first in
a X.500 strong authentication environment where there was
peer-entity authentication binding protocol used in a networking
(vs messaging) enviornment, which conforms to X.509's std strong
authenication procedures. In a two party protocol is using time
fields, there is an assumption (and if I remember back 6 years) a
statement, that clocks should be synchronised for the authentication
semantics embedded in the protocol (and standardised tokens) 
to work. Where one uses 3-msg authentication (as per SSL) this
requirement can be relaxed, and one can rely on mere nonce
knowledge.

As I said last memo to fully specify the change now made, we now need
to change X.500 Bind  syntax declaration, and text, so that the strong
authentication will work with the change in time synchronization model for
cert reliance and  general handling of clock syncronization. Im understanding
the move to GeneralizedTime to be one in which not only is there a 4 digit year,
but the parties are not bound to any a priori rules of clock synchronization.

Ive just looked up what Ive been referring to as the UTCness property. Here
the coordinated notion is more professionally expressed (by someone other
than me!):

"In each case where Strong Authentication is to take place, A must obtain the
public key of B, and the return certification path from B to A, prior to
any exchange of information. This may involve access to the Directory..."

The checking of timestamps as mentioned in the following clauses only applies
when either synchronized clocks are used in a local environment, or
if clocks are logically synchronized by bilateral agreements. In any case, it is
eecommended that Coordinated Universal Time be used":

Perhaps Im reacting to violently to this requirement, or misunderstanding these
(optional) rules of token timestamps as they apply to validity. In no sense
was a global time standard required, as I understood it. (bilateral
time system is quite ok... so long as one knows what the time source is)

On the subject of natural expiry, in all cases of strong authentication, there is the
case that B "obtains Ap [..], checking that A's certificate has not expired"

where the notion of expiry is defined:

"Certificates shall have a lifetime associated with them, at the end of which they expire. 
...Expired certificates will normally be removed from the Directory. "

Prioir to using the cert for reliance, "For each of the three authentication
procedures described below, it is assumed that party A has checked the validity
of all of the certificates in the certification path."

Validation is not otherwise defined in the standard, which is why I suspect ABA went
to the trouble of defining a uniform set of rules for the notion! And, in any case X.509 v2 says:

NOTE - This Directory Specification does not specify the procedures to the detail required
for implementation. However,  additional standards could be envisaged which would do so,
either in an application-specific or in a general-purpose way."

VeriSign sought to work within this framework, and use the material advanced by the ABA
in the areas which needed detail. Validity was part of what we conformed to by adopting the
ABA work.

I gather that the IETF is rejecting the ABA standards on these notions of 
standardised validity handling, and  each protocol/vendor is expected to do their own thing,
essentially. Where you havbe your definitions, your customers do it your way.

Kind of makes the notion of a global PKI rather difficult; but, then, this
was always an ideal of the Authentication Model.

Peter.

From: 	Mark Bartel
Sent: 	Tuesday, October 08, 1996 2:06 PM
To: 	[email-masked]'; 'Peter Williams'
Subject: 	Re: X.509 validity period

>the UTCness of UTCTime is more than a format thing, I suggest. Its
>a time rule which says the parties can be expected to by
>syncrhonized to a given time source (and universal time conventions
>for expressing the value encodings).
>
>The nature of UTC in X.509 semantics is such that you cannot make
>a claim of validity unless you are synchronised with the same time
>source used by the originator of the cert. X.509 requires
>"currency".
>
>With GeneralizedTime, its ambiguous which time source you can rely on;
>your own, the originators, the one your attacker provided... 
GeneralizedTime is
>just an ASN.1 wrapper for an ISO standard on date *formats*,
>not time handling. Of course, lax UTCTime handling systems have
>the same issues.

The time source used is *not* specified in the standard for UTCTime or 
X.509.  The standard specifies a *format*.  So one format is as good as 
another, as long as it provides the same information (or more, such as a 
century!).  I can't find anything about time source in X.509 or in X.208. 
 Of course, the source is important, but it isn't part of the standard, 
just as truly verifying the identity of the person/object being bound to 
the certificate is important but also not part of the standard.

- Mark Bartel ([email-masked])

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Subject: Re: X.509 validity period
Date: Tue, 8 Oct 1996 17:06:28 -0400
Encoding: 26 TEXT

>the UTCness of UTCTime is more than a format thing, I suggest. Its
>a time rule which says the parties can be expected to by
>syncrhonized to a given time source (and universal time conventions
>for expressing the value encodings).
>
>The nature of UTC in X.509 semantics is such that you cannot make
>a claim of validity unless you are synchronised with the same time
>source used by the originator of the cert. X.509 requires
>"currency".
>
>With GeneralizedTime, its ambiguous which time source you can rely on;
>your own, the originators, the one your attacker provided... 
GeneralizedTime is
>just an ASN.1 wrapper for an ISO standard on date *formats*,
>not time handling. Of course, lax UTCTime handling systems have
>the same issues.

The time source used is *not* specified in the standard for UTCTime or 
X.509.  The standard specifies a *format*.  So one format is as good as 
another, as long as it provides the same information (or more, such as a 
century!).  I can't find anything about time source in X.509 or in X.208. 
 Of course, the source is important, but it isn't part of the standard, 
just as truly verifying the identity of the person/object being bound to 
the certificate is important but also not part of the standard.

- Mark Bartel ([email-masked])

From: [email-masked] (Ron Rivest)
Date: Tue, 08 Oct 96 17:03:32 EDT
To: [email-masked]
Subject: Choice of symmetric algorithms in certificates

Note that some algorithms have several "size" parameters.  For example
RC5-w/r/b has *three* parameters (w=word size, r = rounds, b = number of key
bytes).  Any scheme for labelling encryption algorithms should accomodate
such variability....

	Cheers,
	Ron Rivest

From: Mark Bartel <[email-masked]>
To: "'Miklos Sue A.'" <[email-masked]>, "'Mark Bartel'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: X.509 validity period
Date: Tue, 8 Oct 1996 16:50:59 -0400
Encoding: 96 TEXT

>The Hoyt "choice proposal" is clearly now a given. The cert generated 
using
>this scheme will not be accepted by X.509 v1 systems such
>as 15 million navigator clients, and ~4 million IE clients. The explicit
>context tag added to the front of the time primitive (or the type
>checking on the UTCTime primitive)  will break the X.509 decoders.

Arrgghh!  I realize I was ambiguous.  The certs generated with the CHOICE 
scheme will look exactly the same as old certificates, as long as the 
notAfter date is pre-2K.  Is that more clear?  So current software will 
work *fine* with them.  Only post-2K certificates will cause problems.  The 
type tags on UTCTime and GeneralizedTime provide distinctness; no 
additional tag (or implicit tag) is necessary.

Almost all current certificates won't have a post-2K notAfter, and so don't 
need to change.

Sorry for the confusion...

- Mark Bartel ([email-masked])

>Its tough on those users of older software (i.e. software massively 
distirbuted
>2 months ago). For Microsoft, they should be able to issue
>a new DLL for the X.509 v1+ module over the web given
>the way they architected the solution. Entrust should
>be able to replace the v1-based systems for its numerous
>corporate organizational CAs pretty fast also to conform
>to the registered defect report/resolution (when it passes ISO).
>
>Should I  start work on preparing the secure server community to
>request a renewal of the SSL server certs to change the encoding (and find
>a message of why this is now needed). Its going
>to be nasty with a mix of old format and new format
>browsers out there  - on the server operations folk. Some
>enterprising company can perhaps sell them some tools ...
>on how to migrate standards.
>
>At what point do you believe VeriSign should reissue its
>250,000 client certs (Currently conformant to the ratified X.509 v2
>edition and the additional TC1 defect report)?
>
>Peter.
>
>
>----------
>From: 	Mark Bartel
>Sent: 	Tuesday, October 08, 1996 12:02 PM
>To: 	'Miklos Sue A.'; 'Mark Bartel'; 'Nick Pope'; 'Peter Williams'
>Cc: 	[email-masked]'; [email-masked]'; 
[email-masked]'
>Subject: 	Re: X.509 validity period
>
>>Does a choice have automatic explicit tags?
>>
>>Could a pre-Mark cert be decoded by a post-Mark cert bit decoder?
>
>The tags must be distinct, but since UTCTime and GeneralizedTime have
>different tags already, this is ok.
>
>In other words, software that parses certificates according to the old
>definition won't recognize the difference unless notAfter is post-2K.
>
>And as an aside, I understand that Hoyt came up with the CHOICE option
>first; I came in after that and hadn't seen Hoyt's post.  "Mark cert" is a 
>misnomer. :)
>
>>I think we have just said there will be two cert formats. You will
>>find out which one you are using by looking for the presence
>>of a context tag value in one or other of the the validity fields.
>>
>>Warwick suggestion adds no more complexity than
>>does any use of a v3 extension. It is certainly less
>>complex that looking for tags to switch which
>>std format one is using.
>
>I disagree.  With the CHOICE option you merely need to check tags.  With
>the extension option, you have to (a) have extensions, (b) parse the
>extensions, (c) determine whether one of them is the century extension, 
and
>(d) add that information onto the dates if it is there.  Think about
>hardware; extensions complicate it enough (with having to check for
>criticality etc.) without having to parse yet another extension.
>
>>Dont forget (as if one would) to do the same to X.509 CRLs.
>
>Yes.  All dates in CRLs should really be changed similarly.  This is not
>nearly so bad as the certificate problem, though, because CRLs are 
supposed
>to be updated frequently (so the old versions shouldn't persist like old
>certificates).  I propose that the same change be made there.
>
>- Mark Bartel ([email-masked])
>
>
>

From: Peter Williams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Mark Bartel'" <[email-masked]>
Subject: RE: X.509 validity period
Date: Tue, 8 Oct 1996 13:41:29 -0700

Mark,  

the UTCness of UTCTime is more than a format thing, I suggest. Its
a time rule which says the parties can be expected to by
syncrhonized to a given time source (and universal time conventions
for expressing the value encodings).

The nature of UTC in X.509 semantics is such that you cannot make
a claim of validity unless you are synchronised with the same time
source used by the originator of the cert. X.509 requires
"currency".

With GeneralizedTime, its ambiguous which time source you can rely on;
your own, the originators, the one your attacker provided... GeneralizedTime is
just an ASN.1 wrapper for an ISO standard on date *formats*,
not time handling. Of course, lax UTCTime handling systems have
the same issues.

You know, I just created a cert with validity from 1896...5096.
This stuffs great. I can do anything I like as a CA (apparently) All
I need is to declare myself a CA, create a cert, and hey presto, people
can rely on my certs to verify documents, and prove
when they were created! Amazing stuff this public key crypto, no!

Peter.

----------
From: 	Mark Bartel
Sent: 	Tuesday, October 08, 1996 12:32 PM
To: 	[email-masked]'; 'Peter Williams'
Subject: 	Re: X.509 validity period

>My comments are interspersed. Here we are a bunch of non-legal
>types pretending to talk about legal protocols. Its fun, abut

<chuckle>  Very true.  Again I agree (or cannot judge!) most of what you 
say.  Most aspects of validity depend upon how the CA chooses to define it, 
and the standard doesn't really enter into it.

>PW: My claim is this: you a re fixing a problem which doesnt exist, and

I'd say having to do strange and wonderful calculations to determine the 
century is a problem.  I'm not claiming that the problem can't be worked 
around or that this is difficult, I'm just claiming that it should be 
fixed.  It adds complexity that doesn't need to be there.

>if it does, noone can legally rely on any presumtion of accuracy of dating 
>with any greater value that with the current form. The only basis for
>relying on accuracy of a time assertion is to know that the data-issuing 
parties
>are syncrhonised in actual fact on a credible source of UTC data (or 
equivalent)
>and
>they will come to court to prove that fact. The UTCness of UTCTime
>expresses this requirement perfectly. See the CCIR regulations.

I don't understand your argument wrt UTCness.  GeneralizedTime can easily 
express coordinated universal time (see X.208, section 32.3, clause b). 
 There are three formats:  local time, UTC time (with a "Z" on the end), 
and local time with offset to UTC.  That last two forms correspond to the 
forms of UTCTime.  It is entirely reasonable to require (similar to 
requiring DER) certificates use the second variation, just as they 
currently require that you use the "Z" form of UTCTime instead of the 
offset form (actually, this is a DER requirement anyway).

>PW: This seems a fair position, no?.

Certainly.

- Mark Bartel ([email-masked])

From: Peter Williams <[email-masked]>
To: "'Miklos Sue A.'" <[email-masked]>, "'Mark Bartel'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: X.509 validity period
Date: Tue, 8 Oct 1996 13:26:16 -0700

Mark, Sandi, Hoyt,

The Hoyt "choice proposal" is clearly now a given. The cert generated using
this scheme will not be accepted by X.509 v1 systems such
as 15 million navigator clients, and ~4 million IE clients. The explicit
context tag added to the front of the time primitive (or the type
checking on the UTCTime primitive)  will break the X.509 decoders.

Its tough on those users of older software (i.e. software massively distirbuted
2 months ago). For Microsoft, they should be able to issue
a new DLL for the X.509 v1+ module over the web given
the way they architected the solution. Entrust should
be able to replace the v1-based systems for its numerous
corporate organizational CAs pretty fast also to conform
to the registered defect report/resolution (when it passes ISO).

Should I  start work on preparing the secure server community to
request a renewal of the SSL server certs to change the encoding (and find
a message of why this is now needed). Its going
to be nasty with a mix of old format and new format 
browsers out there  - on the server operations folk. Some
enterprising company can perhaps sell them some tools ...
on how to migrate standards.

At what point do you believe VeriSign should reissue its
250,000 client certs (Currently conformant to the ratified X.509 v2
edition and the additional TC1 defect report)?

Peter.

----------
From: 	Mark Bartel
Sent: 	Tuesday, October 08, 1996 12:02 PM
To: 	'Miklos Sue A.'; 'Mark Bartel'; 'Nick Pope'; 'Peter Williams'
Cc: 	[email-masked]'; [email-masked]'; [email-masked]'
Subject: 	Re: X.509 validity period

>Does a choice have automatic explicit tags?
>
>Could a pre-Mark cert be decoded by a post-Mark cert bit decoder?

The tags must be distinct, but since UTCTime and GeneralizedTime have 
different tags already, this is ok.

In other words, software that parses certificates according to the old 
definition won't recognize the difference unless notAfter is post-2K.

And as an aside, I understand that Hoyt came up with the CHOICE option 
first; I came in after that and hadn't seen Hoyt's post.  "Mark cert" is a 
misnomer. :)

>I think we have just said there will be two cert formats. You will
>find out which one you are using by looking for the presence
>of a context tag value in one or other of the the validity fields.
>
>Warwick suggestion adds no more complexity than
>does any use of a v3 extension. It is certainly less
>complex that looking for tags to switch which
>std format one is using.

I disagree.  With the CHOICE option you merely need to check tags.  With 
the extension option, you have to (a) have extensions, (b) parse the 
extensions, (c) determine whether one of them is the century extension, and 
(d) add that information onto the dates if it is there.  Think about 
hardware; extensions complicate it enough (with having to check for 
criticality etc.) without having to parse yet another extension.

>Dont forget (as if one would) to do the same to X.509 CRLs.

Yes.  All dates in CRLs should really be changed similarly.  This is not 
nearly so bad as the certificate problem, though, because CRLs are supposed 
to be updated frequently (so the old versions shouldn't persist like old 
certificates).  I propose that the same change be made there.

- Mark Bartel ([email-masked])

From: "Charles Moore" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Private key validity period
Date: Wed, 9 Oct 1996 06:08:43 +1000

Some of the discussions on this subject seem quite strange and appear to be

making  the whole certificate infrastructuremuch too complicated.

In the case of Signature Certificate.

> Section 12.2.2.1 of the X.509 v3 final DAM currently says about the 
> "private key validity period":
> 
>  d) ..........  The validity period of the certificate indicates a period

>     for which the public key may be used, which is not necessarily the 
>     same as the usage period of the private key.
> 
A certificate needs to be simple in its purpose, it is a representation by
a CA of the binding between the subject and his associated public key.  The
subjects private key is bound to the public key through non certificate
means.

The validity period is the scope in time that the CA supports (also legaly)
the above binding.

The affects of the above are:
1. Validity period of a signeture certificate do not affect the validity of
either private or public keys only the ability to use the private key
assocated with the binding (identified by this certificate serial no) to
represent the "subject" of the certificate.
2. If the certifcate validity period is not valid then (1) would legally
remove the requirement of the CA to support the 
binding represented by the certificate.
3. The private key associated with the public key, represented in the
certificate binding, does NOT expire or anything else 
when a  a certifiacte validity period is invalid.
4. This means that a public key identified within a certificate can ALWAYS
be used to verify a signature that was produced 
by a valid certificate (including revocation). ALWAYS will be a determined
by commercial and legal issues, it is pretty normal here to require 7
years, but for some apps periods of 20 years could be required.

> This topic was discussed at the last IETF meeting in Montreal where I had

> a presentation to explain why the "private key validity period" was 
> unnecessary when the validity period included in the X.509 certificate 
> was interpreted in the following way :
> 
> a) When the public key within the X.509 certificate is used for 
> encryption purposes (e.g. data confidentiality) then the validity period 
> within the certificate indicates the validity period of the public key.
Outside the scope of a Signature Certificate, but if a Key Management
Certificate then I suggest that the issues are 
simular to the above.
> 
> b) When the public key within the X.509 certificate is used for digital 
> signature purposes (e.g. authentication, data origin authentication with 
> integrity or non repudiation) then the validity period within the 
> certificate indicates the validity period of the private key.
NO, only the binding by the CA.
> 
> After some discussion, we all agreed that the "private key validity 
> period" would be an extension that would *not* be supported by the IETF 
> PKIX group.
Good.
> 
> If, for a moment, we forget the PKIX group position a question may arise:

> When, according to the statements hereabove, might a "private key 
> validity period" extension be ever useful ?
> 
> I have three observations: 
> 
> 1) If no justification may be given, it would be appropriate to delete 
> that extension from the ISO document
Agreed.
> 
> 2) If some justification may be given, then the current text needs anyway

> to be corrected in order to avoid a misinterpretation of the meaning of
the
> validity period included in the X.509 certificate.
Agree.
> 
> 3) Under any circumstance, the interpretation of the validity period 
> included within the X.509 certificate should be clarified.
> 
Agreed.

Date: Tue, 08 Oct 1996 13:35:03 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Choice of symmetric algorithms in certificates. -Reply

Actually, Rich, 47-bit RC4 may not be as silly as it sounds at first, 
for there seems to be some judging recognition of the need for a 
standard-of-living inflationary increase in key lengths from year to 
year. This will make the negotiation of algorithms and key lengths 
from country to country even more complex, of course.

I don't even want to think about trying to get some kind of an objective 
measure for resistance to cryptanalysis -- is 56- bit RC4 stronger or 
weaker than 56-bit DES?  But it would seem reasonable to compare 
algorithms on the basis of the "standard" or current best practice means 
of cracking the algorithm by brute force, whether by exhaustive 
search, factoring, or whatever. Since a factor of ten in strength is 
probably down in the noise as far as accuracy, how about using the 
base10 exponent of the number of MIP-machines necessary to have a 
50% probability of finding the key or otherwise breaking the algorithm?

Since our Novell Directory Service is probably the closest thing 
to an (almost) ubiquitous directory service, we could just put the 
information about what symmetric algorithms are available in the 
directory, and have GroupWise and other applications retrieve the 
information that way, and be done with it.  However, I believe that
without detracting from the practicality and desirability of distributing 
certificates via a directory, we should also allow, and maybe 
even encourage the distribution of certificates via e-mail, as 
correspondents exchange mail. (Several times I have sent 
mail to from the "wrong" person, because I didn't check the recipient's 
location or organizational function carefully enough to distinguish 
between two users with similar names. If I had used the same 
directory to retrieve from the recipient's certificate prior to encrypting the mail
from the results would have been consistent, but not at all what I intended.)

So I would prefer to put a list of available/supported algorithms and key 
strengths in my certificate, and to hope that others would do likewise. This 
will become particularly important when we start to deal with encrypted 
mail that is being sent to lists such as this, where the various members
do not all have the same algorithms available to them. (Depending on the 
sensitivity of the information, I might want to insist on a minimum cryptographic
strength, and then either not copy those who can't accept such messages, 
or perhaps "dumb down" or paraphrase the message for the rest.)

Defining an extension to provide a list of available algorithm OIDs is something 
that the pkix group could do almost immediately, and I think it would greatly 
facilitate the deployment of secure e-mail systems over from the next year or so.

Bob

>>> Rich Salz <[email-masked]> 10/08/96 12:43pm >>>
{Rewrapped to fit in common line lengths.}
>Ideally, the effective key length could be indicated as well, so that if
>the user were presented a choice, he or she would not have to understand
>all of the semantics of the algorithm OID in order to determine whether
>to select triple-DES or 40 bit RC2.

We're facing the same kind of issue in DCE, and are going to have to
maintain some kind of registry.  We're trying to decide of a single
numeric parameter, commonly called keylength is a suitable parameter,
or whether it makes more sense to call each one a different mechanism.
I'm leaning toward the latter.  While there could be 'n' different crypto
mechanisms, in practice that seems unlikely (47bit RC4, anyone?).  It
also makes the ordering harder to do -- a simple order list of mechanisms
isn't sufficient any more.  And as I said at the start of this rather
wordy paragraph, "keylength" doesn't seem general enough.  For the sake
of parallelism, shouldn't it be DES where the number of rounds is specified,
instead of 3DES? :)
	/r$

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Subject: Re: X.509 validity period
Date: Tue, 8 Oct 1996 15:32:14 -0400
Encoding: 38 TEXT

>My comments are interspersed. Here we are a bunch of non-legal
>types pretending to talk about legal protocols. Its fun, abut

<chuckle>  Very true.  Again I agree (or cannot judge!) most of what you 
say.  Most aspects of validity depend upon how the CA chooses to define it, 
and the standard doesn't really enter into it.

>PW: My claim is this: you a re fixing a problem which doesnt exist, and

I'd say having to do strange and wonderful calculations to determine the 
century is a problem.  I'm not claiming that the problem can't be worked 
around or that this is difficult, I'm just claiming that it should be 
fixed.  It adds complexity that doesn't need to be there.

>if it does, noone can legally rely on any presumtion of accuracy of dating 
>with any greater value that with the current form. The only basis for
>relying on accuracy of a time assertion is to know that the data-issuing 
parties
>are syncrhonised in actual fact on a credible source of UTC data (or 
equivalent)
>and
>they will come to court to prove that fact. The UTCness of UTCTime
>expresses this requirement perfectly. See the CCIR regulations.

I don't understand your argument wrt UTCness.  GeneralizedTime can easily 
express coordinated universal time (see X.208, section 32.3, clause b). 
 There are three formats:  local time, UTC time (with a "Z" on the end), 
and local time with offset to UTC.  That last two forms correspond to the 
forms of UTCTime.  It is entirely reasonable to require (similar to 
requiring DER) certificates use the second variation, just as they 
currently require that you use the "Z" form of UTCTime instead of the 
offset form (actually, this is a DER requirement anyway).

>PW: This seems a fair position, no?.

Certainly.

- Mark Bartel ([email-masked])

From: Mark Bartel <[email-masked]>
To: "'Miklos Sue A.'" <[email-masked]>, "'Mark Bartel'" <[email-masked]>, "'Nick Pope'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: X.509 validity period
Date: Tue, 8 Oct 1996 15:02:05 -0400
Encoding: 38 TEXT

>Does a choice have automatic explicit tags?
>
>Could a pre-Mark cert be decoded by a post-Mark cert bit decoder?

The tags must be distinct, but since UTCTime and GeneralizedTime have 
different tags already, this is ok.

In other words, software that parses certificates according to the old 
definition won't recognize the difference unless notAfter is post-2K.

And as an aside, I understand that Hoyt came up with the CHOICE option 
first; I came in after that and hadn't seen Hoyt's post.  "Mark cert" is a 
misnomer. :)

>I think we have just said there will be two cert formats. You will
>find out which one you are using by looking for the presence
>of a context tag value in one or other of the the validity fields.
>
>Warwick suggestion adds no more complexity than
>does any use of a v3 extension. It is certainly less
>complex that looking for tags to switch which
>std format one is using.

I disagree.  With the CHOICE option you merely need to check tags.  With 
the extension option, you have to (a) have extensions, (b) parse the 
extensions, (c) determine whether one of them is the century extension, and 
(d) add that information onto the dates if it is there.  Think about 
hardware; extensions complicate it enough (with having to check for 
criticality etc.) without having to parse yet another extension.

>Dont forget (as if one would) to do the same to X.509 CRLs.

Yes.  All dates in CRLs should really be changed similarly.  This is not 
nearly so bad as the certificate problem, though, because CRLs are supposed 
to be updated frequently (so the old versions shouldn't persist like old 
certificates).  I propose that the same change be made there.

- Mark Bartel ([email-masked])

From: <[email-masked]>
Date: 8 Oct 96 17:50
To: [email-masked]
To: [email-masked]
To: [email-masked]
Subject: Re: Private key validity period
Encoding: 92 TEXT

From: [email-masked] (Denis Pinkas) 
Message-Id: <[email-masked]> 
Subject: Private key validity period
To: [email-masked]
Date: Tue, 8 Oct 1996 13:16:22 +0100 (NFT)
Cc: [email-masked], [email-masked],
    [email-masked], [email-masked]
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 2.4
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit

     

While discussing with Nick Pope around the topic of the X.509 validity 
period, Nick drawn my attention on a section of the X.509 v3 final DAM.
     
Section 12.2.2.1 of the X.509 v3 final DAM currently says about the 
"private key validity period":
     
 d) ..........  The validity period of the certificate indicates a period
    for which the public key may be used, which is not necessarily the 
    same as the usage period of the private key.
     
This topic was discussed at the last IETF meeting in Montreal where I had 
a presentation to explain why the "private key validity period" was 
unnecessary when the validity period included in the X.509 certificate 
was interpreted in the following way :
     
a) When the public key within the X.509 certificate is used for 
encryption purposes (e.g. data confidentiality) then the validity period 
within the certificate indicates the validity period of the public key.
     
b) When the public key within the X.509 certificate is used for digital 
signature purposes (e.g. authentication, data origin authentication with 
integrity or non repudiation) then the validity period within the 
certificate indicates the validity period of the private key.
     
     -----------------------------
     
     Denis,
     I was at that meeting, and I do not think that anyone agreed with your 
     point b) above. The validity period always refers to the validity of 
     the certificate (i.e. name to public key binding) and not to the 
     validity of the private key. After the validity period has expired, 
     CRLs do not need to be issued.
     
     David
     -------------------------------

After some discussion, we all agreed that the "private key validity 
period" would be an extension that would *not* be supported by the IETF 
PKIX group.
     
     ----------------------
     This is true, but the decision I think was not as a result of your 
     (false) logic, but was for some other reason which I fail to recollect
     
     David
     
     ----------------------------
     
If, for a moment, we forget the PKIX group position a question may arise: 
When, according to the statements hereabove, might a "private key 
validity period" extension be ever useful ?
     
I have three observations:
     
1) If no justification may be given, it would be appropriate to delete 
that extension from the ISO document
     
2) If some justification may be given, then the current text needs anyway 
to be corrected in order to avoid a misinterpretation of the meaning of the 
validity period included in the X.509 certificate.
     
3) Under any circumstance, the interpretation of the validity period 
included within the X.509 certificate should be clarified.

Denis PINKAS.
     
--
     
============================================================================
      Denis Pinkas                           E-mail : [email-masked] 
      Bull S.A.
      Rue Jean Jaures  B.P. 68                Phone : (33-1) 30 80 34 87 
      78340 Les Clayes sous Bois. FRANCE       Fax  : (33-1) 30 80 33 21
============================================================================

From: Rich Salz <[email-masked]>
Date: Tue, 8 Oct 1996 14:43:38 -0400
To: [email-masked]
Subject: Re: Choice of symmetric algorithms in certificates.
Cc: [email-masked]

{Rewrapped to fit in common line lengths.}
>Ideally, the effective key length could be indicated as well, so that if
>the user were presented a choice, he or she would not have to understand
>all of the semantics of the algorithm OID in order to determine whether
>to select triple-DES or 40 bit RC2.

We're facing the same kind of issue in DCE, and are going to have to
maintain some kind of registry.  We're trying to decide of a single
numeric parameter, commonly called keylength is a suitable parameter,
or whether it makes more sense to call each one a different mechanism.
I'm leaning toward the latter.  While there could be 'n' different crypto
mechanisms, in practice that seems unlikely (47bit RC4, anyone?).  It
also makes the ordering harder to do -- a simple order list of mechanisms
isn't sufficient any more.  And as I said at the start of this rather
wordy paragraph, "keylength" doesn't seem general enough.  For the sake
of parallelism, shouldn't it be DES where the number of rounds is specified,
instead of 3DES? :)
	/r$

Date: Tue, 08 Oct 1996 12:14:39 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Choice of symmetric algorithms in certificates.

Jan, this is an excellent question, and I was on the verge of submitting something 
similar myself, especially after the White House announcement. I just wanted to review 
the pkix document one more time, to be sure I hadn't missed something. (Maybe I have 
even so.)

One of the major consequences I would expect from the White House announcement
will be a considerable increase in interoperability requirements between one import/export
regime and another. It isn't just US vs. the rest of the world -- the French have 
significant IMPORT restrictions, and so do some other countries.

Although an X.509 certificate defines which public key algorithm to use to encrypt
a message (or session) encryption key in, at present it makes no provision for what 
kind of a symmetric key algorithm to use.  So this has to be negotiated out-of-band,
or in a proprietary protocol.

This is bad enough in the case of a session, where negotiation is at least possible, but
highly undesirable int he case of a store and forward system such as e-mail.

I'd like to see us think about adding an extension to certificates which would provide a list
of available symmetric key algorithms that that user could accept.

Ideally, the effective key length could be indicated as well, so that if the user were
presented a choice, he or she would not have to understand all of the semantics of the
algorithm OID in order to determine whether to select triple-DES or 40 bit RC2.

Whaddaya think?

Bob

>>> Jan Luehe <[email-masked]> 10/07/96 04:30pm >>>
Hi there:

Does anybody know if special object identifiers have
been defined for encryption algorithms with a fixed
key size (e.g., DES-CBC), when used in export mode
(e.g., DES40_CBC)?

If no such object identifiers exist, how can two sites
using different versions of the same software package
(one domestic, one export) communicate with each other?

This is not a problem where the encryption keysize is
specified by a cipher suite identifier which can be negotiated
between the two communicating parties as part of a protocol
(e.g., SSL).
This is also not a problem where one site wraps the encryption
key in a digital envelope.

However, this becomes a problem if both parties establish the
encryption key independently, e.g., through password-based
encryption, and the party using the exportable version of the
software truncates the encryption key to say 40 bits.

Since the definition of DES does not provide for 
a key size parameter, how can a decrypting party
determine the (potentially truncated) key size that was
used by the encrypting party, other than through some out-of-band
mechanism?

So my question again: Is there a special AID for something
like DES40_CBC?

Thanks,

Jan Luehe
Sun Microsystems

From: Peter Williams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Mark Bartel'" <[email-masked]>
Subject: RE: X.509 validity period
Date: Tue, 8 Oct 1996 11:15:31 -0700

Mark,

My comments are interspersed. Here we are a bunch of non-legal
types pretending to talk about legal protocols. Its fun, abut
not very credible on that basis when we ask the question "is a signature
valid". As the proposed change exists to solve this problem, we
do need more thought, and wee what happens if you begin
to fiddle with the semantics which rely upon time.

----------
From: 	Mark Bartel
Sent: 	Monday, October 07, 1996 8:01 PM
To: 	[email-masked]'; 'Peter Williams'
Cc: 	[email-masked]'; [email-masked]'
Subject: 	Re: X.509 validity period

Peter,

I freely admit that I don't know much about how digitals signatures work =

with the legal system.

I was working from my understanding of the purpose of certificates, =
which=20
is to bind a name to a public key.  A certificate is valid if the =
digital=20
signature placed on that certificate by the CA verifies.

PW: You just have to more careful. An expired cert has the conditions
you mention. A revoked cert has the conditions you cared to define. Both
of the counter-examples break the binding, both technically, and =
arguably
also legally. Your understanding is flawed, I would suggest. You have
chosen to interpret the simple notion of validity period=20
in a manner which the court will reject as contrived and will
henceforth be suspicious of following arguments, I suspect.

With this is mind, the addition of validity dates to certificates seems=20
designed to limit the period of time for which the assertion is made.  =
The=20
CA asserts that between notBefore and notAfter, Jane Doe (I'll give =
Alice &=20
Bob a rest) of Acme Corp, Canada, =3D=3D XXXXXXXXXXXXX (some key).  This =
is=20
particularly necessary because Jane may leave Acme, or may change her =
name,=20
or any number of other things.  If so, the CA must revoke the =
certificate,=20
and without validity dates, the CA would have to keep that revocation on =

the CRL for all time.  Quite rapidly the length of that CRL would become =

unmanageable.

PW: You are omitting the fact that a cert's validity expires naturally =
at the
notAfter point. Remember, and be more careful not to simply ignore those
handling rules which you dont happen to want to following but which the =
std
obligates you to enforce. Ive noe idea what ghe validation policy in =
Netsacpe
servers currently is, ragardless of the fact that it can parse v3 certs,
as the company will not conform to the standard, and will not publich
its own algorithm. The value of its security is arguably worthless, in =
this sense.
Or, its as different as it yours - i.e. non- standard, and god help
the poor user in dealing with 15  different algorithms prioir to =
relying!

Legally speaking, however, I would think (again, IANAL and don't know =
much=20
about it, but this seems pretty basic) that if a disagreement or problem =

came up later with a contract that Jane signed, the courts would be=20
concerned as to whether the certificate was binding at the time.  I =
don't=20
know that the fact that the notAfter date had passed would be relevent.  =
Of=20
course, the validity period on Jane's certificate should have covered =
the=20
duration of the contract, but disputes often arise after such contracts =
are=20
completed.

PW: its a good point that to rely on a digital signature on a document, =
means you must
rely on the public key which is used techncially to verify that =
signature at
the moment or verification. To enforce the legal signature service, you =
must claim
you know to which real-world party the key is bound. You may use certs, =
if convenient,
or you may not use certs. The verification of a digital signature is not =
a function of certs or
cert-specific control systems, per se.

PW: There is thus a very strong counterarugment to your assertion, that =
facts
about certs are necessary for verification of document digital =
signatures.
That those cert facts may make things much easier and much much cheaper, =
is
not the issue at argument, and the court will not care much about =
issuing
cost until the part in the porceedings concerned with the assignment of =
damages
for tortuous liabilities.
=20

Of course, notarization and all that is undoubtedly useful.  But it =
seems=20
to me that the fact that the CAs digital signature on Jane's certificate =

verified would be an important item, regardless of validity dates.

PW: When A CA signs a VeriSIgn cert, it is intending to make a legal =
signature -
which necessailry lives in perpetuity as with any writing. The cert is =
still not valid once it=20
expires, though,  and may not be valid in any case. You can now get IBM =
and GTE signatures
on their certs for banking and commerce. Time to sue these capital =
giants and get rich quick, unless they are being careful!! But =
seriously...

Of course, if cryptography had advanced such as the certificate was easy =
to=20
forge, that would be a problem.  But that's a separate issue, and not =
the=20
issue that validity dates were designed for.

PW: The inadquacies of physical intruments for conveying real-world =
signatures (.e.g
paper, ink, math, etc) are well known and already handled in court. The =
pen with
containg the special ink with which  a signature is written may or may
not have validity date constraining its use for creating. The =
distinguishing
features of the ink, facilitating authenticity to that pen, may =
disappear
in ~4 years to constrain validity beyond that point. A notray may be =
used
to prolong the usefull of a public signature in court , whatever the pen =
manufacturer or
owner of the pen (i.e. private key) desires!

>Depends on how you define purpose and use as to what valdiity mean, say =
I.

Exactly.  My understanding is that validity dates are pretty much a CRL=20
management artifice.  This is not to say that they aren't important; =
Jane=20
couldn't sign a document with the private key corresponding to a given=20
certificate after notAfter and have it binding.  Of course, without=20
timestamping it could be difficult to determine when exactly Jane did =
sign=20
that document.

PW: "pretty much a CRL management artifice.  This is not to say that =
they aren't
important" you say. The value of a cert is you can rely on it for
authenicating a real-world party. You can only  reasonably rely on it if =
you
know its not revoked/suspsended. To downplay revocation like this
may be commercially and legally irresponsible.

PW: But the point is strangely correct despite the lack of undersatnding
if importance (for legal-grade signatures environments). Validity is
an artifact of - well, validity. And indeed CRLs affect validity, as
does current time. And validity i na cert is only an assertion about the =
cert. Any
conjecture that it affects bindings, documents, etc is for one to argue =
in court. A strong basis
for counter-argument has been provided to your defending opponnent, and
ratified by the American Bar Association.. its possible the judge may =
respect
the ABA's considered opinion. (The VeriSign CPS is believed (and =
certainly intended)=20
to conform fo the ABA Digital Signature Guidelines, by the way.)

My previous rant was mostly about people assuming that X.509 wouldn't be =

around in a century (maybe true, maybe not, but rash and irresponsible =
to=20
assume).  The hack with UTCTime is appropriate for a specific=20
implementation... but, IMHO, unforgivable in a standard.  It is=20
unreasonable to require that every implementation go through contortions =
to=20
make up for a deficiency in that standard; the standard should change to =
be=20
more usable.  I find it particularly amazing that this didn't get =
changed=20
in version 2, considering there can't have been many certificates around =

then, so compatibility wouldn't have been as big an issue.  Even now, =
there=20
aren't that many certificates around.

PW: My claim is this: you a re fixing a problem which doesnt exist, and
if it does, noone can legally rely on any presumtion of accuracy of =
dating=20
with any greater value that with the current form. The only basis for
relying on accuracy of a time assertion is to know that the data-issuing =
parties
are syncrhonised in actual fact on a credible source of UTC data (or =
equivalent) and
they will come to court to prove that fact. The UTCness of UTCTime
expresses this requirement perfectly. See the CCIR regulations.

PW: Otherwise, with randomn time handling, certs will not be reliable. =
Its just as with
serial number monotiicity; you rely on this fact, and your provider must =
be able to prove how it
is provided, if the reliance instrument has any value when disputed. =
Obivously, this
is where the trust/reliability part of issuing parties comes in...

I apologise for not responding to the rest of this, but the main issue =
to=20
me was the assumption that X.509 would be obsolete long before 2087 and=20
therefore there was no reason to change it.  I don't know enough about =
the=20
issues you raise to argue one way or the other; indeed, on the most part =
I=20
am inclined to agree with you (except for what I've said above, of =
course).

PW: I personally suspect X.509 will be obsolete before the end of
the year. I want to use the IETF work, but only when everyone else
does too!  As commercial parties choose to use other types of certs =
based
on public standards, we will provide the authentication management =
service in
those formats, just as with X.509. =20

PW: This seems a fair position, no?. Support and conform to the public =
standards which
people want to use. (I wonder how SPKI is doing these days with
its capability model? Seemed to be achieving progress, once it
got off the ASN.1/DER rant)

- Mark Bartel ([email-masked])

PS.  Minor point of interest--I've noticed that VeriSign's serial =
numbers=20
are *huge*.  I don't know that there is any reason they would need to =
get=20
larger over the next century.  I suspect they generate a GUID (or =
rather,=20
whatever that is called in the DCE RPC spec) for each user to guarantee=20
uniqueness, rather than relying on sequential numbering.  Of course, =
since=20
those use the current date, it would not be a problem figuring out when =
it=20
was generated.

PW: its realistically possible in the next 300 years that VeriSign =
masked serial numbers
may double in size, assuming current compute power. But, I doubt it. =
Certs
are useful; but I fully expect something better to arrive within 50 =
years! The
infrastructure deployed for X.509 cets will be hihgly reusable though,
as its the human element of the authentication controls which matters, =
not the
technology syntax or cipher.

Peter.

>VeriSign defined it, in paraphrase, as
>you cannot rely upon the certificate unless the certificate is valid.=20
Validity
>is defined in the technical standard as a period, and that is expressed
>using notBefore/notAfter universal times. It also says the signer
>may not create digital signature outside the operational period
>of the cert. (In better software, we can use v3 std extensions
>to enforce this; v3 std extensions even have disclaimed and juicy
>GeneralizedTime fields for just such a judicious control purpose!)
>
>As this whole thread started on the basis that a signature on
>a document may be contested at any time following creation,
>one should realise the impact of the above paraphrased formalism.
>
>For authentication protocols, its the syncrhonization of clocks
>at sender and receiver which matters. For legal purposes, the
>argument about periodicity is quite different, as legal time has a =
fixed=20
point,
>namely the judges watch. A plaintiff has to make cliams wrt that point,
>adn here is where things start to break down, in the credibility of the
>claim of  validity of a cert in the next/last century.
>
>All I can really say is that if you use a VeriSign certificate to =
validate
>a digital signature, you are obligated to rely upon that cerificate =
only
>while it is valid. (you may note the use of while, not "when".) The=20
longevity
>of a digital signature can be ensured through notarial practices.
>
>As with any signed document, a careful party will store a copy of
>the writing forever, unless the signature or content limits its period
>of validity. the ability to show that a document with the same =
signature
>existed 100 years ago may well be disasterous for your case;
>all one needs is to show someone (anyone, just one!)  during the =
previous
>century made a verification of that signature which conformed to
>the prevailing prctices governing use of the reliance instruments.
>
>A party which seeks to pretend that the period of validity relates to a =

date in
>a century other than which the CA issued it will have to explain why =
the
>VeriSign serial numbers are so small, indicating an ancient
>cert. Where VeriSign masks serialNumbers, its heirs and successors
>will no doubt be willing to give to the court, in camera, the data and=20
method
>of proving the monotonicity, for such a special-case claim.
>
>Those CAs today using PCMCIA devices or other devices not
>designed for trustworthy cert issuing may struggle to support
>their clients using digital signatures to sign/authenticate documents,=20
when
>it comes down to the wire on the subtler issues of dig sig
>security (versus mere risk management, crypto and key protection!)
>A Fortezza card is really not suitable for commercial notarys or
>commercial CAs, without support from other trusted design/devices. A=20
pocket-size
>PCMCIA RSA card without emanations security may not be suitable =
whatsoever
>for such purposes!
>
>Seriously, if a relying party seeks to use a cert to contest a digital
>signature without ensuring the cert is valid, it is not acting in a=20
(commercially)
>reasonable manner, claim I. A damaged relying party claiming validity =
will=20
have
>to explain to the court how it ascertained that validity - it having=20
(apparently)
>
>the burden of proof. I would ask, as a mock-attorney, when, sir, did =
you
>first obtain the digtially-signed document, and what reasonable steps =
did=20
you use
>to confirm its validity before relying on it?
>
>Ask yourself how many overlaying/overlapping controls exist in the=20
VeriSign
>CPS to control this reasonable reliance on a technology. E.g. a digital =

signature
>may
>only be created during the operation period of a cert. E.g. the relying =

party
>must determine no cert in the chain is revoked/suspended. E.G. for
>use in non-repudiation services, the data to be digitally signed must=20
include
>time and date (legal terms, not ISO terms) (A PKCS7 signingTime
>attribute in the signature block will NOT suffice!) E.G. the reliance =
is=20
reasonable
>under the circumstances...relying party ...additional assurnaces... =
must=20
obtain
>...
>to be reasonable E.G. relying party has complied with all requirements =
of=20
[] CPS.
>
>Read the VeriSign CPS carefully for a description of a system
>for digital signatures relying upon certificates (X.509 technology for
>the moment; SPKI and Ron Rivest's SDSI certs next, perhaps)
>
>Ask for the CA's Certifcation Practice Statement (CPS), before you
>buy a certificate or procure any service involving digital signatures!=20
Ensure
>the CA company is willing to be legally bound to it!
>
>Peter.
>
>
>

From: <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at relay-3.mail.demon.net
To: Nick Pope <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 3 Oct 1996 11:35:08 +0000
Subject: Re: Re[2]: X.509 Bug Regarding Policy Constraints
CC: [email-masked]
Priority: normal

Hoyt

Yes, I agree that the details of the procedures needs sorting out.  
My concern is that the proposed resolution removes functionality.  

Thus, I agree with progressing with a defect report and identifying a 
resoution speedily so that it can be incorporated in the published 
text.

I will respond to Warwicks mail suggesting a possible way forward.

Nick

> 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

Date: Tue, 08 Oct 1996 11:28:25 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Private key validity period -Reply

Denis, I'm sorry I couldn't attend the Montreal IETF meeting, for I would have objected 
strongly, as I have in the past, to your proposed interpretation of the public key vs. 
private key validity period with respect to digital signatures (only).

In my mind, the definition is perfectly clear, as is the intent. The public key validity 
period defines the interval during which the CA is obligated to report any compromises,
revocations, etc. Without setting some limit, the CRL list would be enormous.

In addition, the public key validity period, AKA the certificate validity period, defines a
sort of sunset law with respect to the assumption that the binding between the public 
key and the entity named in the certificate should still be assumed to be correct, even 
if the certificate has not been explicitly revoked.

Depending on the CAs Certification Practice Statement, the likelihood that a CA will
exercise an on-going awareness of the status of a subject ranges from poor to
no-way-in-hell. If the CA is operated by a corporation as a means of validating the
credentials of its employees, then there is a pretty good chance (but not 100%) 
that if the employee changes names or leaves the company the certificate will be 
revoked. But if CompuServe, AOL, or even VeriSign issues certificates to the ordinary
man-in-the-street user, the chance that the certificate will be revoked if the person 
moves or dies approaches zero. (If they fail to pay their bill, that might be a different 
story. :-)

On the other hand, the private key validity period provides a very meaningful and 
useful way of limiting the risk that is associated with the use of a digital signature 
key. The fundamental principle is that if a key is zeroized, it can no longer be 
compromised or stolen.

So if I am operating a CA, where my certificates may need to have a operational validity
period of three to five years to limit how often all of the subordinate certificates have
to be reissued, I can "retire" the public key used to sign those certificates after only 
one year, and reduce my risk. The private key validity period indicates when I expect 
to do that, and it places the relying party effectively on notice that anything that 
was purportedly signed after the expiration of my private key validity period should 
be scrutinized very carefully.

Not supporting the private key validity period in the ietf-pkix document would be a
very serious mistake, in my judgment. There are more than enough splinter groups 
flying off in all directions with their own proposals for certificates -- the pkix group 
should not be one of them. Instead, we should endeavor to provide the maximum 
support possible for international standards and the applicable legal and business
practices. 

Otherwise, both the vendor and the user community may decide that the ietf is
irrelevant and they will ignore us, as they have apparently already concluded 
in the secure e-mail arena.

Bob

>>> Denis Pinkas <[email-masked]> 10/08/96 06:16am >>>

While discussing with Nick Pope around the topic of the X.509 validity 
period, Nick drawn my attention on a section of the X.509 v3 final DAM.

Section 12.2.2.1 of the X.509 v3 final DAM currently says about the 
"private key validity period":

 d) ..........  The validity period of the certificate indicates a period 
    for which the public key may be used, which is not necessarily the 
    same as the usage period of the private key.

This topic was discussed at the last IETF meeting in Montreal where I had 
a presentation to explain why the "private key validity period" was 
unnecessary when the validity period included in the X.509 certificate 
was interpreted in the following way :

a) When the public key within the X.509 certificate is used for 
encryption purposes (e.g. data confidentiality) then the validity period 
within the certificate indicates the validity period of the public key.

b) When the public key within the X.509 certificate is used for digital 
signature purposes (e.g. authentication, data origin authentication with 
integrity or non repudiation) then the validity period within the 
certificate indicates the validity period of the private key.

After some discussion, we all agreed that the "private key validity 
period" would be an extension that would *not* be supported by the IETF 
PKIX group.

If, for a moment, we forget the PKIX group position a question may arise: 
When, according to the statements hereabove, might a "private key 
validity period" extension be ever useful ?

I have three observations: 

1) If no justification may be given, it would be appropriate to delete 
that extension from the ISO document

2) If some justification may be given, then the current text needs anyway 
to be corrected in order to avoid a misinterpretation of the meaning of the
validity period included in the X.509 certificate.

3) Under any circumstance, the interpretation of the validity period 
included within the X.509 certificate should be clarified.

Denis PINKAS.

-- 

============================================================================
      Denis Pinkas                           E-mail : [email-masked]
      Bull S.A.                                                             
      Rue Jean Jaures  B.P. 68                Phone : (33-1) 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE       Fax  : (33-1) 30 80 33 21
============================================================================

From: Peter Williams <[email-masked]>
To: "Miklos Sue A." <[email-masked]>, Mark Bartel <[email-masked]>, "'Nick Pope'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: X.509 validity period
Date: Tue, 8 Oct 1996 10:09:31 -0700

Does a choice have automatic explicit tags?

Could a pre-Mark cert be decoded by a post-Mark cert bit decoder?

I think we have just said there will be two cert formats. You will
find out which one you are using by looking for the presence
of a context tag value in one or other of the the validity fields.

Warwick suggestion adds no more complexity than
does any use of a v3 extension. It is certainly less
complex that looking for tags to switch which
std format one is using.

Dont forget (as if one would) to do the same to X.509 CRLs.

one should consider also tinkering with the X.500 BIND and/or
OPTINOALLY-SIGNED definition also, if the US PKI is to demand strong
authentication on the global directory.

----------
From: 	Nick Pope
Sent: 	Tuesday, October 08, 1996 2:52 AM
To: 	Miklos Sue A.; Mark Bartel
Cc: 	[email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: 	Re: X.509 validity period

In reply to your message of  7 Oct 96, 13:38:

I find this the most neat solution to this problem.  I believe it meets 
the extensibility requirements that systems recognising the new variant 
can interwork with systems using the old structure.  It also gives 
implemetors a few years to incroporate the change.
...

> 
> Warwick's solution adds significant complexity to validity checking.
> 
> My preference would be to redefine Validity:
> 
> Validity ::= SEQUENCE {
>     notBefore     CertificateValidityDate,
>     notAfter      CertificateValidityDate }
> 
> CertificateValidityDate ::= CHOICE {
>     utcTime       UTCTime,
>     generalTime   GeneralizedTime }
> 
> Additionally, specify that UTCTime should be used for both if notAfter
> is before the year 2000, otherwise GeneralizedTime should be used (for
> both).  Also specify that generalTime must be specified in coordinated
> universal time (ie. no local time!).
> 
> I think this solution has the advantage of maintaining compatibility
> for certificates in the short term without adding a lot of complexity
> in the long term.
> 
> Mark Bartel ([email-masked])
> 
> >  ----------
> > From: pki-twg-request
> > To: [email-masked]; [email-masked]; 
> > [email-masked]
> > Subject: RE: X.509 validity period
> > Date: Monday, October 07, 1996 4:45AM
> > 
> > This thread seems to be drifting seriously.  With a view to
> > returning it to track and hopefully concluding it, following is a
> > suggested "fix" for X.509 for those who are really concerned about
> > 4-digit years.  The attraction of this fix is that few implementors
> > will need to do anything for a long time. Whether such a fix is
> > warranted is an open question; someone who feels strongly enough
> > should raise a defect report.
> > 
> > Warwick
> >  ----------------
> > 
> > Validity Century Extension
> > 
> > validityCentury EXTENSION ::= {
> >   SYNTAX   ValidityCenturySyntax
> >   IDENTIFIED BY { id-ce ? }}
> > 
> > ValidityCenturySyntax ::= SEQUENCE {
> >   notBeforeCentury  [0] INTEGER OPTIONAL,
> >   notAfterCentury   [1] INTEGER OPTIONAL }
> > 
> > The values of notBeforeCentury and notAfterCentury give the century
> > figures to be prefixed to the year fields in the nonBefore and
> > notAfter components of the certificate validity field.  If the
> > notBeforeCentury or notAfterCentury field is omitted or the
> > validityCentury extension is absent, the century figures default to
> > 19 for a year value in the range 88 to 99, and 20 for a year value
> > in the range 00 to 87.  This extension shall be flagged noncritical
> > if both default values are indicated or critical otherwise.
> >  -------------------------------------------------------------------
> > Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
> >    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> >  -------------------------------------------------------------------
> > 
> > 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Nick Pope <[email-masked]>
To: [email-masked], Denis Pinkas <[email-masked]>
Date: Tue, 8 Oct 1996 16:49:58 +0000
Subject: Re: Private key validity period
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Priority: normal

In reply to your message of  8 Oct 96, 13:16 from Denis Pinkas:

I have concern about changing the agreed meanings of validity period 
and private key validity.  Whilst it may be possible to use just the 
validity period with Denis' proposed change to the meaning I don't see 
why there is a "Defect" with the alternative meanings used in X.509.

If the issue is that it might be done more efficiently, we would be 
continuously changing standards as every day someone came up with a 
slightly more efficient way of doing things.

Nick
> 
> 
> 
> While discussing with Nick Pope around the topic of the X.509 validity
> period, Nick drawn my attention on a section of the X.509 v3 final
> DAM.
> 
> Section 12.2.2.1 of the X.509 v3 final DAM currently says about the
> "private key validity period":
> 
>  d) ..........  The validity period of the certificate indicates a
>  period 
>     for which the public key may be used, which is not necessarily the
>     same as the usage period of the private key.
> 
> This topic was discussed at the last IETF meeting in Montreal where I
> had a presentation to explain why the "private key validity period"
> was unnecessary when the validity period included in the X.509
> certificate was interpreted in the following way :
> 
> a) When the public key within the X.509 certificate is used for 
> encryption purposes (e.g. data confidentiality) then the validity
> period within the certificate indicates the validity period of the
> public key.
> 
> b) When the public key within the X.509 certificate is used for
> digital signature purposes (e.g. authentication, data origin
> authentication with integrity or non repudiation) then the validity
> period within the certificate indicates the validity period of the
> private key.
> 
> After some discussion, we all agreed that the "private key validity
> period" would be an extension that would *not* be supported by the
> IETF PKIX group.
> 
> If, for a moment, we forget the PKIX group position a question may
> arise: When, according to the statements hereabove, might a "private
> key validity period" extension be ever useful ?
> 
> I have three observations: 
> 
> 1) If no justification may be given, it would be appropriate to delete
> that extension from the ISO document
> 
> 2) If some justification may be given, then the current text needs
> anyway to be corrected in order to avoid a misinterpretation of the
> meaning of the validity period included in the X.509 certificate.
> 
> 3) Under any circumstance, the interpretation of the validity period
> included within the X.509 certificate should be clarified.
> 
> 
> Denis PINKAS.
> 
> -- 
> 
> ======================================================================
> ======
>       Denis Pinkas                           E-mail :
>       [email-masked] Bull S.A.                                 
>                                  Rue Jean Jaures  B.P. 68             
>         Phone : (33-1) 30 80 34 87 78340 Les Clayes sous Bois. FRANCE 
>            Fax  : (33-1) 30 80 33 21
> ======================================================================
> ======
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at relay-3.mail.demon.net
To: Nick Pope <[email-masked]>, [email-masked], [email-masked], [email-masked], Warwick Ford <[email-masked]>
Date: Thu, 3 Oct 1996 12:34:28 +0000
Subject: Re: X.509 Bug Regarding Policy Constraints
CC: [email-masked]
Priority: normal

Warwick

In reply to you message of  Wed, 02 Oct 1996 17:50:47 -0400

I believe that there is confusion over the roles of the Policy 
constraints field and the certificate policies field.

I understand that the Certificate policies field relates to:
"different applications which may use the certified key".

Whereas the Policy constraints field:
"specifies constraints ......  for the remainder of the
certification path".

I believe the problem lies in 12.4.3 item list after:
"The following checks are applied to a certificate:
....
d)	If the certificate policies extension is present and is flagged
critical, ........".

This needs re-wording to use policy set and require explicit 
policy in the policy constraints field to control the acceptable policy set
and mandated policy indicator.  These state valiable should be used 
to match against the certificate policies field of subsequent 
certificates.

I do agree that the use of SEQUENCE OF in the Policy Constraints 
field is unnecessary and adds to the complexity of the processing.  I 
do not believe that this is necessary, provided that the Certified 
Policies is to be a subset of all the Policy Constraints of preceding 
certificates.

Let me know if you want me to draft an alternative resolution.

Regards

Nick

> 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.  
> >> 
> >> Warwick
> >> --------------------------------------
> >> 
> >>
> >......
> >
> >> 10.	Nature of Defect:  (complete, concise explanation of the perceived
> >> problem)
> >> 
> >> 12.4.2.3 (Policy constraints field) includes a policySet component in
> >> the ASN.1 and describes its semantics, but the path processing
> >> procedure in 12.4.3 does not include processing for that component. 
> >> If processing for policySet were to be added to 12.4.3, the algorithm
> >> would become very complex, with little real benefit.  It is the
> >> submitter's contention that policySet should have been removed in the
> >> DAM editing process (the same component was removed from the Name
> >> constraints field), but was inadvertently left in.
> >> 
> >> 11.	Solution Proposed by the Source:  (optional)
> >> 
> >> In 12.4.2.3, remove the policySet component from the ASN.1 and delete
> >> the first paragraph after the ASN.1.  Also remove the SEQUENCE OF from
> >> the ASN.1, as this becomes unnecessary.  Assign the extension a new
> >> OID (id-ce 36) to avoid confusion.  Reflect the same ASN.1 changes in
> >> Annex A.
> >> 
> >> 12.	Editor's Response:
> >> (any material proposed for processing as an erratum to, an amendment
> >> to, or a commentary on the IS or DIS final text/CCITT Recommendation
> >> or Draft Recommendation is attached separately to this completed
> >> report).
> >> 
> >> 
> >> 
> >> 
> >> -------------------------------------------------------------------
> >> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
> >>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> >> -------------------------------------------------------------------
> >> 
> >
> >-------------------------------------
> >
> >
> >Security & Standards
> >Suite A
> >191 Moulsham St.
> >Chelmsford
> >Essex
> >CM2 0LG
> >U.K.
> >
> >Tel: +44 1245 495018
> >Fax: +44 1245 494517
> >
> >
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 
> 

Date: Tue, 08 Oct 1996 10:31:23 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: X.509 validity period -Reply

I agree with Mark, both regarding his previous excellent message and his concern 
for "fluffing up" the certificate structure. The CHOICE option proposed by Hoyt, with 
pre-and post 2000 rule he proposed for notAfter, would be my strong preference.

Bob

>>> Mark Bartel <[email-masked]> 10/07/96 11:38am >>>
> I would be happy to bring the defect report into our next ISO editing 
> meeting... I have also cc'd Bancroft Scott on this, as I had anticipated 
> some DER representation of UTCTime, which is another potential time-related 
> problem... I certainly don't expect the discussion to gravitate onto any 
> other tangents.  If anyone has objections to a defect report, or suggestions 
> other than Warwick's, please send them to me.  [email-masked]
> Sandi

Warwick's solution adds significant complexity to validity checking.

My preference would be to redefine Validity:

Validity ::= SEQUENCE {
    notBefore     CertificateValidityDate,
    notAfter      CertificateValidityDate }

CertificateValidityDate ::= CHOICE {
    utcTime       UTCTime,
    generalTime   GeneralizedTime }

Additionally, specify that UTCTime should be used for both if notAfter
is before the year 2000, otherwise GeneralizedTime should be used (for
both).  Also specify that generalTime must be specified in coordinated
universal time (ie. no local time!).

I think this solution has the advantage of maintaining compatibility
for certificates in the short term without adding a lot of complexity
in the long term.

Mark Bartel ([email-masked])

>  ----------
> From: pki-twg-request
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: X.509 validity period
> Date: Monday, October 07, 1996 4:45AM
> 
> This thread seems to be drifting seriously.  With a view to returning it to
> track and hopefully concluding it, following is a suggested "fix" for X.509
> for those who are really concerned about 4-digit years.  The attraction of
> this fix is that few implementors will need to do anything for a long time.
> Whether such a fix is warranted is an open question; someone who feels
> strongly enough should raise a defect report.
> 
> Warwick
>  ----------------
> 
> Validity Century Extension
> 
> validityCentury EXTENSION ::= {
>   SYNTAX   ValidityCenturySyntax
>   IDENTIFIED BY { id-ce ? }}
> 
> ValidityCenturySyntax ::= SEQUENCE {
>   notBeforeCentury  [0] INTEGER OPTIONAL,
>   notAfterCentury   [1] INTEGER OPTIONAL }
> 
> The values of notBeforeCentury and notAfterCentury give the century figures
> to be prefixed to the year fields in the nonBefore and notAfter components
> of the certificate validity field.  If the notBeforeCentury or
> notAfterCentury field is omitted or the validityCentury extension is absent,
> the century figures default to 19 for a year value in the range 88 to 99,
> and 20 for a year value in the range 00 to 87.  This extension shall be
> flagged noncritical if both default values are indicated or critical
> otherwise.
>  -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
>  -------------------------------------------------------------------
> 
> 

From: [email-masked] (Denis Pinkas)
Subject: Private key validity period
To: [email-masked]
Date: Tue, 8 Oct 1996 13:16:22 +0100 (NFT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

While discussing with Nick Pope around the topic of the X.509 validity 
period, Nick drawn my attention on a section of the X.509 v3 final DAM.

Section 12.2.2.1 of the X.509 v3 final DAM currently says about the 
"private key validity period":

 d) ..........  The validity period of the certificate indicates a period 
    for which the public key may be used, which is not necessarily the 
    same as the usage period of the private key.

This topic was discussed at the last IETF meeting in Montreal where I had 
a presentation to explain why the "private key validity period" was 
unnecessary when the validity period included in the X.509 certificate 
was interpreted in the following way :

a) When the public key within the X.509 certificate is used for 
encryption purposes (e.g. data confidentiality) then the validity period 
within the certificate indicates the validity period of the public key.

b) When the public key within the X.509 certificate is used for digital 
signature purposes (e.g. authentication, data origin authentication with 
integrity or non repudiation) then the validity period within the 
certificate indicates the validity period of the private key.

After some discussion, we all agreed that the "private key validity 
period" would be an extension that would *not* be supported by the IETF 
PKIX group.

If, for a moment, we forget the PKIX group position a question may arise: 
When, according to the statements hereabove, might a "private key 
validity period" extension be ever useful ?

I have three observations: 

1) If no justification may be given, it would be appropriate to delete 
that extension from the ISO document

2) If some justification may be given, then the current text needs anyway 
to be corrected in order to avoid a misinterpretation of the meaning of the
validity period included in the X.509 certificate.

3) Under any circumstance, the interpretation of the validity period 
included within the X.509 certificate should be clarified.

Denis PINKAS.

-- 

============================================================================
      Denis Pinkas                           E-mail : [email-masked]
      Bull S.A.                                                             
      Rue Jean Jaures  B.P. 68                Phone : (33-1) 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE       Fax  : (33-1) 30 80 33 21
============================================================================

From: Nick Pope <[email-masked]>
To: [email-masked]
Date: Tue, 8 Oct 1996 12:49:20 +0000
Subject: Transports for PKI Cert Man Protocols
Priority: normal

The PKI internet draft Part III: Certificate management protocols 
currently does not include anything for the Transports section which 
defines how the ASN.1 encoded messages are carried over TCP/IP, E-mail 
and HTTP.

Has anyone produce this transport yet that they could send me, or are 
there any good examples for other similar ASN.1 protocols.

I thought of using the LDAP (RFC 1777) section 3 (copied below)
as the basis for use of TCP with additional requirement that DER be 
used.

I presume that mapping to E-mail / HTTP requires a new MIME content 
type.

Nick

--- Extract from LDAP RFC 1777
3.  Mapping Onto Transport Services

   This protocol is designed to run over connection-oriented, reliable
   transports, with all 8 bits in an octet being significant in the data
   stream.  Specifications for two underlying services are defined here,
   though others are also possible.

3.1.  Transmission Control Protocol (TCP)

   The LDAPMessage PDUs are mapped directly onto the TCP bytestream.
   Server implementations running over the TCP should provide a protocol
   listener on port xxx.

Yeong, Howes & Kille                                            [Page 2]
 RFC 1777                          LDAP                        March
1995

3.2.  Connection Oriented Transport Service (COTS)

   The connection is established.  No special use of T-Connect is made.
   Each LDAPMessage PDU is mapped directly onto T-Data.

--- End of extract from RFC 1777

Nick Pope

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Nick Pope <[email-masked]>
To: "Miklos Sue A." <[email-masked]>, Mark Bartel <[email-masked]>
Date: Tue, 8 Oct 1996 09:52:13 +0000
Subject: Re: X.509 validity period
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Priority: normal

In reply to your message of  7 Oct 96, 13:38:

I find this the most neat solution to this problem.  I believe it meets 
the extensibility requirements that systems recognising the new variant 
can interwork with systems using the old structure.  It also gives 
implemetors a few years to incroporate the change.
....

> 
> Warwick's solution adds significant complexity to validity checking.
> 
> My preference would be to redefine Validity:
> 
> Validity ::= SEQUENCE {
>     notBefore     CertificateValidityDate,
>     notAfter      CertificateValidityDate }
> 
> CertificateValidityDate ::= CHOICE {
>     utcTime       UTCTime,
>     generalTime   GeneralizedTime }
> 
> Additionally, specify that UTCTime should be used for both if notAfter
> is before the year 2000, otherwise GeneralizedTime should be used (for
> both).  Also specify that generalTime must be specified in coordinated
> universal time (ie. no local time!).
> 
> I think this solution has the advantage of maintaining compatibility
> for certificates in the short term without adding a lot of complexity
> in the long term.
> 
> Mark Bartel ([email-masked])
> 
> >  ----------
> > From: pki-twg-request
> > To: [email-masked]; [email-masked]; 
> > [email-masked]
> > Subject: RE: X.509 validity period
> > Date: Monday, October 07, 1996 4:45AM
> > 
> > This thread seems to be drifting seriously.  With a view to
> > returning it to track and hopefully concluding it, following is a
> > suggested "fix" for X.509 for those who are really concerned about
> > 4-digit years.  The attraction of this fix is that few implementors
> > will need to do anything for a long time. Whether such a fix is
> > warranted is an open question; someone who feels strongly enough
> > should raise a defect report.
> > 
> > Warwick
> >  ----------------
> > 
> > Validity Century Extension
> > 
> > validityCentury EXTENSION ::= {
> >   SYNTAX   ValidityCenturySyntax
> >   IDENTIFIED BY { id-ce ? }}
> > 
> > ValidityCenturySyntax ::= SEQUENCE {
> >   notBeforeCentury  [0] INTEGER OPTIONAL,
> >   notAfterCentury   [1] INTEGER OPTIONAL }
> > 
> > The values of notBeforeCentury and notAfterCentury give the century
> > figures to be prefixed to the year fields in the nonBefore and
> > notAfter components of the certificate validity field.  If the
> > notBeforeCentury or notAfterCentury field is omitted or the
> > validityCentury extension is absent, the century figures default to
> > 19 for a year value in the range 88 to 99, and 20 for a year value
> > in the range 00 to 87.  This extension shall be flagged noncritical
> > if both default values are indicated or critical otherwise.
> >  -------------------------------------------------------------------
> > Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
> >    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> >  -------------------------------------------------------------------
> > 
> > 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: X.509 validity period
Date: Mon, 7 Oct 1996 23:01:27 -0400
Encoding: 175 TEXT

Peter,

I freely admit that I don't know much about how digitals signatures work 
with the legal system.

I was working from my understanding of the purpose of certificates, which 
is to bind a name to a public key.  A certificate is valid if the digital 
signature placed on that certificate by the CA verifies.

With this is mind, the addition of validity dates to certificates seems 
designed to limit the period of time for which the assertion is made.  The 
CA asserts that between notBefore and notAfter, Jane Doe (I'll give Alice & 
Bob a rest) of Acme Corp, Canada, == XXXXXXXXXXXXX (some key).  This is 
particularly necessary because Jane may leave Acme, or may change her name, 
or any number of other things.  If so, the CA must revoke the certificate, 
and without validity dates, the CA would have to keep that revocation on 
the CRL for all time.  Quite rapidly the length of that CRL would become 
unmanageable.

Legally speaking, however, I would think (again, IANAL and don't know much 
about it, but this seems pretty basic) that if a disagreement or problem 
came up later with a contract that Jane signed, the courts would be 
concerned as to whether the certificate was binding at the time.  I don't 
know that the fact that the notAfter date had passed would be relevent.  Of 
course, the validity period on Jane's certificate should have covered the 
duration of the contract, but disputes often arise after such contracts are 
completed.

Of course, notarization and all that is undoubtedly useful.  But it seems 
to me that the fact that the CAs digital signature on Jane's certificate 
verified would be an important item, regardless of validity dates.

Of course, if cryptography had advanced such as the certificate was easy to 
forge, that would be a problem.  But that's a separate issue, and not the 
issue that validity dates were designed for.

>Depends on how you define purpose and use as to what valdiity mean, say I.

Exactly.  My understanding is that validity dates are pretty much a CRL 
management artifice.  This is not to say that they aren't important; Jane 
couldn't sign a document with the private key corresponding to a given 
certificate after notAfter and have it binding.  Of course, without 
timestamping it could be difficult to determine when exactly Jane did sign 
that document.

My previous rant was mostly about people assuming that X.509 wouldn't be 
around in a century (maybe true, maybe not, but rash and irresponsible to 
assume).  The hack with UTCTime is appropriate for a specific 
implementation... but, IMHO, unforgivable in a standard.  It is 
unreasonable to require that every implementation go through contortions to 
make up for a deficiency in that standard; the standard should change to be 
more usable.  I find it particularly amazing that this didn't get changed 
in version 2, considering there can't have been many certificates around 
then, so compatibility wouldn't have been as big an issue.  Even now, there 
aren't that many certificates around.

I apologise for not responding to the rest of this, but the main issue to 
me was the assumption that X.509 would be obsolete long before 2087 and 
therefore there was no reason to change it.  I don't know enough about the 
issues you raise to argue one way or the other; indeed, on the most part I 
am inclined to agree with you (except for what I've said above, of course).

- Mark Bartel ([email-masked])

PS.  Minor point of interest--I've noticed that VeriSign's serial numbers 
are *huge*.  I don't know that there is any reason they would need to get 
larger over the next century.  I suspect they generate a GUID (or rather, 
whatever that is called in the DCE RPC spec) for each user to guarantee 
uniqueness, rather than relying on sequential numbering.  Of course, since 
those use the current date, it would not be a problem figuring out when it 
was generated.

>VeriSign defined it, in paraphrase, as
>you cannot rely upon the certificate unless the certificate is valid. 
Validity
>is defined in the technical standard as a period, and that is expressed
>using notBefore/notAfter universal times. It also says the signer
>may not create digital signature outside the operational period
>of the cert. (In better software, we can use v3 std extensions
>to enforce this; v3 std extensions even have disclaimed and juicy
>GeneralizedTime fields for just such a judicious control purpose!)
>
>As this whole thread started on the basis that a signature on
>a document may be contested at any time following creation,
>one should realise the impact of the above paraphrased formalism.
>
>For authentication protocols, its the syncrhonization of clocks
>at sender and receiver which matters. For legal purposes, the
>argument about periodicity is quite different, as legal time has a fixed 
point,
>namely the judges watch. A plaintiff has to make cliams wrt that point,
>adn here is where things start to break down, in the credibility of the
>claim of  validity of a cert in the next/last century.
>
>All I can really say is that if you use a VeriSign certificate to validate
>a digital signature, you are obligated to rely upon that cerificate only
>while it is valid. (you may note the use of while, not "when".) The 
longevity
>of a digital signature can be ensured through notarial practices.
>
>As with any signed document, a careful party will store a copy of
>the writing forever, unless the signature or content limits its period
>of validity. the ability to show that a document with the same signature
>existed 100 years ago may well be disasterous for your case;
>all one needs is to show someone (anyone, just one!)  during the previous
>century made a verification of that signature which conformed to
>the prevailing prctices governing use of the reliance instruments.
>
>A party which seeks to pretend that the period of validity relates to a 
date in
>a century other than which the CA issued it will have to explain why the
>VeriSign serial numbers are so small, indicating an ancient
>cert. Where VeriSign masks serialNumbers, its heirs and successors
>will no doubt be willing to give to the court, in camera, the data and 
method
>of proving the monotonicity, for such a special-case claim.
>
>Those CAs today using PCMCIA devices or other devices not
>designed for trustworthy cert issuing may struggle to support
>their clients using digital signatures to sign/authenticate documents, 
when
>it comes down to the wire on the subtler issues of dig sig
>security (versus mere risk management, crypto and key protection!)
>A Fortezza card is really not suitable for commercial notarys or
>commercial CAs, without support from other trusted design/devices. A 
pocket-size
>PCMCIA RSA card without emanations security may not be suitable whatsoever
>for such purposes!
>
>Seriously, if a relying party seeks to use a cert to contest a digital
>signature without ensuring the cert is valid, it is not acting in a 
(commercially)
>reasonable manner, claim I. A damaged relying party claiming validity will 
have
>to explain to the court how it ascertained that validity - it having 
(apparently)
>
>the burden of proof. I would ask, as a mock-attorney, when, sir, did you
>first obtain the digtially-signed document, and what reasonable steps did 
you use
>to confirm its validity before relying on it?
>
>Ask yourself how many overlaying/overlapping controls exist in the 
VeriSign
>CPS to control this reasonable reliance on a technology. E.g. a digital 
signature
>may
>only be created during the operation period of a cert. E.g. the relying 
party
>must determine no cert in the chain is revoked/suspended. E.G. for
>use in non-repudiation services, the data to be digitally signed must 
include
>time and date (legal terms, not ISO terms) (A PKCS7 signingTime
>attribute in the signature block will NOT suffice!) E.G. the reliance is 
reasonable
>under the circumstances...relying party ...additional assurnaces... must 
obtain
>...
>to be reasonable E.G. relying party has complied with all requirements of 
[] CPS.
>
>Read the VeriSign CPS carefully for a description of a system
>for digital signatures relying upon certificates (X.509 technology for
>the moment; SPKI and Ron Rivest's SDSI certs next, perhaps)
>
>Ask for the CA's Certifcation Practice Statement (CPS), before you
>buy a certificate or procure any service involving digital signatures! 
Ensure
>the CA company is willing to be legally bound to it!
>
>Peter.
>
>
>

From: Peter Williams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Mark Bartel'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: X.509 validity period
Date: Mon, 7 Oct 1996 17:14:04 -0700

Mark,

"Validity" - or, as I put it, "the name of the game".You say:

"Another argument is that certificates are not useful outside of their 
validity dates.  This is incorrect.  As I understand it, the validity dates 
of a certificate define the period for which the binding between the 
subject name and public key is valid, not the validity of the certificate 
itself.  They also force people to renew their certificates and therefore 
(usually) their keys, but this is merely a useful side-effect.  The fact 
that a person signed that document, even though it was ten years ago, could 
still be very important."

Depends on how you define purpose and use as to what valdiity mean, say I.

VeriSign defined it, in paraphrase, as
you cannot rely upon the certificate unless the certificate is valid. Validity 
is defined in the technical standard as a period, and that is expressed
using notBefore/notAfter universal times. It also says the signer
may not create digital signature outside the operational period
of the cert. (In better software, we can use v3 std extensions
to enforce this; v3 std extensions even have disclaimed and juicy
GeneralizedTime fields for just such a judicious control purpose!)

As this whole thread started on the basis that a signature on
a document may be contested at any time following creation,
one should realise the impact of the above paraphrased formalism.

For authentication protocols, its the syncrhonization of clocks
at sender and receiver which matters. For legal purposes, the
argument about periodicity is quite different, as legal time has a fixed point,
namely the judges watch. A plaintiff has to make cliams wrt that point,
adn here is where things start to break down, in the credibility of the 
claim of  validity of a cert in the next/last century.

All I can really say is that if you use a VeriSign certificate to validate
a digital signature, you are obligated to rely upon that cerificate only
while it is valid. (you may note the use of while, not "when".) The longevity
of a digital signature can be ensured through notarial practices.

As with any signed document, a careful party will store a copy of 
the writing forever, unless the signature or content limits its period
of validity. the ability to show that a document with the same signature
existed 100 years ago may well be disasterous for your case;
all one needs is to show someone (anyone, just one!)  during the previous
century made a verification of that signature which conformed to
the prevailing prctices governing use of the reliance instruments.

A party which seeks to pretend that the period of validity relates to a date in
a century other than which the CA issued it will have to explain why the
VeriSign serial numbers are so small, indicating an ancient
cert. Where VeriSign masks serialNumbers, its heirs and successors
will no doubt be willing to give to the court, in camera, the data and method
of proving the monotonicity, for such a special-case claim.

Those CAs today using PCMCIA devices or other devices not
designed for trustworthy cert issuing may struggle to support
their clients using digital signatures to sign/authenticate documents, when
it comes down to the wire on the subtler issues of dig sig
security (versus mere risk management, crypto and key protection!)
A Fortezza card is really not suitable for commercial notarys or
commercial CAs, without support from other trusted design/devices. A pocket-size
PCMCIA RSA card without emanations security may not be suitable whatsoever
for such purposes!

Seriously, if a relying party seeks to use a cert to contest a digital
signature without ensuring the cert is valid, it is not acting in a (commercially)
reasonable manner, claim I. A damaged relying party claiming validity will have
to explain to the court how it ascertained that validity - it having (apparently) 
the burden of proof. I would ask, as a mock-attorney, when, sir, did you
first obtain the digtially-signed document, and what reasonable steps did you use
to confirm its validity before relying on it?

Ask yourself how many overlaying/overlapping controls exist in the VeriSign
CPS to control this reasonable reliance on a technology. E.g. a digital signature may
only be created during the operation period of a cert. E.g. the relying party
must determine no cert in the chain is revoked/suspended. E.G. for
use in non-repudiation services, the data to be digitally signed must include
time and date (legal terms, not ISO terms) (A PKCS7 signingTime
attribute in the signature block will NOT suffice!) E.G. the reliance is reasonable
under the circumstances...relying party ...additional assurnaces... must obtain ...
to be reasonable E.G. relying party has complied with all requirements of [] CPS.
 
Read the VeriSign CPS carefully for a description of a system
for digital signatures relying upon certificates (X.509 technology for
the moment; SPKI and Ron Rivest's SDSI certs next, perhaps)

Ask for the CA's Certifcation Practice Statement (CPS), before you
buy a certificate or procure any service involving digital signatures! Ensure
the CA company is willing to be legally bound to it! 

Peter.

Date: Mon, 7 Oct 1996 15:30:45 -0700
From: [email-masked] (Jan Luehe)
To: [email-masked]
Subject: OIDs for exportable algorithms

Hi there:

Does anybody know if special object identifiers have
been defined for encryption algorithms with a fixed
key size (e.g., DES-CBC), when used in export mode
(e.g., DES40_CBC)?

If no such object identifiers exist, how can two sites
using different versions of the same software package
(one domestic, one export) communicate with each other?

This is not a problem where the encryption keysize is
specified by a cipher suite identifier which can be negotiated
between the two communicating parties as part of a protocol
(e.g., SSL).
This is also not a problem where one site wraps the encryption
key in a digital envelope.

However, this becomes a problem if both parties establish the
encryption key independently, e.g., through password-based
encryption, and the party using the exportable version of the
software truncates the encryption key to say 40 bits.

Since the definition of DES does not provide for 
a key size parameter, how can a decrypting party
determine the (potentially truncated) key size that was
used by the encrypting party, other than through some out-of-band
mechanism?

So my question again: Is there a special AID for something
like DES40_CBC?

Thanks,

Jan Luehe
Sun Microsystems

From: Mark Bartel <[email-masked]>
Subject: Re: X.509 validity period
To: [email-masked] (Miklos Sue A.)
Date: Mon, 7 Oct 1996 13:38:31 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

> I would be happy to bring the defect report into our next ISO editing 
> meeting... I have also cc'd Bancroft Scott on this, as I had anticipated 
> some DER representation of UTCTime, which is another potential time-related 
> problem... I certainly don't expect the discussion to gravitate onto any 
> other tangents.  If anyone has objections to a defect report, or suggestions 
> other than Warwick's, please send them to me.  [email-masked]
> Sandi

Warwick's solution adds significant complexity to validity checking.

My preference would be to redefine Validity:

Validity ::= SEQUENCE {
    notBefore     CertificateValidityDate,
    notAfter      CertificateValidityDate }

CertificateValidityDate ::= CHOICE {
    utcTime       UTCTime,
    generalTime   GeneralizedTime }

Additionally, specify that UTCTime should be used for both if notAfter
is before the year 2000, otherwise GeneralizedTime should be used (for
both).  Also specify that generalTime must be specified in coordinated
universal time (ie. no local time!).

I think this solution has the advantage of maintaining compatibility
for certificates in the short term without adding a lot of complexity
in the long term.

Mark Bartel ([email-masked])

>  ----------
> From: pki-twg-request
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: X.509 validity period
> Date: Monday, October 07, 1996 4:45AM
> 
> This thread seems to be drifting seriously.  With a view to returning it to
> track and hopefully concluding it, following is a suggested "fix" for X.509
> for those who are really concerned about 4-digit years.  The attraction of
> this fix is that few implementors will need to do anything for a long time.
> Whether such a fix is warranted is an open question; someone who feels
> strongly enough should raise a defect report.
> 
> Warwick
>  ----------------
> 
> Validity Century Extension
> 
> validityCentury EXTENSION ::= {
>   SYNTAX   ValidityCenturySyntax
>   IDENTIFIED BY { id-ce ? }}
> 
> ValidityCenturySyntax ::= SEQUENCE {
>   notBeforeCentury  [0] INTEGER OPTIONAL,
>   notAfterCentury   [1] INTEGER OPTIONAL }
> 
> The values of notBeforeCentury and notAfterCentury give the century figures
> to be prefixed to the year fields in the nonBefore and notAfter components
> of the certificate validity field.  If the notBeforeCentury or
> notAfterCentury field is omitted or the validityCentury extension is absent,
> the century figures default to 19 for a year value in the range 88 to 99,
> and 20 for a year value in the range 00 to 87.  This extension shall be
> flagged noncritical if both default values are indicated or critical
> otherwise.
>  -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
>  -------------------------------------------------------------------
> 
> 

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, pki-twg-request <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "'Bancroft Scott'" <[email-masked]>
Subject: RE: X.509 validity period
Date: Sat, 05 Oct 96 09:52:00 EDT
Encoding: 48 TEXT

I would be happy to bring the defect report into our next ISO editing 
meeting... I have also cc'd Bancroft Scott on this, as I had anticipated 
some DER representation of UTCTime, which is another potential time-related 
problem... I certainly don't expect the discussion to gravitate onto any 
other tangents.  If anyone has objections to a defect report, or suggestions 
other than Warwick's, please send them to me.  [email-masked]
Sandi
 ----------
From: pki-twg-request
To: [email-masked]; [email-masked]; 
[email-masked]
Subject: RE: X.509 validity period
Date: Monday, October 07, 1996 4:45AM

This thread seems to be drifting seriously.  With a view to returning it to
track and hopefully concluding it, following is a suggested "fix" for X.509
for those who are really concerned about 4-digit years.  The attraction of
this fix is that few implementors will need to do anything for a long time.
Whether such a fix is warranted is an open question; someone who feels
strongly enough should raise a defect report.

Warwick
 ----------------

Validity Century Extension

validityCentury EXTENSION ::= {
  SYNTAX   ValidityCenturySyntax
  IDENTIFIED BY { id-ce ? }}

ValidityCenturySyntax ::= SEQUENCE {
  notBeforeCentury  [0] INTEGER OPTIONAL,
  notAfterCentury   [1] INTEGER OPTIONAL }

The values of notBeforeCentury and notAfterCentury give the century figures
to be prefixed to the year fields in the nonBefore and notAfter components
of the certificate validity field.  If the notBeforeCentury or
notAfterCentury field is omitted or the validityCentury extension is absent,
the century figures default to 19 for a year value in the range 88 to 99,
and 20 for a year value in the range 00 to 87.  This extension shall be
flagged noncritical if both default values are indicated or critical
otherwise.
 -------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
 -------------------------------------------------------------------

Date: Mon, 07 Oct 1996 04:45:57 -0700
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: RE: X.509 validity period

This thread seems to be drifting seriously.  With a view to returning it to
track and hopefully concluding it, following is a suggested "fix" for X.509
for those who are really concerned about 4-digit years.  The attraction of
this fix is that few implementors will need to do anything for a long time.
Whether such a fix is warranted is an open question; someone who feels
strongly enough should raise a defect report.

Warwick
----------------

Validity Century Extension

validityCentury EXTENSION ::= {
  SYNTAX   ValidityCenturySyntax
  IDENTIFIED BY { id-ce ? }}

ValidityCenturySyntax ::= SEQUENCE {
  notBeforeCentury  [0] INTEGER OPTIONAL,
  notAfterCentury   [1] INTEGER OPTIONAL }

The values of notBeforeCentury and notAfterCentury give the century figures
to be prefixed to the year fields in the nonBefore and notAfter components
of the certificate validity field.  If the notBeforeCentury or
notAfterCentury field is omitted or the validityCentury extension is absent,
the century figures default to 19 for a year value in the range 88 to 99,
and 20 for a year value in the range 00 to 87.  This extension shall be
flagged noncritical if both default values are indicated or critical otherwise. 
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

From: Nick Pope <[email-masked]>
To: Peter Williams <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Warwick Ford <[email-masked]>, "'Nick Pope'" <[email-masked]>, Peter Williams <[email-masked]>
Date: Mon, 7 Oct 1996 11:15:14 +0000
Subject: RE: X.509 validity period
Priority: normal

In reply to message of  4 Oct 96, 10:47 from Peter Williams:

Peter,

Do we have a technical reason for not using Generalised time in the 
validity period?

 In checking again with ASN.1 I read that generalised 
time can be local or coordinated universal time.  For use in the 
validity period obviously localised time is not appropriate.
Either we have to restict use of Generalised Time or stay with UTCT.

Are you of the opinion that generalised time cannot be used because it 
is not restricted to Universal time?

> 
> UTCTime is a complete time rule. GenralisedTime is not; it can
> be though. Simply replacing GeneralizedTime for UTCTime changes
> the nature of the real-time strong authentication semantics in X.509,
> as the nature of time sources is altered.
> 
> This is quite a responable proposal, and responds to the underlying
> argument that there is a need for non-real time validation of certs in
> 50 years time, when supporting proof of origin with NR security
> services in a messaging environment.
> 
> This time thing is about more than 2 versus 4 digit year
> representation. Actual Cellular use of X.509 services already relies
> upon the UTCness properties already standardised by ISO for 10 years.
> 
> The real issue is about eliminating a standard rule for time handling
> in preference to one needed by messaging apps. A competent standard
> group would allow for both obvious models to support maximally the
> number of enviornments in which the syntax can be used, without
> ambiguity.
> 
> Peter.
> 
> 
> 
> 
> ----------
> From: 	Nick Pope
> Sent: 	Friday, October 04, 1996 2:30 AM
> To: 	Nick Pope; [email-masked];
> [email-masked]; [email-masked]; Warwick Ford
> Subject: 	Re: X.509 validity period
> 
> In reply to your message of  3 Oct 96, 13:12:
> 
> With the way that X.509 is becoming the basis for many of the security
> protocols being used today I believe that there is a good chance that
> X.509 (or its decendent) will be around in 2087.  Whilst solutions
> like SET are likely to be superceded with new payment technology, in
> all probability it will still be in use.  Payment by a Check book (is
> the same word used in American?) is still widely used even though
> there are more covenient methods around.
> 
> Is it worth a small amount of pain now than causing confusion later
> next century with the need to re-do all certificate management
> software that may be around in the world by then (could be every
> personal computer, networking service and banking system).
> 
> Nick
> 
> > I agree with [email-masked].  We simply write into the
> > PKIX spec (or X.509 itself) that any year in the range 00 through 87
> > means 20xx rather than 19xx.  This will keep X.509 dates working
> > until year 2087.  The idea of certificates being valid for 50 years
> > is just not in line with technology expectations - what
> > cryptographer is confident that any of the technologies we are
> > currently using will still be cryptographically sound in 50 years?
> > 
> > More pointedly, does anyone out there really think X.509 will still
> > be in use in year 2087?
> > 
> > Warwick
> > 
> > 
> > At 10:21 AM 10/2/96 +0000, Nick Pope wrote:
> > >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?
> > -------------------------------------------------------------------
> > Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
> >    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> > -------------------------------------------------------------------
> > 
> 
> -------------------------------------
> 
> 
> Security & Standards
> Suite A
> 191 Moulsham St.
> Chelmsford
> Essex
> CM2 0LG
> U.K.
> 
> Tel: +44 1245 495018
> Fax: +44 1245 494517
> 
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: X.509 validity period
Date: Mon, 7 Oct 1996 00:34:20 -0400
Encoding: 144 TEXT

It seems that there are lots of arguments flying about the 2-digit years 
problem.  The major arguments against changing from 2 digit years are all 
in the "X.509 will be obsolete" category, with the following subarguments:

1)  Nothing lasts that long in the computer industry
2)  Nobody will care about 1990s data in 2090
3)  The authentication provided by current certificates will be void in 100 
years

====

1)  Nothing lasts that long in the computer industry.

How about ASCII?  It's still around, and it's being perpetuated in ISO 
10646 which tries to fix the problems, but there are still ambiguities. 
 ISO 10646 is supposed to adhere to the one character, one code point rule 
but there are duplications to keep ASCII compatibility.

You might say that ASCII is *much* more basic to computing than 
certificates.  Yes, right now that is true, but I think (I hope!) that as 
computers become more ubiquitous, then authentication will become as basic 
to future software as ASCII is now.  X.509 might have evolved by 2087, but 
I don't think it unreasonable to think it might still be around in much the 
same form.  The extensions mechanism allows it to respond to changing needs 
without sacrificing compatibility.  This last will become more and more 
important as *everything* becomes computerized, and therefore standards 
will be *much* harder (and expensive!) to change.

I can think of lots of other examples of *old* standards that are still 
around.  The software that my company makes, for example, has a "job card" 
field in one of the files that it generates.  Anybody care to guess the 
origin of it?  Since there was no reason to change the contents of that 
field, it was never changed, and so retained backwards compatibility and 
minimized the need to rewrite code.

I think that last example also responds to the "nobody will be able to read 
3.5" floppies in 2087 anyway" argument.  The job card field has nothing to 
do with punch cards anymore.  I have files on this machine that came from 
the Commodore 64 I used in the early 1980s.  Data that is important will 
get migrated up as technology changes.  Most people are aware of the media 
obsolescence problem and deal with it.

Peter Williams said it would be "arrogant" to presume that the standard 
will be used in 100 years.  I wouldn't presume to say that it *will* be 
used in 100 years, but I don't think it is appropriate for a *standard* to 
have obsolescence built in (except perhaps in peculiar circumstances which 
don't apply to X.509).

Just because software often changes every year (ie. MS and Netscape), 
doesn't mean it always has to, or that the underlying standards must 
change.  Think about ASCII, which is still used in even the latest web 
browsers.  Think about the Unix password system, which has several standard 
forms, the original form (well, the passwd file with multiple DES 
encryption form) still being used in many systems.  And both of these 
"standards" came from an era when proprietary systems were the norm. 
 Standards are now more standard and are getting more so.  (Now that was an 
intriguing sentence.)

I would hope that in 2087 most programmers have no need to worry about 
security because the standard pieces have been around for so long, kind of 
like ASCII except better because we actually thought about the future and 
didn't do the gain-now, pain-later thing.

2)  Nobody will care about 1990s data in 2090.

As computers "take over," more and more of our ordinary life is going to be 
data on computers.  Birth certificates, citizenship records, medical 
records, school records, etc, etc.  Not to mention all the data that I 
personally have collected and want to be secure.  I might not be alive in 
2090, but my children might be and this data (medical data, for example) 
might be important for them.

3)  The authentication provided by current certificates will be void in 100 
years

Another argument is that certificates are not useful outside of their 
validity dates.  This is incorrect.  As I understand it, the validity dates 
of a certificate define the period for which the binding between the 
subject name and public key is valid, not the validity of the certificate 
itself.  They also force people to renew their certificates and therefore 
(usually) their keys, but this is merely a useful side-effect.  The fact 
that a person signed that document, even though it was ten years ago, could 
still be very important.

A related argument is that cryptographic advances will render any 1990s 
certificates invalid.  First of all, for long-term data one can use really 
long keys.  Second, the recommendations about when key sizes will be 
insufficient is based on optimistic predictions of both technological and 
mathematical advances.  If *either* fail to continue at the current rate, I 
suspect key lengths of 2048 bits (what I'm building into my current 
product) will still be secure.  And so 100-year old signatures might still 
be valid in a court of law.

There is a need to distinguish between predictions for security purposes, 
which have to assume the worst, and for standards purposes, which should be 
optimistic about life-span.  I'm not presumptious enough to think that 
people will want to verify signatures created by my product a hundred years 
from now; I'm using long keys to *ensure* that the signatures are secure 
five years from now.  But I think it's entirely reasonable to think that 
these signature will *probably* be secure 100 years from now.

Some arguments have talked about "current methods" being invalid at that 
time.  Well, since you can use whatever algorithm you like, I don't see 
this as particularly being an issue.  In the future, when RSA and DSA are 
proven insecure, maybe we'll all be using elliptic cryptosystems or 
something like that.  Maybe there'll be an easy way of breaking any type of 
message digest, so we'll have to encrypt entire messages for signatures. 
 X.509 can adjust to all of that (although people might have to re-sign old 
data).

====

Other comments:

Even if it were known that X.509 would be obsolete in 10 years, it is still 
a pain to have to do the "if (year > 87)" check.  You can't do string 
compares, you actually have to parse the date.  Yes, it is a trivial bit of 
code but it is an *unnecessary* trivial bit of code.  In software it is 
annoying, in hardware it might even make a product more expensive.

I'd rather not "fluff up" the certificate by putting a validity period with 
a GeneralizedTime in the extensions and retaining the UTCTime validity 
period.  As well as inflating the certificates, it makes them more complex 
to validate.  I like the CHOICE option, personally.  But the extension 
solution is better than no solution.

Peter Williams said something about the "UTC-ness" of the time being 
important.  I'm not sure I understand this argument.  I certainly think 
that we should require the GeneralizedTime to be specified in coordinated 
universal time (ie. in the form with the "Z" on the end), otherwise the 
validity is ambiguous.  I don't see how having an extra two digits in the 
year affects anything.

The time is *NOW*!  The best time to change this is immediately, before 
many certificates are issued.  I believe that even Netscape's CA 
certificate expires before 2000 (I think it's Dec 31, 1999, at 23:59:59). 
 If the change occurred immediately, we could avoid having to do the "> 87" 
comparison on old certificates.

The very fact that Netscape's certificate expires when it does implies that 
they might have thought of this problem already, and be prepared to change 
the software.  I know I'm going to define my certificates to take a CHOICE.

- Mark Bartel ([email-masked])

From: "Hoffman, Mort" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: RE(2): X.509 validity period
Date: Fri, 4 Oct 1996 12:22:57 -0400
Encoding: 70 TEXT

There are techniques for archiving old messages and certificates either
in physical vaults or under new signatures (possibly with newer/stronger
algorithms) so that you can then prove that the certificate was
generated at the time or archiving, which is hopefully before the
algorithm on the certificate was broken.  Thus the dates of these old
certificates are validated by the newer ones.  While this may provide a
mechanism to help determine the era of the original certificate (before
archiving), that may not be sufficient to determine the real date, and
even when it is, I'd hate to have to write the code.

Old certificates never die, they get archived.

>----------
>From:
>	[email-masked][SMTP:[email-masked]]
>Sent: 	Friday, October 04, 1996 2:50 AM
>To: 	[email-masked]
>Subject: 	RE(2): X.509 validity period
>
>
>
>
>
>
>
>         I wish I could understand this argument. 
>         
>         I don't see how a certificate can last longer than its ability 
>         to withstand attack. Are we not working on the 
>         basis that crypto technology will have advanced sufficiently
>         by the year 20-whatever-it-is that a 1996 certificate could be 
>         forged at will? If this is the case, aren't such old certificates 
>         worth no more than the floppy they are written on? If my great 
>         grandson wants to prove that Warwick signed a promissory note 
>         for a million dollars in 1995 (you *do* remember doing that don't 
>         you Warwick?) all he needs to do is create a false old certificate 
>         and a falsely signed note. Perhaps one way of focusing the mind
>         on the difficulties is to imagine trying to protect from a
>         cryptographer of today an ancient Roman "signed" document 
>         signed (well, sealed - it's the best they could have done)
>         using a Caesar cipher.
>         
>         So over the years certificates will be devalued according to the
>         ease with which they can be forged. Perhaps one way of prolonging
>         their life is to "refresh" them with stronger technology, by 
>         signing the certificate inside another certificate at intermediate 
>         points. The logic would then be: at a time at which the
>         certificate could not be broken, an authority I trust has
>         reinforced it, at a subsequent time before the first authority's
>         certificate could not be broken, a second authority I trust has
>         further reinforced that reinforced certificate ...etc..). Sounds
>         a bit heavy though!
>         
>         Regards,
>         Tom Parker
>         4th October 1996
>         -----------------------------------------------------------------
>         Tom Parker, Security Architect, ICL Fellow.
>           
>         Tel:      +44.1344.472169        The Solution Centre
>         Fax:      +44.1249.822703        ICL Enterprise Technology
>         Mobile:   +44.385.551826         Lovelace Road,
>         Home Tel: +44.1249.814762        Bracknell RG12 8SN
>                                          UK
>         
>         email:    t.a.parker(a)win0199.wins.icl.co.uk
>         -----------------------------------------------------------------
>
>
>

From: Peter Williams <[email-masked]>
To: "'Mark Bartel'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: X.509 validity period
Date: Fri, 4 Oct 1996 16:45:24 -0700

Mark,

Why not throw away X.509, and just start again. Im convinced that
a signed java class is far more effective a tool for the
role which certs play, then any syntax. For all it matters,
it can be a signed DLL (activeX control) on windows, just the same,
to get faster (and safer!) execution.

What really matters in X.509 is the collected wisdom
of the Authentication Model, not the stupid syntax.

All the control systems elements we now understand as necessary
for operating  a sizable and flexible PKI with lots of CA =
application-driving
policies, can be expressed programmatically=20
with a signed java class, instead of as signed cert syntax +
extensions.

This idea is now doable with current technology. Netsacpe now
allow servers access to the client https cert at the CGI level. Until
we dump X.509, it can contain a java class (activeX control) as an =
extension,
which the CGI server logic executes to do the real work of end-end =
authentication
and control. =20

At the MS schannel winwock level, the cert handling is completely =
unspecified
as to syntax and handling. Winsock SSL just transfers bytes end-end. In =
that enviornment
one can transfer the signed java class directly between peers, and =
ignore the=20
X.509 wrapper need.

Looking at the role which oleisapi2.dll plays in IIS server, such that =
any
web client can remotely activate OLE servers, the ability to
transfer to the OLE stub-proxy server the specialised =
code/control-system (i.e.=20
the executable client cert/java class) you want it to use to override =
the handling
requirements, is a very useful feature!.

We are really no longer limited to any static description. If we
are not going to confom to the process of IETF/ISO standards, then lets =
not
fiddle, just upgrade now to modern computing.

Peter.

----------
From: 	Mark Bartel
Sent: 	Friday, October 04, 1996 9:52 AM
To: 	Nick Pope
Cc: 	[email-masked]; [email-masked]; =
[email-masked]; [email-masked]; =
[email-masked]; [email-masked]
Subject: 	Re: X.509 validity period

> With the way that X.509 is becoming the basis for many of the security
> protocols being used today I believe that there is a good chance that
> X.509 (or its decendent) will be around in 2087.  Whilst solutions =
like
> SET are likely to be superceded with new payment technology, in all
> probability it will still be in use.  Payment by a Check book (is the
> same word used in American?) is still widely used even though there =
are
> more covenient methods around.

I agree.  I keep thinking of all the programmers who figured 20 years
ago that their systems would no longer be in use by the year 2000.
And *that's* just specific implementations, not a *standard*.  I
believe that if X.509 is widely accepted 10 years from now, it (or a
descendent) could just as easily still be in common use 100 years from
now.  As more and more things are computerized, changing a standard is
going to become more and more difficult, instrusive, and expensive,
especially something like authentication which can usefully be used in
pretty much anything.

> Is it worth a small amount of pain now than causing confusion later=20
> next century with the need to re-do all certificate management=20
> software that may be around in the world by then (could be every=20
> personal computer, networking service and banking system).

YES!  I do *not* think it is reasonable to limit a standard because it
*might* be superseded.  If you don't build limitations into it, it
might not be.  If you do build limitations into it, it will *have* to
be.  Think of how nice it would be to have standards which *ARE*
standard, and don't keep changing every few years.

> > I agree with [email-masked].  We simply write into the =
PKIX
> > spec (or X.509 itself) that any year in the range 00 through 87 =
means
> > 20xx rather than 19xx.  This will keep X.509 dates working until =
year
> > 2087.  The idea of certificates being valid for 50 years is just not
> > in line with technology expectations - what cryptographer is =
confident
> > that any of the technologies we are currently using will still be
> > cryptographically sound in 50 years?

First, just because low confidence is assigned to the validity of the
signature doesn't mean that it won't be useful to check it anyway.
And second, the estimation that current key lengths will be inadequate
is based on the assumption that (a) factoring algorithms will continue
to improve and (b) that the current rate of improvement in hardware
will continue.  These assumptions are reasonable from a security
standpoint, where one must be pessimistic, but who knows?  A 1536 bit
key length may be just as unbreakable in 2097 as it is now, and I'm
using a length of 2040 bits currently (excessive, probably).  Remember
that this is not a linear function; the difference in power required
to break 1024 bit keys vs 768 bit keys is *much* smaller than the
difference between 1280 vs 1024.  And just because the certificate has
expired doesn't mean that you wouldn't want to verify it anyway
(someone else has talked about what validity dates really mean).

- Mark Bartel ([email-masked])

PS.  There are major industry analysts (not all of them, but some)
that predict that at *least* one *major* company will go out of
business just because of the year 2000 problem.  I don't remember the
reference; if anybody cares I will try to find it.  I'd rather not see
the same thinking that caused that problem be perpetuated in X.509.

Date: Fri, 04 Oct 1996 18:10:23 -0400
To: [email-masked], [email-masked], [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: Re[2]: X.509 validity period

There is no problem with extensions.  All current extensions that specify
times use GeneralizedTime.  The only problem is with the validity period in
the base certificate, which cannot be changed without a new certificate
format.  We could define a new "validityPeriod" extension that uses
GeneralizedTime and that is defined to override the period in the base
certificate.  However, seeing as we have until around 2067 (20 years or so
before 2087) to solve this problem, I don't think we need rush to do
something like that yet.  (Like, it may be easier to fix it in the X.5000
directory recommendations, when ASN.6 comes into use, or when we migrate to
biological certificates.)

Warwick

At 12:36 PM 10/3/96 MST, [email-masked] wrote:
>i believe we should get away from two digits years. we had a discussion in
>previous directory defect meetings and proposed doing a wrap around also. this
>is a acceptable bandage but we should fix the problem.
>
>to handle backward compatability we could define additional extensions that
>duplicate the extensions that use utc time but replace the utc time with
>generalizedtime. we could allow the extensions to co-exist for a period but
>after that period deprecate the use of the earlier extensions. if we don't
>change the semantics of the earlier extension, we could accomplish this by
>defect.
>
>note that the rules of extensibility should allow extension to a choice (adding
>to a choice or creating a choice) only if the original field was optional.
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

From: Peter Williams <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 validity period  -Reply -Reply
Date: Fri, 4 Oct 1996 13:59:05 -0700

Bob,

We are very much in agreement on most topics; as weve done it for years.

A whole new bunch of people are at the table today, who dont care; they
just want to make money. There are no sacred cows in the money markets.

One has to realize that certs have broken through the magical barrier. I
personally regard X.509 as a throw-away, today; and will remember it
for that +ve reason. The nature of US capitalism is
that it WILL be replaced, "because" (of nothing). An enormous amount
of pomp will be used to bluster that there is cause. But, the real
purpose of standards is to make markets, not constrain technology.

I fully predict the next 9 format for certs will contain all the same base
information, and the vast majority will be list based encodings. The
nature of a cert is like that of a name - the more you try to
stnadardize it, the more dissent you generate. I think the SPKI
grouop already have 13 types, to which you add the 5 from PGP...

What really matters is not the encoding (or even the syntax) but
what reliance people make on it. And there, CAs like notarial lawyers will
have a long useful life in commerce and dispute situations.

Changing from one format to another is a minor piece of programming.
The value third parties have is their understanding, not their ability
to program. The role of third-parties changes, as technology
reduces risks.

Now that Microsoft has released an X.509 toolkit "build-a cert-server"
product to the world, what would you expect Netscape to do
except do the opposite! If they dont, they go out of existance
in a year; if they compete head-to-head with Microsoft
they lose; if they constantly fiddle the playing field, they
can be faster and smarter - perhaps! 

The aliiance against X.509 is really just an alliance
against Microsoft. I would NOT hold Microsoft to X.509 given
those kind of rules! What I do know is that having
got their vendors to make cert-servers, the nature
of windows technology is that at the flip
of a DLL, the serialized format is changed...At the subclass
of the object, an extra field is added... So I dont think
Netsacpe and co will really win very much, here.

Software (signed or otherwsie) is just information. Information
age requires one to change constantly, else
get eliminated. its a very Maoist notion; good job
I lived in Bolivia for a bit to prepare! 

I think We came close to giving users a legal-grade digital signature
services; but again, like 5 years ago, I suspect we have actually failed. 

Peter.

----------
From: 	Bob Jueneman
Sent: 	Friday, October 04, 1996 9:11 AM
To: 	[email-masked]
Cc: 	[email-masked]
Subject: 	RE: X.509 validity period  -Reply -Reply

Peter,

I don't disagree with anything you've said. Sometime we become so enamored with 
the technical "what is possible" that we lose sight of the "what is needed."

I was just trying to shed a little light on the topic of nonrepudiation, which I have
found difficult to explain to people in a reasonable and balanced way. Typically, 
they don't understand the notion at all, and then once they begin to understand,
they tend to go whole hog and want very long certificate validity periods, notarized time-
stamps, archive everything, etc. As you point out, that may be necessary for
a small percentage of all transactions, but certainly not the majority.

If I really thought I had a 50 year retention requirement, the first problem that I would worry
about would be long-term media compatibility problem. I've got lots of standard 5-1/4"
floppies I can no longer read (for lack of a reader on my current computer), to say 
nothing of some of the quad-density and other odd formats I have lying around.
(Of course one way of dating a document is to date the media on which it is written -- 
its not very likely that anyone could record a song on a wax cylinder today, for
example.)

So one solution would be to contract with a specialist in archiving records -- someone 
who would guarantee to periodically reread the media on which the information was
recorded to ensure it is still intact, and to rerecorded it in whatever new formats come
along, timestamping it and wrapping it in their own digital signature format with
ever-increasing key lengths. And you'd better make sure that the archive company
itself will be an enduring institution, and is guaranteed to be adequately funded in 
perpetuity. The Library of Congress and the Catholic church come to mind, but both are
short of funds. The Mormons are probably better record keepers, but they've only been
around for 100+ years, so they don't have a proven track record yet. Maybe a Buddhist
monastery, if you don't mind schlepping all your records to Tibet. (I can see the IBM
ThinkPad advertisement already, if they only had a place to recharge the batteries.)

Or there is a much simpler solution, one that is both economical and time-proven. Print
the document in question on good acid-free rag paper (if you can find any), and include
a printed copy of the digital signature in hex. If good paper is used, the media should
survive 500 years or more, so the next question is the ink. I still have a Diablo 630 printer 
I'd be willing to sell cheap to anyone who needs one -- with a carbon ribbon and a metal
print wheel the impressions should last as long as the paper. 500 years from now, if
anyone still cares, the paper can be scanned in and reprinted. The digital signature
will be completely worthless except as an indicia of authorship, but the physical aging of he
paper itself will be very difficult to forge, and the message digest will protect against 
undetected corruption of the text.

Bob,

>>> Peter Williams <[email-masked]> 10/02/96 01:46pm >>>
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.

Forcing every internet mail to be signed, or when signed, it must be legally dated, is not
on. People should be able to send any quality of signed mail they
desire, not that which only suits lawyers or other legal needs.

Whats the problem? Is the std too flexible, for American freedoms, in allowing
choice and handling of risks at the individual's level?

Peter.

Date: Fri, 04 Oct 1996 14:26:52 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Subject: White House Statement on Encryption -Forwarded

I assume that probably half of the people on this list may have already heard about this,
but some may not -- particularly our non-US friends.

In any case the issues this will raise will be interesting, to say the least.

Bob

Content-Length: 5744
Date: Thu, 03 Oct 1996 06:44:20 -0600
From: Elaine Frye  <[email-masked]>
Subject: White House Statement on Encryption

                         THE WHITE HOUSE
                 Office of the Vice President

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

FOR IMMEDIATE RELEASE             CONTACT: 456-7035
TUESDAY, October 1, 1996

STATEMENT OF THE VICE PRESIDENT

President Clinton and I are committed to promoting the growth of electronic
commerce and robust, secure communications worldwide while protecting the
public safety and national security.  To that end, this Administration is
consulting with Congress, the information technology industry, state and
local law enforcement officials, and foreign governments on a major
initiative to liberalize export controls for commercial encryption products.

The Administration's initiative will make it easier for Americans to use
stronger encryption products -- whether at home or abroad -- to protect
their privacy, intellectual property and other valuable information.  It
will support the growth of electronic commerce, increase the security of the
global information, and sustain the economic competitiveness of U.S.
encryption product manufacturers during the transition to a key management
infrastructure.

Under this initiative, the export of 56-bit key length encryption products
will be permitted under a general license after one-time  review, and
contingent upon industry commitments to build and market future products
that support key recovery.  This policy will apply to hardware and software
products.  The relaxation of controls will last up to two years.

The Administration's initiative recognizes that an industry-led technology
strategy will expedite market acceptance of key recovery, and that the
ultimate solution must be market-driven.

Exporters of 56-bit DES or equivalent encryption products would make
commitments to develop and sell products that support the key recovery
system that I announced in July. That vision presumes that a trusted party
(in some cases internal to the user's organization) would recover the user's
confidentiality key for the user or for law enforcement officials acting
under proper authority.  Access to keys would be provided in accordance with
destination country policies and bilateral understandings.  No key length
limits or algorithm restrictions will apply to exported key recovery products.

Domestic use of key recovery will be voluntary, and any American will remain
free to use any encryption system domestically.

The temporary relaxation of controls is one part of a broader encryption
policy initiative designed to promote electronic information security and
public safety.  For export control purposes, commercial encryption products
will no longer be treated as munitions.  After consultation with Congress,
jurisdiction for commercial encryption controls will be transferred from the
State Department to the Commerce Department.  The Administration also will
seek legislation to facilitate commercial key recovery, including providing
penalties for improper release of keys, and protecting key recovery agents
against liability when they properly release a key.

As I announced in July, the Administration will continue to expand the
purchase of key recovery products for U.S. government use, promote key
recovery arrangements in bilateral and multilateral discussions, develop
federal cryptographic and key recovery standards, and stimulate the
development of innovative key recovery products and services.

Under the relaxation, six-month general export licenses will be issued after
one-time review, contingent on commitments from exporters to explicit
benchmarks and milestones for developing and incorporating key recovery
features into their products and services, and for building the supporting
infrastructure internationally.  Initial approval will be contingent on
firms providing a plan for implementing key recovery.  The plan will explain
in detail the steps the applicant will take to develop, produce, distribute,
and/or market encryption products with key recovery features.  The specific
commitments will depend on the applicant's line of business.

The government will renew the licenses for additional six-month periods if
milestones are met.  Two years from now, the export of 56-bit products that
do not support key recovery will no longer be permitted. Currently
exportable 40-bit mass market software products will continue to be
exportable.  We will continue to support financial institutions in their
efforts to assure the recovery of encrypted financial information. Longer
key lengths will continue to be approved for products dedicated to the
support of financial applications.

The Administration will use a formal mechanism to provide industry, users,
state and local law enforcement, and other private sector representatives
with the opportunity to advise on the future of key recovery.  Topics will
include: 

-     evaluating the developing global key recovery architecture 
-     assessing lessons-learned from key recovery implementation 
-     advising on technical confidence issues vis-a-vis access to
      and release of keys 
-     addressing interoperability and standards issues 
-     identifying other technical, policy, and program issues for
      governmental action. 

The Administration's initiative is broadly consistent with the recent
recommendations of the National Research Council.  It also addresses many of
the objectives of pending Congressional legislation.

*****************************************************
Elaine Frye
Computer Security Division
National Institute of Standards and Technology
Bldg. 820, M.S. Room 426
Gaithersburg, MD  20899-0001
Voice:   301/975-2819    Fax:  301/948-1233
*****************************************************

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Tom Zmudzinski'" <[email-masked]>
Subject: RE: Re[4]: X.509 validity period
Date: Fri, 4 Oct 1996 12:47:20 -0700

Tom,

Im getting over my head on this legal stuff, but I struggle to
believe that in 50 years a cipher technology and key of today will
ever have much weight in that time frame. Its just going
to be too easy for a protesting lawyer to sway the jury that
there is reasonable doubt. I doubt todays stuff in10 years time,
personally. But, I have masive amount of material to
protect with a useful shelf life of less than 1-2 years!

If the cipher's use is supproted by trusted notary procedures,
then there is a human link, and trust is based on conduct of
reasonable assurnaces. I expect human-based procedures
to be around for a long time, where long-range trust is required.

Bundling cipher-based technolgoy with human-notary procedures
(a service organized and paid for by those who might want to rely in 50
years time, without too much lawyering at that point) can extend
the longevity of the technology ad infinitum.

X.400 standard formalised the digital signature for messages
years ago. It then standardized the notion of a recipient
notarizing that message, if it wanted a legal basis for reliance
in the future when todays technology would no longer be 
innately credible to a reasonable jury.

The internet messaging security standards may just be about to
catch up, it seems!

AS the burden of proof is on the recipient, he or she better
get storing all the evidence now, for use later, and notarize
its confirmed validity NOW (with full timestamp!) Of course,
the notary timestamp is a full statement of linear time.

Apparently there are 400 million short term 2-digit year
credit cards out there. Seems to work, as most
of the tranactions are over with in the flash of a second,
or 90 days at most! If one wants to argue ones
credit-card bill in 50 years time in a law court, you better have
a notarized version of your VISA receipt, I suggest, as the
original ink will probably have faded by then! I doubt
its designed to last that long.

This is a fun time, and fun industry!
 
Peter.

.  ----------
From: 	Tom Zmudzinski
Sent: 	Friday, October 04, 1996 8:02 AM
To: 	[email-masked]
Subject: 	Re[4]: X.509 validity period

In the final lustrum [*] of the Twentieth Century (10/3/96 4:47 PM),  
Peter Williams <[email-masked]> opined:    

> Do you believe you will be able to find a media reader for the
> floppy in 50 years time?
>  
> Will the court still have a 3" floppy reader?
>
> Will the court be willing to believe a key used to perform "binding signature
> marks" 50 years still has the innate strength to so bind in the present,
> given cryptographic capability change?
  
  There's this little thing called "burden of proof".  If I, playing 
  Advocatus Diaboli for a moment, challenge an X.509 certificate in 2087 
  (actually, I have a much loftier goal: I want to be around for the Y10K 
  problem), the burden of proof is on me.  That means I would have to 
  have experts (possibly with gear borrowed from the Information Age 
  exhibit at the Smithsonian) prepared to present evidence of my claim.  
  (Or they might plug in a simulation from a 25 terabyte isolinear clip.)
  I suspect my rented liars (er, "experts") would do better going after 
  the "purity" of the certificate, that is, challenging its provenance.
  
> Will the court be willing to believe a key used to perform "binding signature
> marks" 50 years still has the innate strength to so bind in the present,
> given cryptographic capability change?
>
> Of course not. The key can assert integrity over the long term;
> direct accountability for the duration of reasonable reliance on the cert for
> name binding, and internal data from the signed message
> along with notarial conduct, for the rest.

  Thank you for supporting my position that "in use" depends upon one's 
  definition.  If one's definition of "in use" is "still using the same 
  hardware and software", the obvious answer is "no" as we're certainly 
  going to have better hardware and software in the future.  If it's "has 
  to stand up in a court of law", the answer is "yes".  You've provided 
  an example of how this might be accomplished without requiring X.509 
  to be bulletproof forever. 
  
  Quoting from _Cryptography's_Role_in_Securing_the_Information_Society_
  (page 2-5 of the 30 May draft, for all you fussbutts out there):
  
  ''First, the initial deployment of any technology often brings out 
    unanticipated problems, simply because the products and artifacts 
    embodying that technology have not had the benefit of successive 
    cycles of failure and repair.  Similarly, human procedures and 
    practices have not been tested against the demands of real-life 
    experience.  Cryptography is unlikely to be any different, and so 
    it is probable that early large-scale deployments of cryptography 
    will exhibit exploitable vulnerabilities.''
  
  [snip happens, even in the best of threads]
  
  v/r
  Tom Zmudzinski ..... [email-masked] ... (physically at:)
  (mail:) DISA Code D20A? ... (703) 681-0231 ... Skyline 5, Suite 9116
  701 S. Courthouse Road  ... (DSN) 761-0231 ... 5111 Leesburg Pike
  Arlington VA 22204-2199 ... (FAX) 681-0345 ... Falls Church VA 22041
  
  [*] For those of you who didn't look it up last time.  It means a 
      period of five years.  (It's currently 1996 and the XXth Century 
      ends at midnight, December 31st, 2000 ACE.  Tick, tick, ...)

Date: Fri, 04 Oct 1996 14:24:08 -0400
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: [email-masked] (Bill Burr)
Subject: Re: Re[2]: X.509 validity period & Roman Chariots

Hoyt Kesterson has given us a very entertaining story, about Imperial Roman
Mil-Spec Chariots being responsible for present railroad gauges, but at
least some of the details almost certainly aren't true. Now I don't doubt
that the width of the standard gauge railroad track is in some sense
descended from Roman roads, but Roman roads weren't built for chariots.
 
That is, by the time of the Roman Republic (and long before the Empire),
when the era of Roman conquest and road building began, they had long since
abandoned chariots as military vehicles, in favor of mounted cavalry
(actually they weren't very big on cavalry either until very late in the
Empire, it was the legions - infantry - that conquered the western world).
The Romans did use chariots for racing and ceremonial purposes, but their
heyday as military vehicles rather predated the Roman Empire.  If anyone
used chariots in Britain at the time of the Roman conquest, it was the
Britons themselves.

Nor was the horse the primary Roman draft animal.  The Romans didn't know to
make good harnesses for horses; the yokes they used cut off the air to a
horse when he pulled a heavy wagon.  The reality is that Romans depended on
oxen to haul heavy loads. So the truth of the matter is more likely that
railroad gauges are based the width of Roman ox carts and the width of an
ox. But those were probably just ordinary carts bought or commandeered for
military use, when needed. And considering that oxen have horns, it may not
be their hind ends that are the determining width factor.

Finally, the Romans actually didn't standardize their military much (or even
have a professional standing army) until the time of Gaius Marius (until
then Roman soldiers provided their own arms, and legions were raised as
needed), This was in the fairly late Republic, about 100 BC, long after many
roads were built in Italy.  Marius reformed the Roman Army, and made it a
more professional, more or less standing army, where the public treasury
bought the arms.  So, if there was a Roman mil. spec. for carts, it was an
effect the existing roads and carts, not a cause.

Be that as it may, there is a certain truth here, underneath the
embellishments.  Standards, once established, often remain in use for a very
long time. X.509 is unlovely enough as it is, without perpetuating two digit
dates.  Ron Rivest is right: "This ought to be fixed, just to avoid the
laugh factor." If X.509 is widely successful, as it may be, then much could
remain in use in 2080.  There are a lot of other things to complain about in
X.509, but this is surely one we can fix.

>i believe we should get away from two digits years. we had a discussion in
>previous directory defect meetings and proposed doing a wrap around also. this
>is a acceptable bandage but we should fix the problem.
>
>to handle backward compatability we could define additional extensions that
>duplicate the extensions that use utc time but replace the utc time with
>generalizedtime. we could allow the extensions to co-exist for a period but
>after that period deprecate the use of the earlier extensions. if we don't
>change the semantics of the earlier extension, we could accomplish this by
>defect.
>
>note that the rules of extensibility should allow extension to a choice (adding
>to a choice or creating a choice) only if the original field was optional.
>
>for those who think that x.509 might not effect things in 2099, i offer the
>following story (those of you who are too busy or too serious should ignore the
>rest of this message)
>
>(i don't know the author of this story)
>
> The US Standard railroad gauge (distance between the rails) is 4 feet, 8.5
>inches. That's an exceedingly odd number. Why was that gauge used? Because
>that's the way they built them in England, and the US railroads were built by
>English expatriates.
>
> Why did the English people build them like that? Because the first rail lines
>were built by the same people who built the pre-railroad tramways, and that's
>the gauge they used.
>
> Why did "they" use that gauge then? Because the people who built the tramways
>used the same jigs and tools that they used for building wagons, which used
that
>wheel spacing.
>
> Okay! Why did the wagons use that odd wheel spacing? Well, if they tried
to use
>any other spacing the wagons would break on some of the old, long distance
>roads, because that's the spacing of the old wheel ruts.
>
> So who built these old rutted roads? The first long distance roads in Europe
>were built by Imperial Rome for the benefit of their legions. The roads have
>been used ever since. And the ruts? The initial ruts, which everyone else
had to
>match for fear of destroying their wagons, were first made by Roman war
>chariots. Since the chariots were made for or by Imperial Rome they were all
>alike in the matter of wheel spacing.
>
> Thus, we have the answer to the original questions. The United State standard
>railroad gauge of 4 feet, 8.5 inches derives from the original specification
>(Military Spec) for an Imperial Roman army war chariot. MilSpecs and
>Bureaucracies live forever.
>
> So, the next time you are handed a specification and wonder what horse's ass
>came up with it, you may be exactly right. Because the Imperial Roman chariots
>were made to be just wide enough to accommodate the back-ends of two war
horses.
>
>  hoyt
>_______________________________________________________________________________
>Subject: RE: X.509 validity period
>From:    "Miklos, Sue A." <[email-masked]> at AZ05-SMTP
>Date:    10/3/96  12:31
>
>
>I have had similar requirements proposed and would like to discuss the 
>possibility of adding the ability of CHOICE to the certificate time formats 
>(UTC or GenTime).  I did briefly mention this to Warwick when I last saw him 
>and he expressed concern over backwards compatibility.  I'd be happy to 
>bring this up at the ISO editing meeting the end of this month if we can get 
>some concensus...
>Sandi
> ----------
>From: pki-twg-request
>To: OSIdirectory; pki-twg; ietf-pkix; Warwick Ford
>Subject: X.509 validity period
>Date: Wednesday, October 02, 1996 10:21AM
>
>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
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: RE(2): X.509 validity period
Date: Fri, 4 Oct 1996 11:31:26 -0700

Tom,.

This ia 100% correct way to  view risks inevitably associated with
*any* use of ciphers, even those which are "US govt certified!"

All I can say is beware from whom you buy a cert-server;
you may not get what the security upon which you
are expecting to rely! Get your laywer ready for
the companies misrepresentations...to seek redress!

"If RSA lasts another 50 years, we need better math
and science funding"

That an algoirhtm has laster 10 years is good news (for
that algorithms users, current and short-term future). But
we must not get complacent about the long-term risks 
key size recommendations and ALL ciphers face.

We addressed the issue of coming century rollover when
we helped design Microsoft's Authenicode security
mechanisms for software trust, which uses the 
X.509 standard ratified internationally, and by the US State
dept. Its a trivial 4 lines of code in the validation module
which millions of systems will shortly be using, I suspect.

We were not so arrogant as to say the solution solved
the problem of depending on ciphers in a risky manner
for ALL applications!

I do asset, however, that its risk for anyone to believe or
represent that a 1024 bit RSA document-signing key whould be 
legally usable in even 10 years time, without notarial support.

If one desires longevity for message signature validity, one must
use notarial procedures to cover  a multitide of risks,
not the least of which includes the ciphers and keys.

Todate, this digital signature understanding is robust
enought to support what X.509 standardizes - real time
authentication, and for which purpose the fields
are restriced to UTC conventions. By taking some risks,
the technology can be used for signatures on documents
with a short life time, .e.g. software people with to buy
today, or payment systems, or adding evidential weight to
an act of witnessing a legal agreement.

Its arrogance to believe the understanding or technology
available is suitable for any more bigger goals than
these first tentative steps, with short range reliances
exhibited by software products (with short 1 year commercial
lifespans!), one-time payment transactions, and indisputable witnessing
acts of legal agreement at a given moment (as supported by notarys!)

Peter.

----------
From: 	[email-masked]
Sent: 	Thursday, October 03, 1996 11:50 PM
To: 	[email-masked]
Subject: 	RE(2): X.509 validity period

         I wish I could understand this argument. 
         
         I don't see how a certificate can last longer than its ability 
         to withstand attack. Are we not working on the 
         basis that crypto technology will have advanced sufficiently
         by the year 20-whatever-it-is that a 1996 certificate could be 
         forged at will? If this is the case, aren't such old certificates 
         worth no more than the floppy they are written on? If my great 
         grandson wants to prove that Warwick signed a promissory note 
         for a million dollars in 1995 (you *do* remember doing that don't 
         you Warwick?) all he needs to do is create a false old certificate 
         and a falsely signed note. Perhaps one way of focusing the mind
         on the difficulties is to imagine trying to protect from a
         cryptographer of today an ancient Roman "signed" document 
         signed (well, sealed - it's the best they could have done)
         using a Caesar cipher.
         
         So over the years certificates will be devalued according to the
         ease with which they can be forged. Perhaps one way of prolonging
         their life is to "refresh" them with stronger technology, by 
         signing the certificate inside another certificate at intermediate 
         points. The logic would then be: at a time at which the
         certificate could not be broken, an authority I trust has
         reinforced it, at a subsequent time before the first authority's
         certificate could not be broken, a second authority I trust has
         further reinforced that reinforced certificate ...etc..). Sounds
         a bit heavy though!
         
         Regards,
         Tom Parker
         4th October 1996
         -----------------------------------------------------------------
         Tom Parker, Security Architect, ICL Fellow.
           
         Tel:      +44.1344.472169        The Solution Centre
         Fax:      +44.1249.822703        ICL Enterprise Technology
         Mobile:   +44.385.551826         Lovelace Road,
         Home Tel: +44.1249.814762        Bracknell RG12 8SN
                                          UK
         
         email:    t.a.parker(a)win0199.wins.icl.co.uk
         -----------------------------------------------------------------

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Warwick Ford <[email-masked]>, "'Nick Pope'" <[email-masked]>
Subject: RE: X.509 validity period
Date: Fri, 4 Oct 1996 10:47:21 -0700

NIck,

There is a simpler technique, which requires no infrastructure modification, or involvement
from ISO, particularly. It ensure that those who uinderstand the
value of UTC time handling in authentication protocols are not
foced to use theories not- standarized by X.509, as facilitated
by GeneralisedTime.

The INTERNET PKIX group might specify an extension, opionally
critical, named GeneralTimeValidity, which when present has the semantics
that it replaces the v1 validity fields, and establishes toBeDecided
semantics for handling time sources during authentication,
and path validation. If the extension is critical, the conformant software
shall always perform such replacement and toBeDecided
time source handling, else fail certificate validaton.

Such a techqniue ensures that those who have enviornments where
the UTCness of UTCTime is a requirement (ie. one uses real time
time sources from CCITT sources) have clearly specified
std functionality. Where enviornments have a need to invent a new model
of time handling in an authentication protocol, they are then provided
with the necessary tool in GeneralizedTimeValidity, and shall specify the
rules for handling of time sources and time comparison,
replacing toBeDecided above.

UTCTime is a complete time rule. GenralisedTime is not; it can
be though. Simply replacing GeneralizedTime for UTCTime changes
the nature of the real-time strong authentication semantics in X.509,
as the nature of time sources is altered.

This is quite a responable proposal, and responds to the underlying
argument that there is a need for non-real time validation of
certs in 50 years time, when supporting proof of origin with NR 
security services in a messaging environment.

This time thing is about more than 2 versus 4 digit year representation.
Actual Cellular use of X.509 services already relies upon the
UTCness properties already standardised by ISO for 10 years.

The real issue is about eliminating a standard rule for time handling in preference 
to one needed by messaging apps. A competent standard group
would allow for both obvious models to support maximally the number
of enviornments in which the syntax can be used, without ambiguity.

Peter.

----------
From: 	Nick Pope
Sent: 	Friday, October 04, 1996 2:30 AM
To: 	Nick Pope; [email-masked]; [email-masked]; [email-masked]; Warwick Ford
Subject: 	Re: X.509 validity period

In reply to your message of  3 Oct 96, 13:12:

With the way that X.509 is becoming the basis for many of the security
protocols being used today I believe that there is a good chance that
X.509 (or its decendent) will be around in 2087.  Whilst solutions like
SET are likely to be superceded with new payment technology, in all
probability it will still be in use.  Payment by a Check book (is the
same word used in American?) is still widely used even though there are
more covenient methods around.

Is it worth a small amount of pain now than causing confusion later 
next century with the need to re-do all certificate management 
software that may be around in the world by then (could be every 
personal computer, networking service and banking system).

Nick

> I agree with [email-masked].  We simply write into the PKIX
> spec (or X.509 itself) that any year in the range 00 through 87 means
> 20xx rather than 19xx.  This will keep X.509 dates working until year
> 2087.  The idea of certificates being valid for 50 years is just not
> in line with technology expectations - what cryptographer is confident
> that any of the technologies we are currently using will still be
> cryptographically sound in 50 years?
> 
> More pointedly, does anyone out there really think X.509 will still be
> in use in year 2087?
> 
> Warwick
> 
> 
> At 10:21 AM 10/2/96 +0000, Nick Pope wrote:
> >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?
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

Date: Fri, 04 Oct 1996 11:31:47 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re[2]: X.509 validity period  -Reply -Reply

Hoyt, I loved the story about standards and horses asses. We have met the 
enemy and they are us. Some of the things we do may take on a life of their own.

The people who should have worried about the year 2000 problem made a "gain now, 
pain later" decision, and they probably assumed they would be off on another
job or with another company before it would all come to rest. We shouldn't 
perpetuate the problem.

I like the CHOICE OF solution, but the time to fix the problem is NOW, before many more
certificates are issued. The ones that have been issued so far will probably expire
before 2000, but we have a very narrow window  to come up with a 
definitive fix.  My rationale is as follows:

1. At a minimum we need an agreed-to ad hoc solution for roll-over for any certificates
issued to date. In particular, this will be needed for some long lived certificates that
have already been issued, including some root certificates. But the ad hoc solution should
be definitive with respect to this century, so we don't have the problem again in another
100 years.

2.  Assuming that few certificates will be issued with longer than a 3 year validity 
period, January 1, 1997, will begin the major period of confusion. Certificates with 2 year
validity periods start the confusion period in 1998, etc.

Is it realistic to assume that all of the existing product code, notably Netscape's, could 
adopt a CHOICE OF notation for validity period (if they implement it validity period 
checking at all) by December of this year?  Frankly, I highly doubt it, although it might be 
barely possible -- we would have to poll the all the major players and get a commitment
from them for an updated version, or a confirmation that they wouldn't do 
anything drastically wrong if they saw such a generalizedTime encoding.

What might be more reasonable would be to file a defect report ASAP, and to profile 
the usage within the PKIX document as strongly deprecating the use of generalizedTime 
in any certificates issued prior January 1, 1998, and strongly deprecating the use of
utcTime in any certificates issued after that date whose validity period would end on or
after January 1, 2000. That would give all the various vendors 15 months to solve the
problem in their code, and that should certainly be achievable.

Would changing the definition of the validity period necessitate going to a version 4?
I wouldn't be opposed to that -- it might be the cleanest solution.

Bob

Robert R. Jueneman
Security Architect
NetWare Security R&D
Internet Infrastructure Division
Novell, Inc. M/S-PRV-D241
122 East 1700 South
Provo, UT 84606
801/861-7387

From: Mark Bartel <[email-masked]>
Subject: Re: X.509 validity period
To: [email-masked] (Nick Pope)
Date: Fri, 4 Oct 1996 12:52:26 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

> With the way that X.509 is becoming the basis for many of the security
> protocols being used today I believe that there is a good chance that
> X.509 (or its decendent) will be around in 2087.  Whilst solutions like
> SET are likely to be superceded with new payment technology, in all
> probability it will still be in use.  Payment by a Check book (is the
> same word used in American?) is still widely used even though there are
> more covenient methods around.

I agree.  I keep thinking of all the programmers who figured 20 years
ago that their systems would no longer be in use by the year 2000.
And *that's* just specific implementations, not a *standard*.  I
believe that if X.509 is widely accepted 10 years from now, it (or a
descendent) could just as easily still be in common use 100 years from
now.  As more and more things are computerized, changing a standard is
going to become more and more difficult, instrusive, and expensive,
especially something like authentication which can usefully be used in
pretty much anything.

> Is it worth a small amount of pain now than causing confusion later 
> next century with the need to re-do all certificate management 
> software that may be around in the world by then (could be every 
> personal computer, networking service and banking system).

YES!  I do *not* think it is reasonable to limit a standard because it
*might* be superseded.  If you don't build limitations into it, it
might not be.  If you do build limitations into it, it will *have* to
be.  Think of how nice it would be to have standards which *ARE*
standard, and don't keep changing every few years.

> > I agree with [email-masked].  We simply write into the PKIX
> > spec (or X.509 itself) that any year in the range 00 through 87 means
> > 20xx rather than 19xx.  This will keep X.509 dates working until year
> > 2087.  The idea of certificates being valid for 50 years is just not
> > in line with technology expectations - what cryptographer is confident
> > that any of the technologies we are currently using will still be
> > cryptographically sound in 50 years?

First, just because low confidence is assigned to the validity of the
signature doesn't mean that it won't be useful to check it anyway.
And second, the estimation that current key lengths will be inadequate
is based on the assumption that (a) factoring algorithms will continue
to improve and (b) that the current rate of improvement in hardware
will continue.  These assumptions are reasonable from a security
standpoint, where one must be pessimistic, but who knows?  A 1536 bit
key length may be just as unbreakable in 2097 as it is now, and I'm
using a length of 2040 bits currently (excessive, probably).  Remember
that this is not a linear function; the difference in power required
to break 1024 bit keys vs 768 bit keys is *much* smaller than the
difference between 1280 vs 1024.  And just because the certificate has
expired doesn't mean that you wouldn't want to verify it anyway
(someone else has talked about what validity dates really mean).

- Mark Bartel ([email-masked])

PS.  There are major industry analysts (not all of them, but some)
that predict that at *least* one *major* company will go out of
business just because of the year 2000 problem.  I don't remember the
reference; if anybody cares I will try to find it.  I'd rather not see
the same thinking that caused that problem be perpetuated in X.509.

From: [email-masked] (Ron Rivest)
Date: Fri, 04 Oct 96 12:12:55 EDT
To: [email-masked]
Subject: X.509 validity period

You know, I laughed quite a bit when I heard that X.509 had a
"two-digit year problem".  

This ought to be fixed, just to avoid the laugh factor...

	Cheers,
	Ron

Date: Fri, 04 Oct 1996 10:11:11 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: X.509 validity period  -Reply -Reply

Peter,

I don't disagree with anything you've said. Sometime we become so enamored with 
the technical "what is possible" that we lose sight of the "what is needed."

I was just trying to shed a little light on the topic of nonrepudiation, which I have
found difficult to explain to people in a reasonable and balanced way. Typically, 
they don't understand the notion at all, and then once they begin to understand,
they tend to go whole hog and want very long certificate validity periods, notarized time-
stamps, archive everything, etc. As you point out, that may be necessary for
a small percentage of all transactions, but certainly not the majority.

If I really thought I had a 50 year retention requirement, the first problem that I would worry
about would be long-term media compatibility problem. I've got lots of standard 5-1/4"
floppies I can no longer read (for lack of a reader on my current computer), to say 
nothing of some of the quad-density and other odd formats I have lying around.
(Of course one way of dating a document is to date the media on which it is written -- 
its not very likely that anyone could record a song on a wax cylinder today, for
example.)

So one solution would be to contract with a specialist in archiving records -- someone 
who would guarantee to periodically reread the media on which the information was
recorded to ensure it is still intact, and to rerecorded it in whatever new formats come
along, timestamping it and wrapping it in their own digital signature format with
ever-increasing key lengths. And you'd better make sure that the archive company
itself will be an enduring institution, and is guaranteed to be adequately funded in 
perpetuity. The Library of Congress and the Catholic church come to mind, but both are
short of funds. The Mormons are probably better record keepers, but they've only been
around for 100+ years, so they don't have a proven track record yet. Maybe a Buddhist
monastery, if you don't mind schlepping all your records to Tibet. (I can see the IBM
ThinkPad advertisement already, if they only had a place to recharge the batteries.)

Or there is a much simpler solution, one that is both economical and time-proven. Print
the document in question on good acid-free rag paper (if you can find any), and include
a printed copy of the digital signature in hex. If good paper is used, the media should
survive 500 years or more, so the next question is the ink. I still have a Diablo 630 printer 
I'd be willing to sell cheap to anyone who needs one -- with a carbon ribbon and a metal
print wheel the impressions should last as long as the paper. 500 years from now, if
anyone still cares, the paper can be scanned in and reprinted. The digital signature
will be completely worthless except as an indicia of authorship, but the physical aging of he
paper itself will be very difficult to forge, and the message digest will protect against 
undetected corruption of the text.

Bob,

>>> Peter Williams <[email-masked]> 10/02/96 01:46pm >>>
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.

Forcing every internet mail to be signed, or when signed, it must be legally dated, is not
on. People should be able to send any quality of signed mail they
desire, not that which only suits lawyers or other legal needs.

Whats the problem? Is the std too flexible, for American freedoms, in allowing
choice and handling of risks at the individual's level?

Peter.

Date: Fri, 04 Oct 96 10:34:02 EST
From: "Tom Zmudzinski" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: railroad gauge (was "Re[2]: X.509 validity period")

Slightly before all of the world's computer calendars went mad at the 
end of the XXth Century (10/3/96 12:36 PM), [email-masked] 
posted [after a BIG snip]:

>  Thus, we have the answer to the original questions. The United State standard
> railroad gauge of 4 feet, 8.5 inches derives from the original specification
> (Military Spec) for an Imperial Roman army war chariot. MilSpecs and
> Bureaucracies live forever.
> 
>  So, the next time you are handed a specification and wonder what horse's ass
> came up with it, you may be exactly right. Because the Imperial Roman chariots
> were made to be just wide enough to accommodate the back-ends of two war 
> horses.
> 
>   hoyt

  As Molly McGee said frequently and eloquently to her husband 
  "Fibber", ''T'ain't funny, McGee!'' -- 
  
  1. The Roman MILSPEC was a deliberate decision to facilitate road 
  building and to make the world safer for [Roman] Truth, [Roman] 
  Justice, and the Appian Way.  [Why do you think the Romans said, 
  "Where Rome's Legions trod, there is Rome!"?]
  
  2. Consider the alter-nasty-tive:  Australia runs both English 
  [which is to say, Roman] gauge and Irish gauge [supposedly based 
  on the length of Brian Boru's stride].  I understand, thanks to 
  "Great Railway Journeys of the World", that the cause was a Scot!
  
  [Well, it LOOKS like my e-mail .sig ...]   vr/tez
    
  This space intentionally left what would
  otherwise be blank were this not here.

  

Date: Fri, 04 Oct 96 10:02:53 EST
From: "Tom Zmudzinski" <[email-masked]>
To: [email-masked]
Subject: Re[4]: X.509 validity period

In the final lustrum [*] of the Twentieth Century (10/3/96 4:47 PM),  
Peter Williams <[email-masked]> opined:    

> Do you believe you will be able to find a media reader for the
> floppy in 50 years time?
>  
> Will the court still have a 3" floppy reader?
>
> Will the court be willing to believe a key used to perform "binding signature
> marks" 50 years still has the innate strength to so bind in the present,
> given cryptographic capability change?
  
  There's this little thing called "burden of proof".  If I, playing 
  Advocatus Diaboli for a moment, challenge an X.509 certificate in 2087 
  (actually, I have a much loftier goal: I want to be around for the Y10K 
  problem), the burden of proof is on me.  That means I would have to 
  have experts (possibly with gear borrowed from the Information Age 
  exhibit at the Smithsonian) prepared to present evidence of my claim.  
  (Or they might plug in a simulation from a 25 terabyte isolinear clip.)
  I suspect my rented liars (er, "experts") would do better going after 
  the "purity" of the certificate, that is, challenging its provenance.
  
> Will the court be willing to believe a key used to perform "binding signature
> marks" 50 years still has the innate strength to so bind in the present,
> given cryptographic capability change?
>
> Of course not. The key can assert integrity over the long term;
> direct accountability for the duration of reasonable reliance on the cert for
> name binding, and internal data from the signed message
> along with notarial conduct, for the rest.

  Thank you for supporting my position that "in use" depends upon one's 
  definition.  If one's definition of "in use" is "still using the same 
  hardware and software", the obvious answer is "no" as we're certainly 
  going to have better hardware and software in the future.  If it's "has 
  to stand up in a court of law", the answer is "yes".  You've provided 
  an example of how this might be accomplished without requiring X.509 
  to be bulletproof forever. 
  
  Quoting from _Cryptography's_Role_in_Securing_the_Information_Society_
  (page 2-5 of the 30 May draft, for all you fussbutts out there):
  
  ''First, the initial deployment of any technology often brings out 
    unanticipated problems, simply because the products and artifacts 
    embodying that technology have not had the benefit of successive 
    cycles of failure and repair.  Similarly, human procedures and 
    practices have not been tested against the demands of real-life 
    experience.  Cryptography is unlikely to be any different, and so 
    it is probable that early large-scale deployments of cryptography 
    will exhibit exploitable vulnerabilities.''
  
  [snip happens, even in the best of threads]
  
  v/r
  Tom Zmudzinski ..... [email-masked] ... (physically at:)
  (mail:) DISA Code D20A? ... (703) 681-0231 ... Skyline 5, Suite 9116
  701 S. Courthouse Road  ... (DSN) 761-0231 ... 5111 Leesburg Pike
  Arlington VA 22204-2199 ... (FAX) 681-0345 ... Falls Church VA 22041
  
  [*] For those of you who didn't look it up last time.  It means a 
      period of five years.  (It's currently 1996 and the XXth Century 
      ends at midnight, December 31st, 2000 ACE.  Tick, tick, ...)

From: Nick Pope <[email-masked]>
To: Nick Pope <[email-masked]>, [email-masked], [email-masked], [email-masked], Warwick Ford <[email-masked]>
Date: Fri, 4 Oct 1996 09:30:42 +0000
Subject: Re: X.509 validity period
Priority: normal

In reply to your message of  3 Oct 96, 13:12:

With the way that X.509 is becoming the basis for many of the security
protocols being used today I believe that there is a good chance that
X.509 (or its decendent) will be around in 2087.  Whilst solutions like
SET are likely to be superceded with new payment technology, in all
probability it will still be in use.  Payment by a Check book (is the
same word used in American?) is still widely used even though there are
more covenient methods around.

Is it worth a small amount of pain now than causing confusion later 
next century with the need to re-do all certificate management 
software that may be around in the world by then (could be every 
personal computer, networking service and banking system).

Nick

> I agree with [email-masked].  We simply write into the PKIX
> spec (or X.509 itself) that any year in the range 00 through 87 means
> 20xx rather than 19xx.  This will keep X.509 dates working until year
> 2087.  The idea of certificates being valid for 50 years is just not
> in line with technology expectations - what cryptographer is confident
> that any of the technologies we are currently using will still be
> cryptographically sound in 50 years?
> 
> More pointedly, does anyone out there really think X.509 will still be
> in use in year 2087?
> 
> Warwick
> 
> 
> At 10:21 AM 10/2/96 +0000, Nick Pope wrote:
> >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?
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Nick Pope <[email-masked]>
To: [email-masked], Warwick Ford <[email-masked]>
Date: Fri, 4 Oct 1996 09:42:35 +0000
Subject: Comments on 
Priority: normal

Comments on Internet PKI Part III: Certificate 
Management Protocols

IPKI3CMP-00

I have been working on the use of the Internet PKI  
Certificate Management Protocols and as a result 
would like to point out the following errors / 
comments:

a) Clause 3.1 PKIProtection in PKIMessage

This field should be optional as it is not always 
required to apply additional protection to PKI 
messages (e.g. Cert Announce or CRL Announce 
which just carry certificates which are already 
protected).

b) Clause 3.1.1 Tagging of PKIHeader fields

My ASN.1 syntax checker says that the tagging in 
the PKI header is not correct.   I=92m not sure of the 
exact rules but I would have thought that at least 
the optional fields should be tagged.  My 
suggestion would be to tag all the fields.  Provided 
that implicit tagging is used this would not incur 
any overhead and ensure that there was no 
ambiguity.

c) Clause 3.1.1 PKI Header, free text

BNPString -> BMPString

d) Clause 3.1.1 PKI Header last item

This includes as =91,=92 after the OPTIONAL which 
should not be present.

e) Clause 3.1.1 Message Type

The labels for the values should begin with a lower 
case character as these reference values not data 
types.

f) 3.1.2 PKIBody Content type tags and 3.1.1PKI 
Header Message Type

Given that each type of message has a content type 
tagged with the same values what is the point of 
having the Message Type in the PKI Message 
Header?  What happens if they are set different 
due to an error?

I suggest that Message Type is deleted from the 
header.

g) clause 3.1.3

It is stated that PKIProtection ::=3D SIGNATURE 
SEQUENCE { ....
is the same as 

PKIProtection ::=3D SEQUENCE {
  alg AlgorithmIdentifier OPTIONAL
  protectionBits BIT STRING }

How in the X.509 SIGNATURE structure the 
algorithm identifier is not optional.

h) Clause 3.2.1

Remove ',' from after last field of CertTemplate

i) Clause 3.3.4 Cert response

Remove ',' from after last field.

j) Clause 3.3.8

The optional fields require tags.

Remove ',' after last field in sequence.

k) Clause 3.3.9

The optional fields require tags.

l) Clause 3.3.9 & 4.3.2

It is stated that key recovery returns the entire 
history of user's key.

This should only return those whose certificates 
match the certificate fields given in cert template.

I Note also in part I the X.509 certificate structure 
is re-written.  This does not come out with the 
same encoding as the standard certificate as a 
SEQUENCE structure is itself encoded as a TLV. 

In X.509 the algorithm ID and BITSRING 
signature is in a SEQUENCE, the certificate 
contents is not in a sequence.

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: <[email-masked]>
X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Fri, 4 Oct 1996 07:51:20 +0100
X400-Received: by mta feldr1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Fri, 4 Oct 1996 07:49:50 +0100
X400-Received: by mta bra01c1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Fri, 4 Oct 1996 07:49:30 +0100
X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5-text); Relayed; Fri, 4 Oct 1996 07:50:32 +0100
Date: Fri, 4 Oct 1996 07:50:32 +0100
X400-Originator: [email-masked]
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;win0199         0000008800011134]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 11134
Alternate-Recipient: Allowed
To: [email-masked]
Subject: RE(2): X.509 validity period

         I wish I could understand this argument. 
         
         I don't see how a certificate can last longer than its ability 
         to withstand attack. Are we not working on the 
         basis that crypto technology will have advanced sufficiently
         by the year 20-whatever-it-is that a 1996 certificate could be 
         forged at will? If this is the case, aren't such old certificates 
         worth no more than the floppy they are written on? If my great 
         grandson wants to prove that Warwick signed a promissory note 
         for a million dollars in 1995 (you *do* remember doing that don't 
         you Warwick?) all he needs to do is create a false old certificate 
         and a falsely signed note. Perhaps one way of focusing the mind
         on the difficulties is to imagine trying to protect from a
         cryptographer of today an ancient Roman "signed" document 
         signed (well, sealed - it's the best they could have done)
         using a Caesar cipher.
         
         So over the years certificates will be devalued according to the
         ease with which they can be forged. Perhaps one way of prolonging
         their life is to "refresh" them with stronger technology, by 
         signing the certificate inside another certificate at intermediate 
         points. The logic would then be: at a time at which the
         certificate could not be broken, an authority I trust has
         reinforced it, at a subsequent time before the first authority's
         certificate could not be broken, a second authority I trust has
         further reinforced that reinforced certificate ...etc..). Sounds
         a bit heavy though!
         
         Regards,
         Tom Parker
         4th October 1996
         -----------------------------------------------------------------
         Tom Parker, Security Architect, ICL Fellow.
           
         Tel:      +44.1344.472169        The Solution Centre
         Fax:      +44.1249.822703        ICL Enterprise Technology
         Mobile:   +44.385.551826         Lovelace Road,
         Home Tel: +44.1249.814762        Bracknell RG12 8SN
                                          UK
         
         email:    t.a.parker(a)win0199.wins.icl.co.uk
         -----------------------------------------------------------------

Organization: Consensus Development Corporation <http://www.consensus.com/>
Date: Thu, 3 Oct 1996 13:56:14 -0700
To: [email-masked] (Hemma Prafullchandra)
From: Christopher Allen <[email-masked]>
Subject: Re: DSS certs
Cc: [email-masked]

At 12:30 PM -0700 10/3/96, Hemma Prafullchandra wrote:
>Can those of you who are in a position to provide a
>certification authority *service* for DSS certificate
>issuance please respond to me.
>(I want the CA service provider to sign with a DSA key).
>
>If there is interest, I can post a summary of the responses.

We need the same thing -- we'll have some software that can 'theoretically'
be a CA for DSS soon, but without examples (like the test CA for RSA certs
we developed on the Netscape/VeriSign model) we risk interoperability
issues.

Consensus Development has no desire in entering into the CA business -- we
have a customer demand for adding support for DSS certificates into the
next version of our SSL Plus product.

------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<[email-masked]>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..

From: [email-masked]
Date: Thu, 03 Oct 96 12:36:52 MST
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re[2]: X.509 validity period

i believe we should get away from two digits years. we had a discussion in
previous directory defect meetings and proposed doing a wrap around also. this
is a acceptable bandage but we should fix the problem.

to handle backward compatability we could define additional extensions that
duplicate the extensions that use utc time but replace the utc time with
generalizedtime. we could allow the extensions to co-exist for a period but
after that period deprecate the use of the earlier extensions. if we don't
change the semantics of the earlier extension, we could accomplish this by
defect.

note that the rules of extensibility should allow extension to a choice (adding
to a choice or creating a choice) only if the original field was optional.

for those who think that x.509 might not effect things in 2099, i offer the
following story (those of you who are too busy or too serious should ignore the
rest of this message)

(i don't know the author of this story)

 The US Standard railroad gauge (distance between the rails) is 4 feet, 8.5
inches. That's an exceedingly odd number. Why was that gauge used? Because
that's the way they built them in England, and the US railroads were built by
English expatriates.

 Why did the English people build them like that? Because the first rail lines
were built by the same people who built the pre-railroad tramways, and that's
the gauge they used.

 Why did "they" use that gauge then? Because the people who built the tramways
used the same jigs and tools that they used for building wagons, which used that
wheel spacing.

 Okay! Why did the wagons use that odd wheel spacing? Well, if they tried to use
any other spacing the wagons would break on some of the old, long distance
roads, because that's the spacing of the old wheel ruts.

 So who built these old rutted roads? The first long distance roads in Europe
were built by Imperial Rome for the benefit of their legions. The roads have
been used ever since. And the ruts? The initial ruts, which everyone else had to
match for fear of destroying their wagons, were first made by Roman war
chariots. Since the chariots were made for or by Imperial Rome they were all
alike in the matter of wheel spacing.

 Thus, we have the answer to the original questions. The United State standard
railroad gauge of 4 feet, 8.5 inches derives from the original specification
(Military Spec) for an Imperial Roman army war chariot. MilSpecs and
Bureaucracies live forever.

 So, the next time you are handed a specification and wonder what horse's ass
came up with it, you may be exactly right. Because the Imperial Roman chariots
were made to be just wide enough to accommodate the back-ends of two war horses.

  hoyt
_______________________________________________________________________________
Subject: RE: X.509 validity period
From:    "Miklos, Sue A." <[email-masked]> at AZ05-SMTP
Date:    10/3/96  12:31

I have had similar requirements proposed and would like to discuss the 
possibility of adding the ability of CHOICE to the certificate time formats 
(UTC or GenTime).  I did briefly mention this to Warwick when I last saw him 
and he expressed concern over backwards compatibility.  I'd be happy to 
bring this up at the ISO editing meeting the end of this month if we can get 
some concensus...
Sandi
 ----------
From: pki-twg-request
To: OSIdirectory; pki-twg; ietf-pkix; Warwick Ford
Subject: X.509 validity period
Date: Wednesday, October 02, 1996 10:21AM

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

Date: Thu, 3 Oct 1996 12:30:41 -0700
From: [email-masked] (Hemma Prafullchandra)
To: [email-masked]
Subject: DSS certs

Folks,

Can those of you who are in a position to provide a
certification authority *service* for DSS certificate
issuance please respond to me.
(I want the CA service provider to sign with a DSA key).

If there is interest, I can post a summary of the responses.

Thanks,
Hemma Prafullchandra
JavaSoft
Sun Microsystems Inc

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Tom Zmudzinski'" <[email-masked]>
Subject: RE: Re[2]: X.509 validity period
Date: Thu, 3 Oct 1996 12:31:33 -0700

Do you believe you will be able to find a media reader for the
floppy in 50 years time?
 
Will the court still have a 3" floppy reader?

Will the court be willing to believe a key used to perform "binding signature
marks" 50 years still has the inate strength to so bind in the present,
given cryptographic capability change?

Of course not. The key can assert integrity over the long term;
direct accontability for the duration of reasonable reliance on the cert for
name binding, and internal data from the signed message
along with notarial  conduct, for the rest.

This is how it happens now. There is no reason
to expect it to change because of introduction of a bit
of automated signing technology.

The automation/technology stuff just cuts costs, and adds flexibility and
ease of use of signatures in new settings (telematic world); arguably, it should
never change the essence of things through mere use. Over time, perhaps...

Peter.

----------
From: 	Tom Zmudzinski
Sent: 	Thursday, October 03, 1996 11:59 AM
To: 	[email-masked]
Subject: 	Re[2]: X.509 validity period

In the final lustrum [*] of the Twentieth Century (10/3/96 1:29 PM), 
Warwick Ford <[email-masked]> posted:

> I agree with [email-masked].  We simply write into the PKIX spec
> (or X.509 itself) that any year in the range 00 through 87 means 20xx rather
> than 19xx.  This will keep X.509 dates working until year 2087.  The idea of
> certificates being valid for 50 years is just not in line with technology
> expectations - what cryptographer is confident that any of the technologies
> we are currently using will still be cryptographically sound in 50 years?
> 
> More pointedly, does anyone out there really think X.509 will still be in
> use in year 2087?
> 
> Warwick

  Depending upon one's definition of "in use", yes, I do -- because I 
  "really think" that archived traffic will still have be able to stand 
  up in a court of law in year 2087.  Other than amusing future computer 
  archeologists, that's the sole reason for having long term retention.  
  And as far a Tort Law is concerned, we'll still be playing by the same 
  rules as people were in the middle of the Fourteenth Century.  Now, if 
  you assassinate all the lawyers NLT COB 2086 ... ;{Q
  
  v/r
  Tom Zmudzinski ..... [email-masked] ... (physically at:)
  (mail:) DISA Code D20A? ... (703) 681-0231 ... Skyline 5, Suite 9116
  701 S. Courthouse Road  ... (DSN) 761-0231 ... 5111 Leesburg Pike
  Arlington VA 22204-2199 ... (FAX) 681-0345 ... Falls Church VA 22041
  
  [*] Look it up.  It's a perfectly good word.

Date: Thu, 3 Oct 96 11:39:33 PDT
From: Ebbe Hansen <[email-masked]>
To: [email-masked]
Subject: Re: X.509 validity period

> I agree with [email-masked].  We simply write into the PKIX 
spec
> (or X.509 itself) that any year in the range 00 through 87 means 20xx
>  rather
> than 19xx.  This will keep X.509 dates working until year 2087.  The idea
>  of
> certificates being valid for 50 years is just not in line with technology
> expectations - what cryptographer is confident that any of the 
technologies
> we are currently using will still be cryptographically sound in 50 years?
> 
> More pointedly, does anyone out there really think X.509 will still be in
> use in year 2087?
> 
> Warwick
> 
> 
> At 10:21 AM 10/2/96 +0000, Nick Pope wrote:
> >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.
> >
One way to handle the needs to verify "old" electronic signatures would be 
to store (all?) expired certificates for subsequent signature validation.

If a reliable (non-reputable) time stamp was included (within the signed 
data) it should be possible to retrieve and apply the certificate that was 
valid at the time the signature was generated.

Ebbe Hansen @ Cylink Corp.

> >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?
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 
> 
> 

Date: Thu, 03 Oct 96 13:59:33 EST
From: "Tom Zmudzinski" <[email-masked]>
To: [email-masked]
Subject: Re[2]: X.509 validity period

In the final lustrum [*] of the Twentieth Century (10/3/96 1:29 PM), 
Warwick Ford <[email-masked]> posted:

> I agree with [email-masked].  We simply write into the PKIX spec
> (or X.509 itself) that any year in the range 00 through 87 means 20xx rather
> than 19xx.  This will keep X.509 dates working until year 2087.  The idea of
> certificates being valid for 50 years is just not in line with technology
> expectations - what cryptographer is confident that any of the technologies
> we are currently using will still be cryptographically sound in 50 years?
> 
> More pointedly, does anyone out there really think X.509 will still be in
> use in year 2087?
> 
> Warwick

  Depending upon one's definition of "in use", yes, I do -- because I 
  "really think" that archived traffic will still have be able to stand 
  up in a court of law in year 2087.  Other than amusing future computer 
  archeologists, that's the sole reason for having long term retention.  
  And as far a Tort Law is concerned, we'll still be playing by the same 
  rules as people were in the middle of the Fourteenth Century.  Now, if 
  you assassinate all the lawyers NLT COB 2086 ... ;{Q
  
  v/r
  Tom Zmudzinski ..... [email-masked] ... (physically at:)
  (mail:) DISA Code D20A? ... (703) 681-0231 ... Skyline 5, Suite 9116
  701 S. Courthouse Road  ... (DSN) 761-0231 ... 5111 Leesburg Pike
  Arlington VA 22204-2199 ... (FAX) 681-0345 ... Falls Church VA 22041
  
  [*] Look it up.  It's a perfectly good word.

From: Mark Bartel <[email-masked]>
Subject: subscribe
To: [email-masked]
Date: Thu, 3 Oct 1996 13:51:09 -0400 (EDT)

subscribe

From: "Miklos, Sue A." <[email-masked]>
To: ietf-pkix <[email-masked]>, OSIdirectory <[email-masked]>, pki-twg-request <[email-masked]>, pki-twg <[email-masked]>, Warwick Ford <[email-masked]>
Subject: RE: X.509 validity period
Date: Thu, 03 Oct 96 12:31:00 EDT
Encoding: 45 TEXT

I have had similar requirements proposed and would like to discuss the 
possibility of adding the ability of CHOICE to the certificate time formats 
(UTC or GenTime).  I did briefly mention this to Warwick when I last saw him 
and he expressed concern over backwards compatibility.  I'd be happy to 
bring this up at the ISO editing meeting the end of this month if we can get 
some concensus...
Sandi
 ----------
From: pki-twg-request
To: OSIdirectory; pki-twg; ietf-pkix; Warwick Ford
Subject: X.509 validity period
Date: Wednesday, October 02, 1996 10:21AM

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

Date: Thu, 03 Oct 1996 13:12:36 -0400
To: Nick Pope <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: X.509 validity period

I agree with [email-masked].  We simply write into the PKIX spec
(or X.509 itself) that any year in the range 00 through 87 means 20xx rather
than 19xx.  This will keep X.509 dates working until year 2087.  The idea of
certificates being valid for 50 years is just not in line with technology
expectations - what cryptographer is confident that any of the technologies
we are currently using will still be cryptographically sound in 50 years?

More pointedly, does anyone out there really think X.509 will still be in
use in year 2087?

Warwick

At 10:21 AM 10/2/96 +0000, Nick Pope wrote:
>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?
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

From: "Anil R. Gangolli" <[email-masked]>
Date: Wed, 2 Oct 1996 21:57:01 -0700
Reply-To: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: X.509 implementation notes

On Oct 3,  3:02pm, <[email-masked]> 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
see an increasing usage of these at least in internal corporate Internet
environments, and possibly growing out into the Internet at large.

These use the RFC1779 string form of distinguished names.  If/When/As
LDAP directory service becomes widespread it will be of increasing
utility to have subject names in certificates correspond to
distinguished names in directory service entries.

Also, the use of a single AVA per RDN should be strongly encouraged
to work with common LDAP implementations.  This also avoids the
DER-encoding mess brought on by sets with multiple AVAs.

==
As a side note, this RFC dictates that the string form is to be written in
least-significant to most-significant RDN order (reverse of the
ordering in the actual ASN.1/DER). For example, (assuming your example
denotes a path starting at C=US), the string form of the name above
would be:
CN=John Doe, OU=X.500 Standards Designers, O=Hanger 13, L=Area 51, C=US
==

 > Validity
 > --------
 >
 > Validity ::= SEQUENCE {
 >     notBefore               UTCTIME,
 >     notAfter                UTCTIME
 >     }
 >
 > The IETF recommends that all times be expressed in GMT and seconds not be
 > encoded, giving:
 >
 >   YYMMDDHHMMZ
 >
 > as the time encoding.  However certificates have been found which
 > include seconds.  This doesn't lead to an ambiguous encoding because
 > you should never encode a value of 00 seconds, which means if you read
 > in a UTCTime value generated by an implementation which doesn't use
 > seconds and write it out again with an implementation which does,
 > it'll have the same encoding because the 00 won't be encoded.
 >
 > Non-GMT encodings have never been reported, but it may be a good idea
 > to include handling for the "+/-xxxx" time offset format just in case
 > (but flag it as a decoding error).
 >
 > In coming up with the worlds least efficient time encoding format, the
 > ISO nevertheless decided to forgo the encoding of centuries, so if you
 > find a year less than 80, add 100 to the century.

Alot of the shipped software out there doing verification
uses the traditional "Unix epoch" start as the threshold date.
i.e. A year YY below 70 (not 80 as above) is considered to
represent the year 20YY.

The IETF probably ought to recommend a single convention here for a
threshold date and perhaps an extension should be defined to allow
expressing the validity in "GeneralizedTime".

 > Known Bugs
 > ----------
 >
 > The following bugs are known to exist in X.509 (and related) implementations
 > from different vendors:
 >
 > Netscape
 >
 > Invalid encoding of some (but only some) occurences of the integer
 > value 0 (encoded as integer, length = 0 rather than integer, length =
 > 1, value = 0).  How they can get it right in one place and then wrong
 > 50 bytes later is a puzzle.

I'd like to pursue this.  If Netscape software was used to generate
the certificate mentioned above, can you please indicate what product
was used.  If you have an example of such a certificate could you
please send it to me (base64-encoded or uuencoded DER) for
examination.  Thank you.

--anil.

From: <[email-masked]>
To: [email-masked]
Subject: X.509 implementation notes
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 3 Oct 1996 15:02:56 (NZST)

I've been putting together a few notes on X.509 implementation issues over the 
last few days after discussion with other people revealed that there seems to 
be a lot of confusion over how these should be done.  A very rough first draft 
is included below, if anyone has any comments on them please let me know.  
I'll probably put this on the web somewhere when its finished since it seems 
there's a need for this sort of thing.
 
Just give me a minute to get a fork and some marshmellows before you reply :-).
 
Peter.

                        X.509 Implementation Notes
                        ==========================
 
                 Peter Gutmann, [email-masked]
                              30 October 1996
 
Anyone who has had to work with X.509 has probably experienced what can best be
described as ISO water torture, which involves ploughing through all sorts of
ISO, ANSI, ITU, and IETF standards, amendments, meeting notes, draft standards,
committee drafts, working drafts, and other work-in-progress documents, some of
which are best understood when held upside-down in front of a mirror.  Because
of this confusion, noone seems to know how to implement X.509 certificates
properly (see 'Known Bugs' below).  This document is an attempt at providing a
cookbook for certificates which should give you everything that you can't find
anywhere else without devoting your life to the search, as well as comments on
what you'd typically expect to find in certificates.  The conventions used are:
 
- All encodings follow the DER unless otherwise noted.
 
- Most of the formats are ASN.1.  Occasionally 15 levels of indirection are cut
  out to make things easier to understand.
 
- Questions are marked by '=>' at the start.  If anyone has any comments on
  these please let me know.

Certificate
-----------
 
Certificate ::= SEQUENCE {
    tbsCertificate          TBSCertificate,
    signatureAlgorithm      AlgorithmIdentifier,
    signature               BIT STRING
    }
 
The encoding of the Certificate may follow the BER rather than the DER.  At
least one implementation uses the indefinite-length encoding form for the
SEQUENCE.

TBSCertificate
--------------
 
TBSCertificate ::= SEQUENCE {
    version          [ 0 ]  Version DEFAULT v1(0),
    serialNumber            CertificateSerialNumber,
    signature               AlgorithmIdentifier,
    issuer                  Name,
    validity                Validity,
    subject                 Name,
    subjectPublicKeyInfo    SubjectPublicKeyInfo,
    issuerUniqueID    [ 1 ] IMPLICIT UniqueIdentifier OPTIONAL,
    subjectUniqueID   [ 2 ] IMPLICIT UniqueIdentifier OPTIONAL,
    extensions        [ 3 ] Extensions OPTIONAL
    }

Version
-------
 
Version ::= INTEGER { v1(0), v2(1), v3(2) }
 
The default version is v1(0).  If the issuerUniqueID or subjectUniqueID are
present than the version must be v2(1) or v3(2).  If extensions are present
than the version must be v3(2).  An implementation should target v3
certificates, which is what everyone is moving towards.

SerialNumber
------------
 
CertificateSerialNumber ::= INTEGER
 
This should be unique for each certificate issued by a CA (typically a CA will
keep a counter in persistent store somewhere, perhaps a config file under Unix
and in the registry under Windows).  Another way is to take the current time in
seconds and subtract some base time like the first time you ran the software,
to keep the numbers manageable.
 
Serial numbers aren't necessarily restricted to 32-bit quantitues.  For example
the RSADSI Commercial Certification Authority serial number is 0x0241000016,
which is larger than 32 bits.  If you're writing certificate-handling code,
just treat them as a blob which happens to be an encoded integer.

Signature
---------
 
This rather misnamed field contains the algorithm identifier for the signature
algorithm used by the CA to sign the certificate.  There doesn't seem to be
much use for this field, although you should check that the algorithm
identifier matches the one of the signature on the cert (if anyone can forge
the signature on the cert then they can also change the inner algorithm
identifier, it's possible that this was included because of some obscure attack
where someone who could convince (broken) signature algorithm A to produce the
same signature value as (secure) algorithm B could change the outer,
unprotected algorithm identifier from B to A, but couldn't change the inner
identifier without invalidating the signature.  What this would achieve is
unclear).

Name
----
 
Name ::= SEQUENCE OF RelativeDistinguishedName
 
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
 
AttributeValueAssertion ::= SEQUENCE {
    attributeType           OBJECT IDENTIFIER,
    attributeValue          ANY
    }
 
This is used to encode that wonderful ISO creation, the Distinguished Name
(DN), a path through an X.500 directory information tree (DIT) which uniquely
identifies everything on earth.  Although the RelativeDistinguishedName (RDN)
is given as a SET OF AttributeValueAssertion (AVA) each set should only contain
one element.  However it *may* contain more than one, there has been a reported
case of a certificate which contained more than one element in the SET.
 
=> How are these handled?  If you've got an entry with a CN and extra
   attributes of email address and phone number it's obvious to a human that
   the CN is the important one, but how do you handle it in software?
 
When encoding sets with cardinality > 1, you need to take care to follow the
DER rules which say that they should be ordered by their encoded values
(although ASN.1 says a SET is unordered, the DER adds ordering rules to ensure
it can be encoded in an unambiguous manner).  What you need to do is encode
each value in the set, then sort them by the encoded values, and output them
wrapped up in the SET OF encoding.
 
You don't have to use a Name for the subject name if you don't want to; there
is a subjectAltName extension which allows use of email addresses or URL's.  If
you want to do this, make the Name an empty sequence and include a
subjectAltName extension and mark it critical.  Because of this, you should be
prepared to accept a zero-length sequence for the subject name in version 3
certificates.
 
Typically you would expect to find the following types of AVA's in an X.509
certificate, starting from the top:
 
countryName     ::= SEQUENCE { { 2 5 4 6 }, StringType( SIZE( 2 ) ) }
organization    ::= SEQUENCE { { 2 5 4 10 }, StringType( SIZE( 1...64 ) ) }
organizationalUnitName
                ::= SEQUENCE { { 2 5 4 11 }, StringType( SIZE( 1...64 ) ) }
commonName      ::= SEQUENCE { { 2 5 4 3 }, StringType( SIZE( 1...64 ) ) }
 
The countryName is the ISO 3166 code for the country.  A StringType is either a
TeletexString, a PrintableString, a UniversalString, or an IA5String.
 
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.

Validity
--------
 
Validity ::= SEQUENCE {
    notBefore               UTCTIME,
    notAfter                UTCTIME
    }
 
The IETF recommends that all times be expressed in GMT and seconds not be
encoded, giving:
 
  YYMMDDHHMMZ
 
as the time encoding.  However certificates have been found which include
seconds.  This doesn't lead to an ambiguous encoding because you should never
encode a value of 00 seconds, which means if you read in a UTCTime value
generated by an implementation which doesn't use seconds and write it out again
with an implementation which does, it'll have the same encoding because the 00
won't be encoded.
 
Non-GMT encodings have never been reported, but it may be a good idea to
include handling for the "+/-xxxx" time offset format just in case (but flag it
as a decoding error).
 
In coming up with the worlds least efficient time encoding format, the ISO
nevertheless decided to forgo the encoding of centuries, so if you find a year
less than 80, add 100 to the century.

UniqueIdentifier
----------------
 
UniqueIdentifier ::= BITSTRING
 
These were added in X509v2 to handle the possible reuse of subject and/or
issuer names over time.  Their use is deprecated by the IETF.  If you're
writing certificate-handling code, just treat them as a blob which happens to
be an encoded bitstring.
 
No occurrences of a UniqueIdentifier have been reported.

Extensions
----------
 
Extensions ::= SEQUENCE OF Extension
 
Extension ::= SEQUENCE {
    extnid                  OBJECT IDENTIFIER,
    critical                BOOLEAN DEFAULT FALSE,
    extnValue               OCTETSTRING
    }
 
X.509 certificate extensions are like a LISP property list: an ISO-standardised
place to store crufties.  Extensions can consists of key and policy
information, certificate subject and issuer attributes, certificate path
constraints, CRL distribution points, and private extensions.
 
[There are large numbers of these things.  If people can tell me what they've
 encountered in the past I'll document them]
 
Netscape have quite a few defined for things like CRL URL's and SET defines a
few as well, but none have ever been spotted in the wild.

Open Issues
-----------
 
The creation of a no-authentication certificate (which is the equivalent of an
unsigned PGP key which states something like "Noone has certified this key, but
here it is anyway") is possible using self-signed certificates.  Technically
this isn't a legal way to certify a key, and Netscape will reject these keys.
It may be possible to provide an equivalent mechanism with a null signature OID
and signature.

Known Bugs
----------
 
The following bugs are known to exist in X.509 (and related) implementations
from different vendors:
 
Verisign
 
  Their PKCS #10 stuff is wrong.  According to the PKCS #10 spec, the
  attributes field is mandatory, so if it is empty it is encoded as NULL.
  Verisigns software however assumes that if there are no attributes, the field
  should not be present, treated it like an OPTIONAL field.  This is,
  unfortunately, what the example in PKCS #10 does - there are no attributes so
  it leaves them out, contrary to the spec a few pages earlier.
 
SHTTP specification
 
  There is at least one invalid PCKS#7 example in earlier versions of the spec.
  The most recent draft <draft-ietf-wts-shttp-03.txt> July 1996 (Expires
  January-97) fixes this.  Implementors should ensure they are working with the
  latest version of the draft.
 
COST
 
  The lengths of some of the fields in CRL's are broken.  Specifically, the
  lengths of some sequences are calculated incorrectly, so if your code merely
  nods at things like SET and SEQUENCE tags and lengths as they whiz past and
  then works with the individual fields it'll work, but if it tries to work
  with the length values given (for example making sure the lengths of the
  components of a sequence add up correctly) then it'll break.  The sequence
  lengths are longer than the amount of data in the sequence, the COST code may
  be adding the lengths of the elements of the sequence incorrectly (it's a bit
  hard to tell what's going wrong.  Basically the CRL's are broken).
 
Microsoft
 
  Will create certificates with one of the weirder 32-bit wide character string
  types being used to encode all fields in the DN (probably a BMPString
  containing straight Unicode).  While not illegal, it's a truly Microsoft way
  of using ASN.1.
 
Netscape
 
  Invalid encoding of some (but only some) occurences of the integer value 0
  (encoded as integer, length = 0 rather than integer, length = 1, value = 0).
  How they can get it right in one place and then wrong 50 bytes later is a
  puzzle.

Sample Certificates
-------------------
 
Include some samples:
 
- Basic v1.
- Basic v3 with C, O, OU, and CN in the DN.
- Basic v3 with BER encoding of outer wrapper.
- v3 with other fields in the DN (what would be used?).
- v3 with extensions (what would be used?).
- Microsoft certificates with oddball string types.

Acknowledgements
----------------
 
Eric Young provided lots of useful information on encoding issues and bugs.

Date: Wed, 02 Oct 1996 14:43:25 -0700
To: [email-masked]
From: Kaye Caldwell <[email-masked]>
Subject: ** 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:
[email-masked] 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:

 http://www.softwareIndustry.org/coalition/dswgopen.html

Digital Signature Background page:

http://www.softwareIndustry.org/issues/1digsig.html

For more information, e-mail Kaye Caldwell at [email-masked] or call
408-479-8743.

Kaye Caldwell
Software Industry Coalition Policy Director
CommerceNet Adovocacy and Public Policy Committee Chair
-------------------------------

===========================================================================
Kaye Caldwell Phone:(408)479-8743 Fax:(408) 479-9247 E-mail:[email-masked]
Editor, Software Industry Issues (Web: http://www.SoftwareIndustry.org/issues/)
Policy Director, Software Industry Coalition (Web:
http://www.SoftwareIndustry.org/coalition/)
President, Computer Software Industry Association  (Web:
http://www.SoftwareIndustry.org/csia/)
Legislative Director, Software Forum  (Web:  http://www.SoftwareForum.org/)
===========================================================================

Date: Wed, 02 Oct 1996 17:50:47 -0400
To: Nick Pope <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: X.509 Bug Regarding Policy Constraints
Cc: [email-masked]

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.  
>> 
>> Warwick
>> --------------------------------------
>> 
>>
>......
>
>> 10.	Nature of Defect:  (complete, concise explanation of the perceived
>> problem)
>> 
>> 12.4.2.3 (Policy constraints field) includes a policySet component in
>> the ASN.1 and describes its semantics, but the path processing
>> procedure in 12.4.3 does not include processing for that component. 
>> If processing for policySet were to be added to 12.4.3, the algorithm
>> would become very complex, with little real benefit.  It is the
>> submitter's contention that policySet should have been removed in the
>> DAM editing process (the same component was removed from the Name
>> constraints field), but was inadvertently left in.
>> 
>> 11.	Solution Proposed by the Source:  (optional)
>> 
>> In 12.4.2.3, remove the policySet component from the ASN.1 and delete
>> the first paragraph after the ASN.1.  Also remove the SEQUENCE OF from
>> the ASN.1, as this becomes unnecessary.  Assign the extension a new
>> OID (id-ce 36) to avoid confusion.  Reflect the same ASN.1 changes in
>> Annex A.
>> 
>> 12.	Editor's Response:
>> (any material proposed for processing as an erratum to, an amendment
>> to, or a commentary on the IS or DIS final text/CCITT Recommendation
>> or Draft Recommendation is attached separately to this completed
>> report).
>> 
>> 
>> 
>> 
>> -------------------------------------------------------------------
>> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
>> -------------------------------------------------------------------
>> 
>
>-------------------------------------
>
>
>Security & Standards
>Suite A
>191 Moulsham St.
>Chelmsford
>Essex
>CM2 0LG
>U.K.
>
>Tel: +44 1245 495018
>Fax: +44 1245 494517
>
>
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

From: Peter Williams <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X.509 validity period  -Reply
Date: Wed, 2 Oct 1996 12:46:40 -0700

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.

Forcing every internet mail to be signed, or when signed, it must be legally dated, is not
on. People should be able to send any quality of signed mail they
desire, not that which only suits lawyers or other legal needs.

Whats the problem? Is the std too flexible, for American freedoms, in allowing
choice and handling of risks at the individual's level?

Peter.

----------
From: 	Bob Jueneman
Sent: 	Wednesday, October 02, 1996 10:56 AM
To: 	[email-masked]; [email-masked]
Cc: 	[email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: 	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, 
long after most people would care.

Don't forget that the purpose of a certificate is to document the binding that 
exists between a named entity (assuming that there is a name) and the public
key (and by inference, the corresponding private key) AT THE TIME THE CERTIFICATE
WAS ISSUED. Depending on the details of the CA's Certification Practice Statement, 
the CA is under no obligation to maintain continuous vigilance to ensure that the binding
continues to be factually correct. And to expect that the binding would continue to 
be correct for 50 years is almost ludicrous. The subject would very likely have moved,
changed jobs, or even died during that time period.

In addition, it is highly unlikely that the degree of cryptographic security which is 
economically affordable now would continue to be adequate to resist reasonable 
threats for 50 years -- the keys would have to be impractically long.

I believe that your question is due to the confusion between the technical concept of
non-repudiation in the computer security context, vs. the reality of the legal context. 
First of all, there is no such thing in the legal context of a nonrepudiable signature -- 
a signature can always be contested because of fraud, forgery, duress, mental or legal
incompetence, and a host of other reasons. But on the other hand, the revocation or
expiration of a certificate does not in and of itself invalidate a digital signature as a 
legally binding signature -- it just makes the validity of the signature someone more 
difficult to prove. 

This is where business records, physical protection, and even motive and opportunity
come into play. And in most cases, the rules of evidence and the required standard of
proof is far less than that required in criminal proceedings of "beyond reasonable doubt." 
It isn't even "clear and convincing," but most of the time is simply the relatively weak
"preponderance of the evidence."

So I would submit that your customer does not in fact need a 50 year validity period, nor
would it be meaningful even if it were technically feasible. Instead, they need to rethink or
restate their requirements, or you need to rethink your solution to those requirements.

Bob

Date: Wed, 02 Oct 1996 11:56:56 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: 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, 
long after most people would care.

Don't forget that the purpose of a certificate is to document the binding that 
exists between a named entity (assuming that there is a name) and the public
key (and by inference, the corresponding private key) AT THE TIME THE CERTIFICATE
WAS ISSUED. Depending on the details of the CA's Certification Practice Statement, 
the CA is under no obligation to maintain continuous vigilance to ensure that the binding
continues to be factually correct. And to expect that the binding would continue to 
be correct for 50 years is almost ludicrous. The subject would very likely have moved,
changed jobs, or even died during that time period.

In addition, it is highly unlikely that the degree of cryptographic security which is 
economically affordable now would continue to be adequate to resist reasonable 
threats for 50 years -- the keys would have to be impractically long.

I believe that your question is due to the confusion between the technical concept of
non-repudiation in the computer security context, vs. the reality of the legal context. 
First of all, there is no such thing in the legal context of a nonrepudiable signature -- 
a signature can always be contested because of fraud, forgery, duress, mental or legal
incompetence, and a host of other reasons. But on the other hand, the revocation or
expiration of a certificate does not in and of itself invalidate a digital signature as a 
legally binding signature -- it just makes the validity of the signature someone more 
difficult to prove. 

This is where business records, physical protection, and even motive and opportunity
come into play. And in most cases, the rules of evidence and the required standard of
proof is far less than that required in criminal proceedings of "beyond reasonable doubt." 
It isn't even "clear and convincing," but most of the time is simply the relatively weak
"preponderance of the evidence."

So I would submit that your customer does not in fact need a 50 year validity period, nor
would it be meaningful even if it were technically feasible. Instead, they need to rethink or
restate their requirements, or you need to rethink your solution to those requirements.

Bob

From: [email-masked]
Date: Wed, 02 Oct 96 09:11:12 MST
To: Nick Pope <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: 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 <[email-masked]> 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
> 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)
> 
> 12.4.2.3 (Policy constraints field) includes a policySet component in
> the ASN.1 and describes its semantics, but the path processing
> procedure in 12.4.3 does not include processing for that component. 
> If processing for policySet were to be added to 12.4.3, the algorithm
> would become very complex, with little real benefit.  It is the
> submitter's contention that policySet should have been removed in the
> DAM editing process (the same component was removed from the Name
> constraints field), but was inadvertently left in.
> 
> 11. Solution Proposed by the Source:  (optional)
> 
> In 12.4.2.3, remove the policySet component from the ASN.1 and delete
> the first paragraph after the ASN.1.  Also remove the SEQUENCE OF from
> the ASN.1, as this becomes unnecessary.  Assign the extension a new
> OID (id-ce 36) to avoid confusion.  Reflect the same ASN.1 changes in
> Annex A.
> 
> 12. Editor's Response:
> (any material proposed for processing as an erratum to, an amendment
> to, or a commentary on the IS or DIS final text/CCITT Recommendation
> or Draft Recommendation is attached separately to this completed
> report).
> 
> 
> 
> 
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

To: Nick Pope <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], Warwick Ford <[email-masked]>
Subject: Re: X.509 validity period 
Date: Wed, 02 Oct 1996 15:14:47 +0100
From: Michael Roe <[email-masked]>

> 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.).

Mike

From: Nick Pope <[email-masked]>
To: [email-masked], [email-masked], [email-masked], Warwick Ford <[email-masked]>
Date: Wed, 2 Oct 1996 09:39:07 +0000
Subject: Re: X.509 Bug Regarding Policy Constraints
CC: [email-masked]
Priority: normal

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)
> 
> 12.4.2.3 (Policy constraints field) includes a policySet component in
> the ASN.1 and describes its semantics, but the path processing
> procedure in 12.4.3 does not include processing for that component. 
> If processing for policySet were to be added to 12.4.3, the algorithm
> would become very complex, with little real benefit.  It is the
> submitter's contention that policySet should have been removed in the
> DAM editing process (the same component was removed from the Name
> constraints field), but was inadvertently left in.
> 
> 11.	Solution Proposed by the Source:  (optional)
> 
> In 12.4.2.3, remove the policySet component from the ASN.1 and delete
> the first paragraph after the ASN.1.  Also remove the SEQUENCE OF from
> the ASN.1, as this becomes unnecessary.  Assign the extension a new
> OID (id-ce 36) to avoid confusion.  Reflect the same ASN.1 changes in
> Annex A.
> 
> 12.	Editor's Response:
> (any material proposed for processing as an erratum to, an amendment
> to, or a commentary on the IS or DIS final text/CCITT Recommendation
> or Draft Recommendation is attached separately to this completed
> report).
> 
> 
> 
> 
> -------------------------------------------------------------------
> Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
>    Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
> -------------------------------------------------------------------
> 

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

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

Tel: +44 1245 495018
Fax: +44 1245 494517

From: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: X.509 validity period
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 3 Oct 1996 01:15:11 (NZST)

>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.

From: Nick Pope <[email-masked]>
To: [email-masked], [email-masked], [email-masked], Warwick Ford <[email-masked]>
Date: Wed, 2 Oct 1996 10:21:29 +0000
Subject: X.509 validity period
Priority: normal

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