Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Tadahiko Ito via dev-security-policy]

(From my personal point of view)
I read Google’s paper[1].
For me, that paper’s result could be hypothesized like “some people do care 
about some information, which is written in EV but not in DV”.

That is…
(A) If you click EV indicator, you will able to get more information about 
identity (compare to DV).
(B) If you click page info without EV indicator, you usually only see DV cert’s 
identity information, which does not say much. (number of OV is far less than 
number of DV).

Expected amount of information, from action (A) and (B) is very different, and 
expected information from (B) is small.
So, even if there were someone who is aware of physical identity, He just do A) 
for best effort.

#for me, it sounds more reasonable than “large size of the EV indicator draws 
accidental clicks” (3.2.2 of [1]).

According to above thought, I feel like browser should (at least) 
differentiates 
-DV AND
-OV or EV.
Otherwise, people who do care about information on OV or EV would become tired 
of clicking page info of DV. 
#Do we just need identity on cyber space? I do not think many people would 
agree that.

[1] The Web’s Identity Crisis:Understanding the Effectiveness of Website 
Identity Indicators,  
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/400599205ab5a1c9efa03e2a7c127eb8200bf288.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

[Tadahiko Ito via dev-security-policy]

On Tuesday, April 2, 2019 at 9:36:06 AM UTC+9, Brian Smith wrote:

> I agree the requirements are already clear. The problem is not the clarity
> of the requirements. Anybody can define a new EKU because EKUs are listed
> in the certificate by OIDs, and anybody can make up an EKU. A standard
> isn't required for a new OID. Further, not agreeing on a specific EKU OID
> for a particular kind of usage is poor practice, and we should discourage
> that poor practice.
>

It is good that anyone can make OID, so we do not need to violate policy.

However, I have following concerns with increasing private OIDs in the world.
-I think that OID should be CA’s private OID or public OID. because, in the 
case of a CA is going to out of business, and that business was cared by 
another CA, we would not want those two CA using same OID for different usage.  
-In the other hand, CA’s private OIDs will reduce interoperability, which seems 
to be problematic,
-web browser might just ignore private OIDs, but I am not sure other 
certificate verification applications,
which is used for certificate of that private EKU OID. 

over all, I think we should have some kind of public OIDs, at least for widely 
use purpose.

I believe if it were used for internet, we can write Internet-Draft, and ask 
OIDs on RFC3280 EKU repo.
#I am planing to try that.


Tadahiko Ito
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Questions about Mozilla Root Store Policy 5.1

[Tadahiko Ito via dev-security-policy]

> > This is a great question!
> > 
> > If the certificate is in scope of the BRs (i.e. the intermediate is either
> > I or III), then we know Subscriber certificates MUST have a Key Usage
> > (7.1.2.3(e) of the BRs).
> > >From RFC 5280, Section 4.1.2.3, we know "When the keyUsage extension
> > appears in a certificate, at least one of the bits MUST be set to 1."
> > >From RFC 5280, Section 4.2.1.12, we know that if an EKU asserts
> > id-kp-serverAuth (so (I, II, III)+C), then you're restricted to
> > "digitalSignature, keyEncipherment, or keyAgreement" (those are the only
> > consistent values enumerated)
> > >From RFC 5246, 7.4.2 (and RFC 8446, Section 4.4.2.2), we can also see
> > further restrictions on the allowed key usage bits of server certificates;
> > this is not strictly an issuing prohibition, but worth considering.
> > 
> > We can see through RFC 3279, 4055, 5756, 4491, 5480, and 5758 the relevant
> > keyUsages for a variety of algorithms, such as RSA, DSA, and of course, EC.
> > 
> > If I understand this question correctly, it's asking about whether the MAY
> > of values (X, Y, Z) means SHALL NOT/MUST NOT for values (A, B, C).
> > 
> > One interpretation says "You may set these values... or any other value".
> > The MAY tells clients what they should be prepared for, potentially
> > allowing them to reject any value outside of that if they're unprepared for
> > it.
> > Another interpretation says "These are the ONLY values that MAY be present.
> > You MAY assert one or more of them, but you MUST NOT assert something else"
> > 

it seems we do have ambiguity. I talk with author, and I believe RFC will be 
fixed relatively soon.
 

Tadahiko Ito
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Questions about Mozilla Root Store Policy 5.1

[Tadahiko Ito via dev-security-policy]

On Thursday, March 21, 2019 at 4:27:46 PM UTC+1, Ryan Sleevi wrote:
> On Thu, Mar 21, 2019 at 9:42 AM tadahiko.ito.public--- via
> dev-security-policy  wrote:
> 
> > Hi I have few questions about Mozilla Root Store Policy 5.1
> >
> > Mozilla Root Store Policy 5.1 only permits following algorithms for ECC.
> >
> > > 5.1 Algorithms
> > >
> > > Root certificates in our root program, and __any certificate__ which
> > > chains up to them,  __MUST__ use __only__ algorithms and key sizes from
> > the following set:
> > >
> > > RSA keys whose modulus size in bits is divisible by 8, and is at
> > least 2048.
> > > Digest algorithms: SHA-1 (see below), SHA-256, SHA-384, or SHA-512.
> > > ECDSA keys using one of the following curve-hash pairs:
> > > P-256 with SHA-256
> > > P-384 with SHA-384
> >
> >
> > I am wondering the above is for validation path only, or also for usage of
> > EE certificate.
> > #I thought it might be also for EE cert, since RFC5480 does not require
> > anything on key usage(I descrive detail at the bottom of this text).
> >
> 
> During the discussion in which it was introduced, the goal was two-fold:
> 1) Restrict the set of SubjectPublicKeyInfos to ones supported by Mozilla
> policy and appropriate for Mozilla users
> 2) Restrict the set of SignatureAlgorithms to ones supported by Mozilla
> policy and appropriate for Mozilla Users
> 
> This would apply to all certificates in the certification path. This is
> also why DSA keys (and signatures) are excluded, even though they are
> permissible under the Baseline Requirements.
> 
> A clearer rewording of this section may be to specifically enumerate the
> allowed SubjectPublicKeyInfo AlgorithmIdentifiers (for all certificates in
> the chain) and the signatureAlgorithm AlgorithmIdentifiers (for all
> certificates in the chain). The current language was modeled after the
> Baseline Requirements structure, which similarly conflates these two fields.
> 
> 
> > As far as I understand,  ECDSA public key just show a point on elliptic
> > curve. that point can also be used (plain)ECDH or ECIES.
> > So, if 5.1's description is also for end entity cert, EE cert's key-usage
> > must contain digitalSignature, can contain nonRepudiation, and  must not
> > contain key agreement, key encipherment, etc. to comply 5.1.
> >
> > (question.1)
> > So far I guess, that statement of 5.1 include requirement for key-usage of
> > any EE certs, not limit to server certificates. is it correct?
> >
> 
> To make sure I understand the scenarios:
> A) The EE certificate does not contain an EKU extension
> B) The EE certificate contains an EKU extension, and DOES NOT contain
> id-kp-serverAuth
> C) The EE certificate contains an EKU extension, and DOES contain
> id-kp-serverAuth
> 
> I) The Intermediate certificate does not contain an EKU extension
> II) The Intermediate certificate contains an EKU extension, and DOES NOT
> contain id-kp-serverAuth
> III) The Intermediate certificate contains an EKU extension, and DOES
> contain id-kp-serverAuth
> 
> I break this down, because the following combinations have historically
> been considered "not server certificates": I+B, II+(A, B, C), III+B
> While the following have been considered in scope for policy: I+(A,C),
> III+(A, C).
> Similarly, the issuance practices of I+(A, B, C) and III+(A, B, C) have all
> been considered subject to the BRs; the most notable example of this is
> using SHA-1 to sign EE certificates that aren't server certificates (but
> the intermediate CA's key is capable of issuing them). This is where the
> language "any certificate which chains up to them" comes from.
> 
> Your question - what are the permissible key usages extensions - is similar
> to the I+(A, B, C) / III+(A, B, C) scenario.
> 
> Considering the keyUsage extension specifically (i.e. not considering the
> signatureAlgorithm nor the SubjectPublicKeyInfo algorithm) strikes me as
> fitting in the I+B, II+(A, B, C), III+B scenario. There's a legitimate
> question about whether it should apply in the I+B/III+B scenario (i.e. the
> intermediate is technically capable of issuing TLS certificates, but this
> certificate happens to be not-TLS), but I would think for the II+(A, C)
> scenario it should be OK to declare it out of scope. I'm nervous about the
> II+B scenario, since you could always issue a version of II` that set a
> different EKU...

Thanks to provide me the scope and your concern. 
It seems clear for me. 

> (question.2)
> > In addition, if CA issue ECC certificate without appropriate key-usage,
> > reason to revoke can be non-compliance with Mozilla's root program?
> >
> >
> > RFC 5480 does not seems to require anything for key-usage #since, RFC 2119
> > state  MAY is "truely optional"
> > > RFC 5480ECC SubjectPublicKeyInfo Format   March 2009
> > >
> > >If the keyUsage extension is present in an End Entity (EE)
> > >certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo,