Warwick,
Some comments on the PDAM.
Regards,
Stephen.
----- snip, snip -----
p) certificate policy: A named set of policy statements relating to
use of a certificate recognized by both the issuer and user of the
certificate. Typically, different certificate policies will relate
to different applications which use certified keys.
I think some more realistic examples of policies would be helpful.
Escpecially since it says later that policy mapping will only be
possible for simple certifiate policies.
CAKeyUsage ::= BIT STRING {
keyCertSign (0),
offLineCRLSign (1),
transactionSign (2) }
i) transactionSign: for a CA to sign on-line administration
transactions.
I'm not sure what this is really for. Does it indicate that the CA uses
this key whilst on-line? If so what combinations of bits in the
CAKeyUsage are meaningful. (Maybe offLineCRLSign is just a poor name,
since it doesn't mean that the CA was off-line?)
12.2.2.5 Policy mappings field
This field, which is for use in CA-certificates only, allows a
certificate issuer to indicate that one or more of that issuer's
certificate policies can be considered equivalent to another policy used
in the subject CA's domain.
Is there any other reference to a "CA's domain"? It might be a useful
thing to define. (How about saying that the CA's domain is specified by
a set of {SubTreeSpecification,CertPolicyId} pairs?)
AltName ::= CHOICE {
rfc822Name [0] IA5String,
dNSName [1] IA5String,
x400Address [2] ORAddress -- Imported from X.400 --,
privateName [3] INSTANCE OF PRIVATE-NAME }
Would it be possible to make AltName a SEQUENCE OF (the same) CHOICE? In
the SESAME project we associate more than one dns type name with a
single certified key. With the current definition we'd need a bundle of
extension fields of type AltName. It'd be more efficient to put them all
in one extension. Another reason is that some people (me included) have
both rfc822 and X.400 addresses.
The definition would then be:
AltName ::= SEQUENCE OF CHOICE {
rfc822Name [0] IA5String,
dNSName [1] IA5String,
x400Address [2] ORAddress -- Imported from X.400 --,
privateName [3] INSTANCE OF PRIVATE-NAME }
NameConstraintsSyntax ::= SEQUENCE OF SEQUENCE {
policySet [0] CertPolicySet OPTIONAL,
-- If policySet is omitted, the constraints
-- apply to all policies for which the
-- certificate is applicable
What if policySet is present?
nameSpaceConstraint [1] NameSpaceConstraint OPTIONAL,
nameSubordConstraint [2] NameSubordConstraint OPTIONAL }
d) A revocation certificate contains, for each revoked certificate,
the date when revocation occurred. This date is insufficient to
solve some disputes because, assuming the worst, all signatures
issued during the validity period of the certificate have to be
considered invalid. However, in a commercial environment, it may
be important for a user that a signed document is recognized as
valid even in the case where the key used to sign the message has
been lost. The presence of another date within the user
certificate can assist in solving this problem - the date when the
user was still sure that his key was not compromised. All
signatures issued by the user before this date will be recognized
by the user as valid.
I'm not too sure of the usefulness of this field. The question is:
Who'd certify it? and if a CA did certify it why should I believe it?
(Also, the word "user" is ambiguous in the last sentence.)
cRLNumber EXTENSION ::= {
SYNTAX INTEGER
IDENTIFIED BY { id-ce 20 } }
This extension is always non-critical. It allows a CRL user to detect
when a CRL was issued prior to the next scheduled update indicated in
^^^^
typo - "when" should really be "that" shouldn't it?
the nextUpdate field of the last received CRL.
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
caCompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
certHoldRelease (7),
removeFromCRL (8) }
I think these need some descriptive text - especially numbers
2, 4, 5 and 8.
- A certificate hold shall remain on the CRL until the expiration of
the underlying certificate or the expiration of the hold, whichever
is later.
The expiration date seems useless at this point. (I know it has a use when
the hold is released.)
invalidityDate EXTENSION ::= {
SYNTAX GeneralizedTime
IDENTIFIED BY { id-ce 24 } }
What's wrong with UTCTime:-) They are the same though, aren't they?
This extension is always non-critical.
12.7 CRL distribution points and delta-CRLs
I have a few problems with the way the distribution points have been
handled:-
1) it assumes that only X.500 Names will be given as "places
to go" - why not dns names also? or X.400 DLs? or rfc822
mailing lists?
2) why bother putting this information into the CRL? I assume
that once you've gotten a CRL you don't care where it came
from.
3) if you do put the distribution point name into the CRL
why make it part of a critical extension?
12.7.3.2 Delta CRL indicator field
This CRL extension field identifies a CRL as being a delta-CRL only.
The following ASN.1 defines this field:
deltaCRLIndicator EXTENSION ::= {
SYNTAX BaseCRLNumber
IDENTIFIED BY { id-ce 27 } }
BaseCRLNumber ::= INTEGER
Is there really a "Base CRL" any more? If so what defines it?
The problem is that a CA will now probably issue a number
of CRLs each time (some short, some long, and to various
distribution points). Which base CRL should be chosen against which
a delta CRL will be compared?
Also, the sentence:
After applying the changes indicated in this delta-CRL to the base CRL,
the result will be a CRL with a CRL number the same as that given in the
CRL number extension of this delta-CRL
seems to imply that a delta-CRL and a "full" CRL will both exist with
the same CRL number. Is this correct?