On 10/08/2018 13:02, [email protected] wrote:
On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
<[email protected]> wrote:
I want to emphasize that each and every value of certificate Subject have
always been verified. It's wrong to say that those values are unverified.
It is only a question about E verification method and quality. Our method
has been to estimate visually by Registration Officer if each E value (or
other subject value outside common group C,O,ST,L, streetAddress,
postalCode) is correct for this Customer.
What are you visually validating though? That it's an email address? That
it's owned by the Subscriber? By comparison, what does it mean to "visually
validate" one of those other fields - are you using some registration
service? Some form of validation (e.g. sending an email)?
I think it's fair to say that these fields aren't validated, if your
process is just that the RA looks at it and says "sure"
Our CPS has previously defined our E verification process like this: "The
Registration Officer is obliged to always review all subject information and initiate
additional checking routines if there are any unclear Subject values. Domain name
ownership of domains in email addresses may belong to another company than the applicant
e.g. to some service provider."
We believe that E value is supposed to be Applicant server’s support email
address. It is very hard to for CA to be sure that the provided address is
exactly such address. In some cases our customers have used personal addresses
and in some cases service provider addresses. We have accepted both.
Technically we’ve verified that email address follows emailAddress format
specification. Visually we verify that the email address look like normal
support email address for the Applicant. If the verifier
can't be sure in the visual verification he/she must escalate the verification to our
Security team. They will check e.g. that the email address domain is owned by the Applicant
or that Applicant confirms the address to be their support email address. Even though our
verification isn't very strong it is a two-phase verification: syntax and visual. Because of
the weakness of our method we wanted to open this discussion to understand what BR creators
have meant when they have formulated the E validation requirement using only these words
"MUST contain information that has been verified by the CA", nothing else. And why
openssl is using E as a default subject field in its CSR generation for SSL certificates if
that value is not supposed to be inserted to SSL certificate. Our interpretation of BR text
has been that E value verification has no exact requirements and any reasonable verification
(including our technical&visual verification method) is enough.
Registration Officer training has instructed which E values must be
rejected. It is not possible to use visually similar kinds of characters
because we technically restrict Subject characters to common ASCII
characters (e.g. nulls are rejected). It is completely incorrect to claim
that any values are added without validation. Since Feb 2018 Telia also
techically prevents any other values than C,O,L,OU,E,CN from inserted to
SSL certificates. Since that the simple visual verification has been valid
only with OU and E (others have be very rare always). In addition all Telia
SSL certificates have always been also post-examined (visually) after the
enrollment to be absolutely sure that no incorrect subject values have
passed our validation (second person evaluation).
I think this is really good information - it suggests that prior to Feb
2018, those other fields from the CSR may be copied over.
If it helps, think about something like "Country" or "Organization". Visual
validation just says "Yeah, this is probably right", while actual
validation involves making sure it's a valid ISO country code (in the case
of C) or that the Organization is actually affiliated with the Applicant
(in the case of O). Hopefully that distinction makes it clearer?
The listed validation examples won't help us very much because the described C
verification is basically the same what we have done in our technical E value
verification (that the value is legal). Examples aren't relevant because both C
and O have quite clear verification specification on BR. E verification instead
has't been properly specified in BR.
I understand your opinion that this kind of visual verification is not as
strong as technical email verification with random codes. However, random
code verification is not written to be required by BR. BR only states in
7.1.4.2.2.j: "All other optional attributes, when present within the
subject field, MUST contain information that has been verified by the CA."
In my opinion we have followed that requirement because we have had a
verification method for those values; do you disagree?
I think this is the point that I'm trying to understand - what those
verification methods were and how they were assessed to be correct for the
field. We've discussed emailAddress, but it sounds like prior to Feb 2018,
this may have included other fields (besides OU and emailAddress). Have you
examined and reviewed the past certificates for that?
We have now re-verified from CA database that we have never used the described
weak visual verification to any other field than E and OU.
Next we are ready to stop adding E values completely to solve this issue
permanently but we think it is not right to require us to revoke all our
old E values.
Why is that? What was actually validated for those emailAddresses? Just
that the RA thought it 'probably' was correct for that Applicant?
Because all our old E values have been verified using the two methods I have
explained in this discussion: both technically and visually. Those methods
verify that each E value is technically OK (compare this to your C example) and
each value looks like a proper support email address for that applicant. Our
instructions for visual E verification were that the address should not look
like company name and should not otherwise cause uncertainty.
Verification examples:
Abc – Rejected by technical Telia E verification (not a valid email address)
Telia@ab – Rejected by visual Telia E verification (attempt to use E value that
looks more like O)
[email protected] – Accepted by all Telia E verifications
BR does not specify how E verification should be done so in our opinion you
cannot reasonably expect us to use any specific other verification methods. BR
text should be modified if only some specific E verification methods were
accepted. In our opinion E values aren’t significant for the safety of
certificates (many browsers hide them anyway) so this change to BR text is not
necessary. If any modifications are done then PKI community should estimate
what is the correct required verification level, e.g. E won’t look like company
name, E domain is owned by the company, E is able to give answers, E owner
accepts the value to be used generally in certificates, or only for this
applicant, or only for this specific FQDN list, or perhaps that E owner is able
to give support. People may have different opinions. In our opinion any method
that may delay certificate application acceptance is problematic and very few
methods are thus suitable in practice.
This doesn't even try to validate that the E value is factually *true*,
which is the entire point of a certificate (all signed fields have been
verified as true). The field with the weakest requirement is the OU
value, here it is often enough to validate that the applicant as an
organization has the inherent authority to define its own organizational
units in almost any way that isn't outright deceptive.
A common validation technique (but not the only one possible) is for the
e-mails regarding issuance, issuance questions etc. to be sent to that
e-mail address. With CT logging active, something more needs to be done
to ensure the applicant actually receives such e-mails and doesn't just
grab the issued certificate from the CT log or some other alternative
means.
Examples of how other fields are commonly validated (some are explicitly
specified in the BRs or Mozilla policies, others are just covered by the
general rule of validated truth):
Certificate serial number, issuer distinguished name, certificate
signing algorithm, policy OID: Known first hand (and chosen) by the CA.
Subject public key: Applicant has proven possession of the matching
private key by signing a CSR with it. CA validates that it is
mathematically sound (key length, numerical properties, encoding etc.).
Each DNSName SANs: Applicant has proven actual control over the DNS
contents and/or a web server on that address.
Each IPAddress SANs: Applicant has proven actual control over a web
server on that globally routable address.
Country: Applicant is actually located in that country and other
location fields are validated within the context of that country.
JurisdictionOfIncorporation: Official records show that applicant is an
actual company or other organization formally created in that
jurisdiction (even if not located there). For example, ABB may be
formally incorporated in Switzerland (CH), but the certificate is for a
division in Denmark (country=DK).
Serial Number name element: Official records show that this is the
official company registration number in its JurisdictionOfIncorporation.
Location and Street address: Official records show that the organization
is actually located there and/or PostNord can deliver a letter or
package with a confirmation code of some kind to the organization at
that address, and/or the organization similarly receives a phone call on
a land line which Telia has themselves installed at that physical
address, and which Telia internal data confirms isn't being forwarded to
a different location during that call.
Organization Name: Official records confirm that this is the legal name,
plus/minus a CPS enumerated list of notational variations such as
writing ae, aa, oe instead of äåö omitting the AB suffix of a company
etc.
Common Name: For SSL/TLS certificates, this should be a copy of one of
the DNSName SANs, Plus/minus the ongoing debate if this must be the
punycode or standard encoding of an IDNA name. For e-mail certificates
issued to natural persons, this should be their legal name, again
subject to some notational variations enumerated in the CPS.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
