Bonjour Peter,
Le dimanche 12 avril 2015 09:32:40 UTC+2, Peter Gutmann a écrit :
Erwann Abalea eaba...@gmail.com writes:
That's really an OID, in the Microsoft arc. I don't know what triggered the
Error: OID contains random garbage message,
Uhh, the fact that it contains random garbage encoded as an OID?
Well, since a set of numbers that has no clearly identifiable meaning for an
outside user can reasonably be considered as random, the OID contains random
garbage part of the message is right. But that doesn't mean it's an error.
This OID is correctly encoded, the fact that it contains somewhat random
looking integers isn't an error
Taking Microsoft's own words (from
https://msdn.microsoft.com/en-us/library/windows/desktop/bb540791%28v=vs.85%29.aspx):
The individual elements in the string, separated by periods, represent the
arcs and leaves in a registration authority tree that uniquely identifies
the object and the organization that registered it.
could you perhaps explain to the class which arcs and leaves in a registration
authority tree [...] 3675690 6234259 10436751 12227305 62135 141 959321
10252252 represent?
Sure. The 1.3.6.1.4.1.311 is Microsoft's OID arc. 1...311.21 is declared as
Microsoft CertSrv Infrastructure, and 1...311.21.8 as The root oid for all
enterprise specific oids.
The rest may be known only by the Registration Authority, the publication of
the complete arc isn't mandatory. Not knowing the exact meaning of this suite
of integers doesn't mean this meaning doesn't exist. Microsoft may really
maintain a complicated OID tree for that purpose, who knows? And even if those
number are randomly allocated, they still can have a meaning, and the OID can
still identify something.
[2 SEQUENCE full of zeros]
This is required by the CABF BR.
If this gibberish is required by the BR then there's an awful lot of
noncompliant certs out there. Pretty much all of them, I'd say.
This is required for technically constrained CAs not allowed to issue
certificates with an iPAddress. See CABF BR section 9.7.
The fact that this encoding is full of zeroes isn't a Mozilla/CABF/GlobalSign
issue.
A technically constrained CA allowed to issue certificates with an iPAddress
won't have this part. And of course a non technically constrained CA won't have
this entire extension.
[S/MIME capabilities extension]
That could fall under CABF BR Appendix B (4) (a) rule.
Even if I hold the BR doc sideways and squint at it, I still can't see where
in B (4) it says the CA has to include an S/MIME extension for 1970s and 1980s
crypto algorithms in a TLS server cert. In particular the wording:
The CA SHALL NOT issue a Certificate that contains [...] unless the CA is
aware of a reason for including the data in the Certificate.
CAs SHALL NOT issue a Certificate with [...] unless the Applicant can
otherwise demonstrate the right to assert the data in a public context;
basically says CAs SHALL NOT do X except that they can if they want.
I wasn't saying that the CA has to, or could include such an extension. Quite
the contrary, in fact.
Declaring S/MIME capabilities for a TLS server cert is inconsistent.
No upper limit is imposed by the standards.
There's also no law specifically saying that you're not allowed to stagger
around in public complaining that the sun is too loud and warning people about
the ice weasels, but that doesn't mean that it's not a sign that something's
gone seriously wrong somewhere.
(That may change in Florida, where officials are not allowed to use the terms
global warming, or climate change)
Ok. Why should the CABF put a limit (on the number of domains) above which the
CA MUST either:
- have several CA certificates, or
- pass a yearly audit
(by why, I'm questioning the security benefit of such a restriction on the
constraint)
Where should the CABF set the limit to?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
