As I said in a previous message, the pb also occurs in a string form
like cn=Paul, O=VPN Consortium
Quite true.
I think one might want enhance the normative part of RFC 5280:
The Name describes a hierarchical name composed of attributes, such
as country name, and corresponding values, such as US. The type of
the component AttributeValue is determined by the AttributeType; in
general it will be a DirectoryString.
without other texts of X5xx this is also ambiguous. It doesn't say
how the hierarchy is encoded, etc for name constraints, what
is a subtree (prefix or suffix)? I may have overlooked something?
You have overlooked the fact that this effort is to create a new document, not
to update RFC 5280, which the PKIX group insists is readable enough. I am
well-known for disagreeing, and that is why I think that this new document
allowing constructs that are known security problems is a bad idea.
I didn't not overlook that this effort is to create a new doc. With what
authority do
you say that what the PKIX group "insists"?
Indeed, it might be that you have a server "net.com" and another "com.net"
ah well, the real problem is between Serbia and the UK computer science
departments. Fortunately we have no top level domain www.
I am not saying at all that one should allow an http client to accept DCs
if neither DNS-ID is not present (and no CN-ID). Rather the contrary.
The new document is destined to CAs that fill DNs, and for RPs that
think about it.
If both are reminded about the order defined by the X.500 base
standards, this
is an enhancement. Talking about DCs does not allow anything new that isn't
allowed today. If this text "prohibits" the use of DCs in DNs, then RFC
5280 becomes
somewhat funny because it uses them as examples.
Would an answer to Alexey be: DCs MUST not be used since RFC 5280 does
not define the
order of the encoding of the hierarchy in the normative part of the
text. ???
BTW: Should one speak about jurisdiction and country of jurisdiction
attributes?
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
