On 01/09/2017 20:07, Ryan Sleevi wrote:
On Fri, Sep 1, 2017 at 2:07 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
...
So, from the get-go with the standards, it was possible to name constrain
DNS. Unless you were referencing certificates prior to them being bound to
domain names, but I can't see how that would be relevant, since the
context
is about DNS names.
Point was that RFC2818 (and RFC2459 which it references for SAN usage)
changed the established interpretation of WebPKI certificates from the
established Mozilla standard. And that this is an obvious precedent to
making such changes.
I'm sorry, this is simply factually false.
That depends on how you interpret the deprecation of matching against CN
only, as was the case at least up to and including Netscape 4.x Browsers
(according to old Netscape documentation listing supported standard and
Netscape cert extensions).
However this whole discussion of the SAN introduction by PKIX was only
intended as an example of how such changes (may) have happened in the
past. It was prolonged by your repeated use of anachronistic references
such as RFC2818.
The primary problem is the need to not weaken security for code that
starts looking at new (or previously unused) name types after existing
PKI restricted CAs have (obviously) not mentioned the "new" type(s) as
"deny all" entries in their name restrictions.
The secondary problem is not to burden such restricted CAs with
additional audit or other compliance requirements when such "new" name
types are added to standards such as the CAB/F BRs and the Mozilla root
program polices.
I gave multiple suggestions on how to avoid both of those.
All but one of your suggestions would require the revocation of existing
SubCA certificates, essentially invalidating all existing uses of
certificates issued by those SubCAs (Each certificate holder would need
to obtain and install at least a new SubCA cert, possibly a complete new
end cert).
Then there is your suggestion of requiring technically constrained
SubCAs (that were constrained under a previous set of relevant name
types) could survive by subjecting themselves to the massive overhead of
satisfying the requirements for an unconstrained SubCA (audits, dual
user authentication, specially secured server facilities, geographic
redundancy, etc.), where as a constrained SubCA they could operate under
normal enterprise internal security rules.
Could you suggest an alternative solution that does not impose such
significant costs?
Indeed, I am just trying to see those very requirements from the
perspective of the already deployed PKI and its subscribers being the
"existing users" for which interop needs to be ensured.
Unfortunately, I do not believe you are succeeding in doing so through
proposing semantic changes.
You seem to be ignoring my actual arguments and arguing only against
specific words and phrases.
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
