Mike:
Please find enclosed my comments on the certificate extensions working
draft.
Thanks, Mike. In general I agree with your comments. Following are
those on which I have additional comments.
[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.
Yes, that's true. The reason for combining these is to reduce the
encoding overhead. For those domains that support both, we save quite
a few bytes in the certificate.
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.
You are right that Key Usage could be critical, if it is the CA's
intention that this be a constraint on the use of the certificate.
However, another use of the field is simply as an aid in finding the
right key for a DN, for use in some particular situation. In this
case, the extension in non-critical. Perhaps we should allow this
field to be either critical or non-critical. If so, it would be best
split from Key Identifier as you suggest.
[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.
This document assumes AUTOMATIC tagging, which is the usual default for
contemporary ASN.1 specifications. The context-specific tags will be
added automatically, without we spec-writers having to worry about
them.
[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).
Personally, I agree with you. This distinction should not be made,
unless a clear definition is provided.
[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).
OK. What wording do you suggest (to describe the style of control
provided by such schemes as PEM name subordination)?
[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),
OK. The intention is that a policy can be registered by any
organization able to assign an object identifier.
[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).
Yes, I generally agree. But we don't want to split into too many
different extensions, for coding efficiency reasons.
[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.
See my response to MRR 2.
[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.
Is there really a requirement to go to the lengths you suggest? (I am
not fully convinced of the importance of algorithm constraints at
all.)
Warwick
???????????????????????????????????????