Hi Warwick,
We are revising this material this week ...
Here's a few comments then. The version I have is from Nov. 6th, I hope
that's the latest.
Regards,
Stephen.
The extension fields are designed for use in an automated
self-contained implementation of certification chain
processing logic. No local user interaction is necessary
and no accesses to trusted local databases are required,
beyond the need to obtain a trusted copy of an initial
public key.
There is a little more needed locally:
- the Name associated with the initial public key
- the current time should also be trustworthy
f) There is a need to be able to tag keys with indicators
of privileges associated with their use. The semantics
associated with tags need to be based on privately
registered schemes not subject to standardization.
If the privileges are defined privately, then why standardise
PrimaryKeyPrivileges? A set of flags is certainly not suitable for
carrying all privilege information (e.g. role, group-memberships, etc.)
I would suggest one of the following (with the first preferred):
- delete PrimaryKeyPrivileges since everyone has to define
their own anyway (and can then make up some extensions), or,
- make it more specific (on the assumption that the BIT STRING
is a suitable syntax for someone), or,
- make it more generic, i.e. change it to:
PrivilegeSyntax ::= SEQUENCE {
privilegeAuthorityId OBJECT IDENTIFIER,
privilegeValue OCTET STRING }
I have the same comment about the two privilege fields in the
SecondaryPublicKeyInfo. In any case the two fields should be changed to
one OPTIONAL PrivilegeSyntax (similar to the point made by Peter
Williams about the issuer and serial number earlier).
SecondaryPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
keyUsageRestriction KeyUsage OPTIONAL,
keyAttributes KeyAttributes OPTIONAL,
privilegeAuthorityId OBJECT IDENTIFIER OPTIONAL,
privilegeFlags BIT STRING OPTIONAL,
secondaryPublicKey BIT STRING }
The keyUsageRestriction field seems redundant since the same information
can be included in the keyAttributes field (and presumably not both?)
6.2 Certificate Extension Fields
The following certificate extension fields are defined:
...
The EDIFACT ID seems to have disappeared from the list. Is there
a problem with this or is there an X.500 attribute defined
for it already?
c) DirectoryAttributes: This field conveys any desired
X.500 attribute values for the subject of the
certificate. It is applicable to both CA-certificates
and end-entity certificates.
There's a possible problem here. The attributeValue is essentially a SET
OF ANY which may require your ASN.1 compiler to handle DER pretty well - we
use one quite good ASN.1 compiler which doesn't support DER ("not enough
people have asked for it").
I don't have a solution other than to avoid multivalued attributes -
perhaps someone who knows X.500 better could comment?
ClearanceSyntax ::= BIT STRING {
topSecret (0),
secret (1),
confidential (2),
restricted (3),
unclassSensitive (4),
canadaProtectedC (5),
canadaProtectedB (6),
canadaProtectedA (7),
companyProprietary (8),
unclassified (9) }
X.411 defines another possibility which is "unmarked" as one possible
SecurityClassification. I understand this to mean "one of the above, but
we're not saying which". Certain policies (e.g. STANAG 4406) require
that this be handled differently from unclassified.
PolicyMappingSyntax ::= SEQUENCE OF SEQUENCE {
issuerDomainPolicies PolicySet,
subjectDomainPolicy PolicyId }
Is there any need to distinguish the subjectDomainPolicy in the above?
The extension seems to be asserting that the cert issuer considers that
all the OIDs are equivalent so I can't see why we care who issued them.
7.4.3 Authority Constraints Field
This extension field is applicable to CA-certificates only.
It specifies a set of constraints to apply with respect to
certificates issued by the CA that is the subject of the
immediate certificate and/or constraints to apply throughout
the subsequent chain.
This is still too complicated for me to sensibly comment upon:-( Would
it be possible to define various simpler profiles of this as separate
extensions? Also, what if there are two of these present in one
Certificate? Must both be satisfied or only one?