I took the following notes at the session on ISO 9595-8 certificate
extensions at the Southmapton SC 21 meeting.
These are *not* the official minutes, and may contain inaccuracies or personal
bias. I'm posting these notes to pem-dev as I expect they'll be of interest.
Michael Roe
Computer Security Group
Cambridge University Computer Laboratory
===========================================================================
Notes on Certificate Extensions Meeting
Southampton, July 1994
Attendance
Hoyt Kesterson (US, project editor)
Dave Chadwick (UK)
Michael Roe (UK)
Warwick Ford (Canada)
Junichi Yamaguchi (Japan)
Ella Gardner (US)
Debra Ansen (CH)
Documents
The following documents were distributed at the meeting:
* ANSI X9.30 (draft) Public Key Cryptography Using
Irreversible Algorithms for the Financial Services
Industry
* SC 21/WG1/N1261 US Contribution on NP for Extensions
to ISO/IEN 9594-8
* SC 21/WG4/N1971 Canadian Contribution on proposed
extensions to X.509 Certificates
* (Canada temp doc) Explanatory support for proposed
extensions to X.509 CA Certificates
* (Canada temp doc) Latest ANSI X9.30-3 Certificate
Formats
Discussion
1. Certificate Extensions
Hoyt Kesterson explained his proposal for adding an
extensions field to certificates and CRLs. Each extension
is accompanied by a criticality indicator; if an
extension is marked as non-critical, it may be safely
ignored.
It was asked how can the verifier of a certificate
compute the DER encoding of an extension it doesn't
understand. As the computation of the DER encoding of the
certificate is an essential part of certificate
verification, it must be possible to do this.
Hoyt Kesterson said that he was very displeased that
existing implementations re-calculate the DER encoding;
it was his original intention that the signature be
computed on the octets as received. It was pointed out
that implementors do this because the published standard
tells them to do so.
Two solutions to this problem were proposed:
a) Require that all certificate extensions use explicit
tagging everywhere
b) Encapsulate each extension inside something (e.g. an
ASN.1 EXTERNAL) in order to ensure that the octets as
received will be identical to the DER encoding.
Both of these proposals suffer from some technical
problems:
a) DER of EXTERNAL
Even if extensions are encapsulated, certificate
verification will still require the computation of the
DER encoding of the whole certificate, including the
encapsulated extensions. The definition of DER (and the
related Canonical Encoding Rules, CER) neglects to define
the encoding of an EXTERNAL.
It was suggested that what implementors would do (in the
absence of clear guidance from the standard) was to
replace EXTERNAL with its ISO 8824 definition (which is a
sequence of various elements) and then apply DER to this
sequence. This would probably have the right effect.
Hoyt pointed out that there is also a CHOICE construct in
the definition of EXTERNAL, and the DER definition
doesn't define the encoding of a CHOICE either. Again,
it is clear what a sensible implementor would do, but the
standard itself could do with being made more precise.
b) DER of SET and SET-OF
The ASN.1 constructs SET and SET OF share the same tag
value. However, the rules for computing the DER of these
two constructs are different. HHHH ence the first
proposal (require all certificate extensions to use
explicit tagging everywhere) won't work if a certificate
extension contains a SET or SET OF construct. If the
certificate verifier doesn't understand the extension,
they will be able to tell from the explicit tag that the
extension is either a SET or SET OF, but this is not
sufficient to enable the verifier to compute the DER
encoding.
It was pointed out that the rules for SET and SET OF have
the same effect in many cases. Thus, even if the verifier
makes a wrong guess as to whether the extension is a SET
or SET OF, they can still end up getting the right
answer. If the two rules always had the same effect in
all cases, then the fact that the verifier doesn't know
which rule to apply wouldn't matter. Unfortunately, we
were able to find a case in which the two rules have
different effects. This is when a SET contains items with
context-specific tags, and at least one tag value is so
large that it cannot be represented in a single octet.
c) The 1994 version of ASN.1
It was pointed out that EXTERNAL is treated differently
in the 1994 version of ASN.1. There is a new construct,
called EMBEDDED-PDV. The final text of the new ASN.1 was
not available during this meeting. It was resolved that
we would consult with ASN.1 experts to find out what is
the ``recommended'' way of encapsulating an encoding
with the new ASN.1
2. Progression of the work
Hoyt asked whether this work should be progressed a
defect report or a NWI. If we progress it as a defect
report, the changes can be made to the `version 2'
certificate, but if we progress it as a NWI the changes
will result in a `version 3' certificate.
Resolution:
We will try and have the text stable by the meeting in
Phoenix this December. We will aim to have a PDAM for
ballot before next year's SC 21 meeting.
Warwick asked if the work on CRLs should be in the same
document as the work on certificates. The work on CRLs is
considerably less mature, and it might delay progress to
combine them.
Resolution:
Certificate extensions and CRL extensions will be in the
same document for the time being. They can be separated
later if this causes problems.
3. Relationship with SC 27 work
Debra Ansen drew the meeting's attention to the SC 27
work on certificates. The SC 27 certificates are seeing
some real use, notably in the European Commission funded
TEDIS and SESAME projects. Why are there two different,
incompatible standards for what appears to be the same
thing?
Michael Roe pointed out that SC 21 has received a liaison
statement from SC 27 describing their work on
certificates. This meeting was therefore formally
entitled to consider the SC 27 work and (if necessary)
send a liaison statement back. Unnecessary proliferation
of similar but conflicting standards was felt to be
undesirable.
Resolution: Liaison statements are to be sent to the
following bodies:
(a) SC 27
(b) Implementor's workshops, e.g. the NIST OIW
(c) The IETF
4. Canadian proposal for certificate extensions
4.1 Naming Jurisdiction Rules
It was asked whether the support for naming jurisdiction
rules was necessary. Hoyt said that it would have to be
included to make the proposal acceptable to the Internet
Privacy Enhanced Mail community, where such naming rules
are part of the official security policy.
It was pointed out that the Internet naming jurisdiction
rules (in their current form) are a direct consequence of
the certificate extensions NWI having taken several years
to get going. If ISO 9594-8 had been extended earlier
to provide a better mechanism, then the Internet
community might have used it.
Hoyt expressed an opinion that the new policy constraints
extension could be used to serve the same purpose as
naming jurisdiction rules, and furthermore had the
advantage of not confusing naming with security
policies.
Michael Roe suggested that the essence of the naming
jurisdiction rules were that the name of an entity was
being used to determine which security policy applies to
it. Thus, if a message is received from an entity whose
name starts c=US;o=IBM it is inferred that the applicable
security policy is the one dealing with interactions
between the recipient and IBM. (In particular, it is
inferred that the sender's certification authority ought
to be the IBM certification authority). There was
widepread disagreement with this interpretation.
Dave Chadwick suggested that the name could be considered
as being a parameter of the security policy.
4.2 Multiple Keys
It was asked how the proposed extensions will permit
different keys to be used for different purposes, and
would this be backwards compatible with the current
scheme.
Warwick explained the proposal as follows:
Version 1 certificates use a generic algorithm identifier
(e.g. `rsa') in the subjectPublicKeyInfo field. This is
interpreted to mean that the key can be used with the RSA
algorithm for any purpose.
New certificates may contain a different algorithm
identifier (e.g. rsaWithMD5) which restricts the usage of
the associated key to a specific purpose (in this case,
digital signature). The permitted purposes are part of
the definition of the algorithm identifier.
New certificates may also contain additional keys in
extension fields. In this case, each additional key is
accompanied by a list of the purposes for which it may be
used.
5. Certificate Revocation Lists
5.1 Revocation of Expired Certificates
It has been proposed that text be added to X.509
permitting a certification authority to revoke a
certificate which has expired.
It was asked why would a certification authority ever
want to do this; what is the meaning of a revoked,
expired certificate supposed to be; what action is a
certificate user supposed to take when this happens; and
what is the effect on the non-repudiation service.
From the point of view of a certificate verifier, there
appears to be no difference. If the certificate has
expired, then the verifier should reject it. Explicitly
revoking an expired certificate makes no difference to
the verifier's behavior, and hence appears to be
pointless.
It was argued that revoking an expired certificate can
assist disaster recovery. Suppose the events happen in
the following order:
1. A's key is compromised
2. Attacker uses A's key to forge a message to B
3. B accepts the forged message, as A's certificate is
neither expired nor revoked.
4. A's certificate expires
5. A detects the compromise, and reports it to the CA
6. The CA wishes to inform B that A's key was compromised
Depending on what B did as a result of the forged
message, it may or may not be too late for B to take
corrective action. In the cases where it is not too late
for B to take corrective action, clearly B would like to
be told that the compromise occurred. This is an argument
in favour of allowing expired certificates to be revoked.
The second argument in favour of revoking expired
certificates was that with the non-repudiation service,
an adjudicator would like to know when the key compromise
happened. It was pointed out that the adjudicator will
typically look at the certification authority's paper
records, and not the on-line Directory Service, when
resolving disputes.
An argument against permitting back-dated revocation was
that is causes problems with the non-repudiation service.
In the example above, who would be legally liable for the
consequences of B having acted on the basis of the forged
certificate? A? B? The certification authority? It was
pointed out that the real problem here is that undetected
compromises can happen, and this is a problem
irrespective of whether or not revocation can be back-
dated.
5.2 Temporary Hold Facility
X9.30 describes a mechanism whereby a CA can put a
certificate `on hold'. Verifiers should reject
certificates that are on hold, but a CA can change the
status of a certificate from being on hold to being valid
again. This is different from revocation, which is
permanent. A revoked certificate can never be made valid
again. This facility is useful when the CA suspects a
compromise has occurred, but isn't sure; the certificate
can be put on hold while the CA investigates further.
The general principle was considered to be a reasonable
one.
The issue was raised as to whether this sort of mechanism
was best provided using the Directory CRL attribute, or
by using a specialized on-line server. For this mechanism
to be effective, changes must propagate rapidly. Some
well-known Directory implementations are not very good at
rapidly propagating frequent changes. Dave Chadwick said
that not all Directory implementations were as bad as
QUIPU.
5.3 Alternative CRL Formats
We identified two types of certificate users for which
the current CRL format is not well suited. These were
a) Large transaction processing systems, with plenty
of stable storage. These systems would like to receive
revocation information as `what's changed' updates
which can be applied to their locally stored copy of the
revocation list.
b) Cryptographic modules with limited memory and long
term storage. These systems would like to receive
revocation information split into blocks, with each block
stating the minimum and maximum serial number. When
verifying a certificate, the cryptographic module need
only load the relevant block, and not the entire list of
all revoked certificates.
It would also be desirable to have an on-line revocation
server, for applications were it is necessary to be sure
that a certificate is valid at that moment (and hasn't
been revoked a few hours previously). A comparison was
made with credit cards, were high-value transactions
require an on-line check that the card has not been
revoked, but low-value transactions do not.
It was noted that the US DOD's MOSAIC system provides two
separate CRL mechanisms: A fast propagating one for
urgent revocation (e.g. after a key is compromised) and a
slow propagating one for non-urgent revocation (e.g. when
a user's organisational affiliation changes).
5.4 Key used to sign CRLs
It was pointed out that a CA may want to use different
keys for signing certificates and for signing CRLs. CRL
signing needs to be done at regular intervals. For this
reason, the CA may use a different computer system for
signing CRLs than for signing certificates, and the CRL
signing system may be more vulnerable to attack (e.g.
because it has a more direct connection to a computer
network). The consequences of the CRL-signing key being
compromised are less serious than those of the
certificate-signing key being compromised. (A forged CRL
will at worst result in denial of service).
The extension allowing different keys for different
purposes (e.g. signing and key exchange) could also be
used to provide separate keys for CRL-signing and
certificate-signing.
Hoyt asked if it was also possible to use two different
keys for the same purpose. For example, an on-line server
and an off-line server have different private keys, but
both might be permitted to sign CRLs. It was pointed out
that this would require a key version identifier in the
CRL, so that the CRL verifier knew which of the two
possible keys to use for signature verification. The
approach of trying all possible keys until one works was
acknowledged to be viable, but was considered inelegant.
========================================================================