Care to join me as coauthor of an Internet Draft?
OK.
Please don't re-use the tags - issuerAttributes and subjectAttributes should
have different numbers.
I'm not sure that I understand you here. Are you suggesting that if I want to
use an existing attribute, say description, that I should have to create one
or
two new attributes, subjectDescription and issuerDescription? I hope not!
I'll grant that my knowledge of ASN.1 is far from comprehensive, but surely
we can tell the difference in the usage?
No, not the attribute type object identifiers. The tags are the digits inside
"[" "]" in front of members of SET, SEQUENCE and CHOICE. The flavor used
here, context-specific tags, are needed to differentiate between elements which
are optional and have the same encoding. Thus all tags inside a SEQUENCE must
be unique.
Leaving the X.500(1988) and X.500(1993) tags in place allow for all three
styles of certificates to be handled easily. (Also have version default to v1)
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- if present, version must be v2
subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- if present, version must be v2
issuerAttributes [3] IMPLICIT Attributes OPTIONAL,
-- if present, version must be "v3"
subjectAttributes [4] IMPLICIT Attributes OPTIONAL
-- if present, version must be "v3" -- } }
Are you suggesting that when I said
... [IssuerAttributes and SubjectAttributes are both SETs of the same
SEQUENCE] ...
I really should have said
... [IssuerAttributes and SubjectAttributes are SETs of SEQUENCEs with
different names but similar definitions] ...
If so, I would be happy to make the change, but I don't understand the
reason why.
No, those two would have identical encodings. The text isn't sent on the wire,
but the tags are, and this allows for the differentiation of data structures.
Furthermore, IssuerAttributes and SubjectAttributes can probably be just the
same type (Attributes ::= SET OF AttributeTypeAndValue).
Also consider that the ITU, after defining
Certificate v2 might decide to define its own Certificate v3, and this would
result in significant confusion. Why not make this version 1972825?
Well, because I was not too subtly trying to put pressure on the X.509 folks
to adopt this suggestion. But if this certificate format is registered under
the IANA, the NADF, or elsewhere with its own OID, do you really think that
confusion would result?
If both IANA & ITU-TSS defined Certificate v3, they would probably be in
different X.500 attributes.
There would probably be confusion in people mind's as they try to keep track of
whose v3 this is.
It would to me give the impression that IETF & ITU would be fighting over
protocol definitions. [As would ITU-TSS coming out with a recommendation
stating that they have decided X.25 will be the choice for IPng.]
As IETF isn't the only organization that could be recommending changes to
X.509, there shouldn't be assumptions that this definition could be adopted as
is. Suppose at time X an RFC was published and people started creating these
"v3" certificates. However, if ITU-TSS at time Y republishes X.509 including
these changes as well as others into the certificate format and calls that
"v3" (as it seems to me it has a right to do so), then anything which happens
between X and Y needs to be changed.
An excerpt from an ISO document in a message sent to pem-dev last August,
| A NP has been established for extending the definition of the security
| certificates defined in ITU-TS Recommendation X.509 | ISO/IEC 9594-8. It is
| expected that these extensions will provide:
|
| * better support for non-repudiation requirements
|
| * the ability for certificates to hold multiple algorithms and keys. For
| example, the algorithm identified for confidentiality may be weaker than
| that identified for integrity or authentication.
|
| * more flexibility is extending certificate by providing extensibility
| mechanisms to allow the addition of both standardized and proprietary
| extensions to certificate definitions. This mechanism would allow a user
| of a certificate to ignore unknown information in the certificte if
| permitted by policy.
|
| National bodies and liaison organizations are asked to provide contributions
| into the next Directory meeting in January/February of 1994.
(Did you pick 1972825 for some reason I missed, or was this just a large
random number?)
Just a random number...
Presently, the ITU and various pilot projects are busily
creating new attributes as people discover that X.520/X.521 doesn't really
satisfy their needs.
Well, I don't think X.520 was ever intended to be a complete list...
(What then happens to the older attributes? And how should software such as
certificate creation programs "know" to migrate to the new standard?)
You might want to take a look at Internet draft OSI-DS 36 by Colin Robbins,
"An Aliasing Mechanism for Object Identifiers", which describes how this is
treated in one implementation.
(Another possibility would be to set the Obsolete flag in the
AttributeTypeDescription to deprecate its further use, but this conveys no
useful information as to what the replacement should be. It seems to me, then,
that the AttributeTypeDescription is in a sense broken, and that if the
obsolete flag is set that there should be a seeAlso attribute present. This
would serve as a pointer to the new attribute that replaces the old, or at
least some text that explains what is going on.)
(Do you agree? If so, is there some mechanism whereby we can report this as a
defect?)
This sounds like a valid point for all the subschema policy attributes.
4. It seems to provide a means of supporting X.500 strong authentication,
PEM, and other forms of certificate-based authentication with a common
identity validation mechanism.
I'm not sure what you mean for the X.500 case - what is the advantage over an
X.509(1993) v2 certificate?
Presumably the ACL implementation
would record who is allowed to change what attributes, instead of providing
"rights" within the certificate itself -- I just don't know.
It appears to allow the specification of "this attribute may be modified by
any of these listed (user + unique identifier)".
Don't forget to include the pemCRL attribute type, which has a syntax but not
a defined OID.
Interesting! How have people been coding this attribute, then?
In PASSWORD Report 2.5 Michael Roe writes:
| In order to store PEM revocation lists in the Directory Service, it is
| necessary to define some new attributes and object classes. We intend to
| register these as extensions to the COSINE/Internet naming architecture
| [RFC 1274]. At the time of writing, these definitions have not been
| registered and so have not been assigned unique identifier values.
I've seen it in OSISEC as
{ ccitt(0) data (9) pss(2342) ucl(19200300) pem(109) pemAttributeType(4)
PEMRevocationList(1) }
and SECUDE as
{ iso(1) identifiedOrganization(3) teletrust(36) teletrust-attr(4) pemCRL(1) }
Others using PEM and X.500 have probably defined OIDs for it as well.
Are you suggesting that this should be included in an ID? Or was this just a
reminder to the IANA or whomever that this still needed to be registered?
Probably this ID would be a good time to define the attribute types
and object classes which include the PEM certificate and CRL formats underneath
the internet tree { iso(1) identifiedOrganization(3) dod(6) internet(1) }.
-------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk; Univ.
Coll. London