Warwick,
Please find enclosed my comments on the certificate extensions working
draft.
These are my comments only, not UK approved comments. I'm sending them to
you directly rather than through the official process as the official process
usually takes too long ...
Mike
Comments on Certificate Extensions WD
Michael Roe
5th September 1994
[MRR 1] 5.2
The KeyIdAndUsage extension should be split into two
separate extensions, one for key id and one for usage.
Rationale:
a) The two items of information are quite separate. It is
possible that a security domain would require support for
one but not the other.
b) Key Identifier is clearly not critical (ignoring it is
harmless). However, Key Usage should be marked as
critical; if it isn't an end-system which didn't support
the extension would allow the key to be used for a
purpose which was forbidden. These two items of
information should be separate extensions so that they
can have different criticalities.
[MRR 2] 5.2
The ASN.1 definition of KeyUsage is illegal; it is a
CHOICE of two types with the same tag. This could be
fixed by adding context-specific tags, or by making this
two separate extensions as described above.
[MRR 3] 5.2, UserKeyUsage
The distinction between ``long term'' and ``short term''
non-repudiation is not well-defined. It would better to
have a single flag for non-repudiation, rather than
splitting it into two in this way. (Policy identifiers
can be used to express the length of time over which non-
repudiation is effective).
[MRR 4] 6.2, SecondaryPublicKeyInfo
The keyIdentifier field of SecondaryPublicKeyInfo should
be made optional; it makes sense to have this extension
even without a key identifier.
[MRR 5] 7.3.2
CA constraints are described as being an ``insurance''
provision. It is only an ``insurance'' provision in that
it prevents an entity doing something which it isn't
supposed to do. Most security mechanisms fall into this
category! (The difference in this case is that a CA is
``trusted'' in respect to some activities; It is trusted
to get the name-key binding right. If this extension is
being used, the CA is not trusted to only sign
certificates within its jurisdiction; there is a means of
preventing it misbehaving in this way).
[MRR 6] 7.4.1
This clause says that policy groups are registered by
``community groups or private organisations''.
The clause should be clearer about the requirements for
registration. For example, does ISO need to establish a
registration authority for policy identifiers? (It
probably does not, but the text should make this
explicit),
[MRR 7] 7.4.2
The policyID field of the AuthorityConstraints extension
should be of type Policies, not PolicyID. This would
simplify the case where exactly the same constraints
apply to several different policies.
[MRR 8] 7.4.2
The AuthorityConstraints extension should be split into
several separate extensions.
Rationale
This extension contains many fields with very complex
semantics. Many security domains will only require
support a few of these fields. If this extension is
split, it will be possible to implement a subset of the
fields.
In particular, nextCertConstraints should be a separate
extension, as the recursive nature of this constraint
makes it complex to process.
SubsequentCertConstaints ::= SEQUENCE {
policies Policies OPTIONAL,
constraint NextCertConstraint
}
NextCertConstraint ::= SEQUENCE {
constraintSet ConstraintSet,
nextCertConstraint NextCertConstraint
}
Handling nextPolicy as an extension would enable better
handling of the case where exactly the same constraints
apply to several policies, but each policy is mapped to a
different identifier in the certificate subject's
security domain.
PolicyMappings ::= SET OF SEQUENCE {
issuerDomainPolicyIdentifier Policies, -- several
policies may map to the same policy
subjectDomainPolicyIdentifier PolicyId
}
-- The policy mappings extension is not critical; object
identifiers are globally unique, so
-- ignoring the mappings will never cause a certificate
to be misinterpreted (although it may
-- cause a certification path to be rejected, because
the policy ids which should have been
-- mapped are not known to the verifier).
[MRR 9] 7.4.2
The ASN.1 definition of ConstraintsSet is illegal, as
several OPTIONAL fields with the same tag are used in the
SEQUENCE. This can be fixed by using context-specific
tags.
[MRR 10] 7.4.2
There should be a constraint which allows the certificate
subject to sign user certificates, but not CA
certificates.
Add the following to ConstraintSet:
certForCAPermitted [n] BOOLEAN DEFAULT TRUE,
certForUserPermitted [n+1] BOOLEAN DEFAULT TRUE,
[MRR 11] 7.4.2
Under some policies, the constraints on the algorithms
used by CAs will be different from the constraints on
algorithms used by users. (e.g. if CAs are required to
use longer keys).
The chainAlgorithmConstraint should be split into two
constraints, one for CAs and one for users.
chainAlgorithmConstraint [n] AlgorithmConstraint
OPTIONAL,
userAlgorithmConstraint [n+1] AlgortithmConstraint
OPTIONAL
[MRR 12] 7.4.2
The chain key usage constraint is not really a ``chain''
constraint, as it only applies to the last certificate in
the chain. Hence its name should start with something
other than ``chain''. Also, its syntax should be
UserKeyUsage rather than KeyUsage, as it only applies to
user keys.
userKeyUsageConstraint [n] UserKeyUsage OPTIONAL
[MRR 13] 7.4.2
The current proposal of using an AlgorithmIdentifier for
algorithm constraints will be problematic for some
algorithms. If the AlgorithmIdentifier parameters
includes a length (as is done for RSA, for example) this
would require this constraint to specify a particular key
length. It would better to be able to specify a range of
key lengths.
If the AlgorithmsParameters includes some keying
information (as done for DSA) then the CA which creates
the constraint may not know this keying information for
Cas further down the chain.
Proposed replacement:
AlgorithmConstraint ::= SET OF SEQUENCE {
algorithm OBJECT IDENTIFIER,
minimum ANY DEFINED BY algorithm OPTIONAL,
maximum ANY DEFINED BY algorithm OPTIONAL
}
minimum and maximum will usually be the key length in
bits, but for algorithms where this is not appropriate
they can be some other indication of strength (e.g.
number of rounds).
Above, I have used the old ASN.1; the new information
object notation should be used in the published standard.
[MRR 14] 7.5
``(b) Check that the KeyUsage field permits CA
signature''
This field is an extension, and so is not always present.
This bullet point should say that if the KeyUsage field
is absent, it should be treated as if a KeyUsage field
permitting CA signature is present.
[MRR 15] 8.2
The ASN.1 type HoldInstruction and the value id-none are
used but not defined.
[MRR 16] 8.2
``for one issue cycle only''
If a ``pull' rather than ``push'' model is being used for
CRLs, then the notion of an issue cycle becomes
meaningless. The verifier may happen to miss the CRL that
contained the certHoldRelease.
It would be better to say that a held certificate is
released by a CRL with a later issue date which does not
mention that certificate.
[MRR 17] 9.1
``All signatures issues by the user before this date will
be recognised by the user as valid.''
Note that in some cases notarisation may be required to
demonstrate that the signature really was created before
this date (and it isn't a forged signature back-dated by
the attacker).
[MRR 18] 9.1
``The presence of this optional date within a CRL entry
might be made mandatory when the key of this certificate
is used for a non-repudiation service.''
How does the CA know what the certificate is being used
for? What happens if the certificate is used for non-
repudiation, but the CA doesn't know this, and hence
doesn't realise that this field has become mandatory?
It would better to say that this field might be made
mandatory where the key usage field permits non-
repudiation. The CA has signed the original certificate,
and so knows what the key usage field was.
[MRR 19] A.1
The example value of AuthorityConstraints does not use
the correct ASN.1 value notation