On su, 12 huhti 2020, Fredrik Arneving via FreeIPA-users wrote:
Hi Rob,
Thank you for answering. Though it would probably make the signing pass
it's not my preferred solution. A lot of this is new to me but here's
my thinking. Please feel free to add links and suggestions.
According to RFC3739, section "3.1.1 Issuer", the issuer field SHALL
(yes, it's capitalized in the RFC) identify the organization issuing
the certificate. Further, the distinguished name of the issuer should
be specified using a subset of
- domainComponent;
- countryName;
- stateOrProvinceName;
- organizationName;
- localityName; and
- serialNumber
Shuld I make the organizationName optional or supplied it will only
leave the countryName as a match and I don't think that qualifies as
"appropriate subset".
Looking at section "4.1.2.4 Issuer" in RFC5280 (replacing RFC3280)
they talk about "DirectoryString" with a choice of encodings where
PRINTABLESTRING and UTF8STRING are the two conforming to the RFC with a
couple of exceptions for older environments.
When I read this I draw the conclusion that a freeIPA server added as a
sub-CA to an existing PKI-infrastructure can run into a CA which
expects the "organizationName" to be encoded in either PRINTABLESTRING
of UTF8STRING. To make it as flexible as possible it should be possible
to configure this in some config file (that would be preferred from
digging into the code).
I don't get many hits when googling this problem which gives me a bad
feeling that I am missing something obvious. Any hints would be greatly
appreciated.
Should I not find a solution for this I have to go with the CA-less
installation and write all my certs manually which would be a lot more
work than to have the freeipa server doing it.
When you ask FreeIPA installer to generate a CSR for signing by an
external CA, the actual CSR is created by NSS library with the help of
Dogtag's pkispawn utility which configures an actual request submitted
into NSS database used for the IPA CA storage.
So, pkispawn ends up running 'certutil' command with corresponding
parameters to generate a certificate request. Certutil will do parsing
of the provided certificate's subject and will end up using organization
name from there.
The logic for choosing encoding for organization name is actually the
same as for any DirectoryString element and it follows RFC 4630. I'm
going to show it here in all its C glory because it is short and easy in
lib/certdb/alg1485.c, ParseRFC1485AVA function:
if (vt == SEC_ASN1_DS) {
/* RFC 4630: choose PrintableString or UTF8String */
if (IsPrintable((unsigned char*)valBuf, valLen))
vt = SEC_ASN1_PRINTABLE_STRING;
else
vt = SEC_ASN1_UTF8_STRING;
}
In other words, if your organizationName value can be represented in
ASCII (isPrintable), it will be represented in ASCII. If not, then UTF-8
will be used.
Historically, this place was known for debates in certificate-related
communities. You can see the bug
https://bugzilla.mozilla.org/show_bug.cgi?id=329067
which led to the current logic in NSS.
Neither FreeIPA nor Dogtag have control over this behavior. If you
consider that NSS violates the logic described in RFC 4630, please raise
this with NSS development team at bugzilla.mozilla.org.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
