6:29 p.m.
On 08/15/2013 09:47 AM, Ade Lee wrote:
Couple of questions:
1. I am assuming that ":" is not a valid character in each of the
subject name fields, right?
":" is not on the list of special characters
required to be escaped, so
it is a valid character as names are validated. You can see name
validation in the code.
Keep in mind that this tool modification is added only to test one very
unique incompatibility of some cryptographic libraries which are not
processing subject names in their proper canonical form, which can only
be seen in one corner case of cross signing.
There are few options to introduce encoding types:
1. Introduce encoding types as a separate set parameters.
2. Introduce distinguished name preprocessing, collect encoding types
from preprocessor and distribute them to component name encoders.
3. Use above syntax only if enabled by flag
4. Use above syntax only if prefix includes allowed encoding typesfor
specific name component
Option (1) seems inconvenient and error prone
Option (2) seems a bit expensive for its purpose
Option (3) seems reasonable but new enabling flag seems a bit inconvenient
I believe I selected option (4) but attached the wrong file.
I selected option (4) base on expense and the purpose of this tool.
2. Is the format "cn=UTF8String:aa,ou=BMPString:bb,o=cc" a
standard way
of specifying this type of thing? If not, is there a standard way of
specifying subject names with multiple encodings? (and why would anyone
do that?)
There is no standard way to include encoding for attribute values in
distinguished names.
The main reason here is that distinguished names are defined by LDAP
standards providing strict encoding rules and strict name processing rules.
LDAP is not exposed to our case of cryptographic libraries incorrectly
processing subject names.
3. Right now, if someone puts in an incorrect encoding, the element
will
silently fail to be added to the subject name. Is this what we want?
Do we rather want to throw an exception and notify the user?
This will go away with
option 4.
4. Similarly, in addNameElement, we catch the exception and just
print
out an error message. Do we want to rather bubble up the exception and
abort?
I think that providing error message is more appropriate here.
5. Does it make sense to add logic to addNameElement() to default to
PrintableString in the case that n=0, and then just eliminate the calls
to the old functions?
For example, instead of :
if (split[0].equals("O")) {
if (n > 0) {
ret = addNameElement (ret, Name.organizationName, n, split[1]);
} else {
ret.addOrganizationName(split[1]);
}
// System.out.println("O found : " +
split[1]);
continue;
}
have:
if (split[0].equals("O")) {
ret = addNameElement (ret, Name.organizationName, n, split[1]);
// System.out.println("O found : " + split[1]);
continue;
}
and remove the function addOrganizationName() etc. In fact, it probably
make sense to just compute n in the addNameElement() function, rather
than passing it.
All "name" functions are provided by JSS, which includes
OID to name
mapping and default encoding
To do the above, you would have to duplicate OID to name mapping and
default encoding selection outside JSS, which is an error prone
duplication of functionality.
6. Please add some comments above the addNameElement() function to
describe what is going on. (maybe referencing the ticket number).
Sure.
7. In the diff at least, it looks like the System.out.println()
statements are a little offset. I know they are not in your code
changes, but please fix them while we are there.
I thought those lines are
purposely formatted this way, since all files
were reformatted before.
Thanks,
Ade
On Wed, 2013-08-14 at 17:08 -0700, Andrew Wnuk wrote:
> This patch provides enhancement to PKCS10Client allowing to control
> encoding for components of the subject name.
>
> Ticket #677
>
> More details included in comment #2 of ticket #677.
> Testing procedure included in comment #4 of ticket #677.
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel