On 03/02/2017 05:22, Ryan Sleevi wrote:
On Thu, Feb 2, 2017 at 3:59 PM, Jakob Bohm <jb-mozi...@wisemo.com> wrote:
On 02/02/2017 00:46, Kathleen Wilson wrote:
All,
I've added another Potentially Problematic Practice, as follows.
https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL
The encoding of the Issuer field in the CRL should be byte-for-byte
equivalent with the encoding of the Issuer in the certificate; that is,
using the exact same string types and field contents. The specs (RFC 2459,
RFC 3280, RFC 5280) permit them to mismatch, but that causes compatibility
issues with various clients -- in such cases client software might not find
the entry for the revoked certificate in the CRL.
As always, I will appreciate your thoughtful and constructive feedback.
We ran into this situation several times while adding entries to OneCRL
for revoked intermediate certificates, because our script pulled the data
from the CAs' CRLs where possible.
We have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1330968 to
update the OneCRL client to be encoding agnostic when doing the Issuer
comparisons.
What should a CA do if they have used different encodings of the same
issuer DN in different certs that point to the same CRL location?
Wouldn't a more proper set of rules be:
1. The encoding of the Issuer field in the CRL must be the same as in
the SubjectDN in the issuing certificate.
2. The IssuerDN in all future issued certificates must the same as in
the SubjectDN in the issuing certificate.
3. If any previously issued certificates did not follow rule 2, the CA
must publish a list of the exact IssuerDN encodings used in such
certificates.
What value does 3 provide?
It provides data to allow services such as OneCRL (or even direct CRL
checking code in applications) to work around such past practices by
simply using a table of known Issuer name in certificate to actual
subject name in issuing certificate mappings, rather than trying to
implement fuzzy matching algorithms.
The data is minimal and compact, unlike CT logs. The complete dataset
from all public CAs combined is likely to be just a few kilobytes
uncompressed, much less compressed.
Potentially, this same table as a substitute for fuzzy mapping can also
be used when building/following certificate chains.
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
