Doug, in similar cases a standard (like BR) would list the
referenced/incorporated requirements/rules under the "Normative
documents" section.
Maybe we should add this to BRs?
Thanks,
M.D.
your question leads to another another question: should we list those
external documents that have "normative" impact on BRs
On 2/25/2016 10:30 PM, Doug Beattie wrote:
Good questions Jeremy.
I hate to ask, but is rfc 5019 another RFC that must be met in order
to be BR compliant, and will any errors there be warnings or full
audit findings? There are a lot of rules about cache values which we
might not be all compliant with.
https://certificate.revocationcheck.com/
*From:* [email protected]
[mailto:[email protected]] *On Behalf Of *Jeremy Rowley
*Sent:* Wednesday, February 24, 2016 1:56 PM
*To:* [email protected]
*Subject:* [cabfpub] RFC5280
I’ve been playing around with Peter Bowen’s certlint (an excellent
tool) and, looking at the cert universe as a whole, there are some
noticeable issues with the BRs and RFC 5280 that I though merited a
public CAB Forum discussion. Some of this is likely me not knowing
the entire history of 5280, so I appreciated any explanation. If
there’s exceptions we would like to make to RFC5280, we should
probably also push a bis with IETF at the same time.
Here’s what I’m noticing are common issues:
1)Org names, common names, and address fields are limited to 64
characters. Very few international companies can comply with this
restriction. It’s even worse if you are converting an IDN to a
printable string. I don’t think any browsers limit this to 64
characters? Is there a strong objection to permitting longer strings
in these fields?
2)keyAgreement isn’t specifically prohibited in the BRs or 5280.
However, keyAgreement should no longer be used in ECC certs because of
security issues as explained by Ryan Sleevi in previous emails . We
should update the BRs to prohibit keyAgreement.
3)Years ago, we discussed that 2047 bit certs were equivalent to 2048
bit certs (although the discussion may have occurred solely on the
Mozilla mailing list). We should codify this exception.
4)Why is teletext string not permissible on a lot of these fields? I
also don’t understand the weird requirement to use printablestring
over UTRF8 for some fields. Specifically, requiring a printable string
for subject:serialNumber could cause issues with the EV Guidelines if
a country uses an IDN as part of their registration number.
Thoughts?
Jeremy
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public