DN attributes to be supported

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Marc, I think we are in violent agreement.

>> [ ... ]
>> 
>> (3) I would strongly recommend we add the X.520 definition of streetAddress 
>> to the list of RDN types that constitute the minimal schema for certificate 
>> processing code, including directory/respositories.  Implementing it within 
>> a CA should be optional, but recommended.
>> 
>
>I don't have any problem with requiring support for a particular attribute
>(although I'd like to see the list kept reasonably short).  However, I think
>it's important to emphasize that this support is at the _software_ level.
>That is, PKIX should not mandate that certificates with DNs contain these
>attributes.
>
Yes!  Certainly not all certificate require them. but some will, and Iwant to
make sure that the rest of the infrastructure can handle such attributes.

It's an interoperability issue.

>By mandating DN attributes, PKIX locks in particular directory structures 
>that are by no means "standard".  Even though some of these attributes might 
>have some kind of defacto status, I think it's far too early to start 
>limiting the possibilities.
>
Nor do I mean to limit the possibilities to just those. I just want to make sure 
that a reasonably short, but still minimally useful set is supported universally.

>If PKIX even appears to mandate DN attributes, I think it'll touch off 
>problems even bigger than the UTF-8 issue.  It's one thing to say that 
>PKIX-compliant software SHOULD (never MUST) support certain DN attributes, 
>but it's another thing altogether to relegate to non-compliance(*) any 
>certificate with a DN that doesn't contain an attribute from The List.

No that wasn't my intent at all. Mandate support for, not inclusion of.
>
>That said, I think section 4.1.2.4 should _not_ recommend that issuer names 
>contain only the specified attributes.  Rather, the second sentence of the
>paragraph that begins with "Standard sets of sttributes..." should be 
>changed so that the paragraph reads
>
>   Standard sets of attributes have been defined in the X.500 series of
>   specifications.  Implementations of this specification should be
>   prepared to process or create certificates with issuer names that
>   contain the following attribute types: country, organization,
>   organizational-unit, distinguished name qualifier, title, locality,
>   state or province name, common name (e.g., "Susan Housley"), surname,
>   given name, initials, and generationqualifier (e.g., "Jr." or "IV").
>   The syntax and associated object identifiers (OIDs) for these attribute
>   types are provided in the ASN.1 modules in Appendices A and B.
>
>I don't mind if streetAddress is added to this list.
>
I would even say that the X.520 list may well be insufficient for some purposes, 
so the reference to "standard" sets of attributes probably goes too far.

>		Marc
>
>(*) There's got to be a verb for "relegating to non-compliance".  
>Discomplying?  Deconforming? ...

Deprecated?  Decertified? Despised?

Bob