Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

[Stephen Kent]

+1

As some other have already said, the charter of the WG calls for 
documenting current

Web PKI practices, not describing what one might wish were true.

Steve


Ben,

I reviewed what I think is the latest draft at 
https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, 
not the Word doc attached to the previous message.


Section 2.1: Is it worth pointing out that root stores are not fixed? 
Not only can they be extended via automatic download (as you pointed 
out), but enterprises can add and remove roots (as often happens in 
Windows environments) and browser users can manually add or remove 
roots or modify trust bits. Document readers may not be aware of those 
other possibilities.


Section 2.2: It might be helpful to readers to explain here why 
Firefox does not do "AIA chasing". In other words, they don't see it 
as a missing feature; they choose to fail on incomplete chains, and a 
case can be made as to why this behavior is preferable to the behavior 
of other browsers. Or do we just want to point out differences among 
browsers without trying to explain why those differences exist (where 
we understand why)?


Section 3.1 The introduction says "This document reviews the current 
processing behaviors...", but this Section is full of "should"s. I 
suggest it needs to be rewritten to factually describe current behavior.


Section 3.4 seems speculative and not descriptive of current browser 
behavior.


Section 3.5 Header is not in bold.

Section 4.3 Shouldn't say "browsers should" ;^)

-Rick

*From:*wpkops [mailto:wpkops-boun...@ietf.org] *On Behalf Of *Ben Wilson
*Sent:* Tuesday, May 27, 2014 2:13 PM
*To:* wpkops@ietf.org
*Subject:* Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

Here is another draft with suggested changes from Santosh accepted, 
and the addition of "Security Considerations" subsections, based on 
our discussions of May 13^th .


*From:*wpkops [mailto:wpkops-boun...@ietf.org] *On Behalf Of *Ben Wilson
*Sent:* Tuesday, May 13, 2014 9:44 AM
*To:* wpkops@ietf.org 
*Subject:* [wpkops] Preliminary Next Version of Browser Behavior Draft

Here is a first pass through the browser behavior document that I sent 
to Robin and Santosh yesterday.




___
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops


___
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

Re: [wpkops] OCSP Responder Vendors

[Stephen Kent]

Tim,

The charter for this WG says (in part):

   The working group's goal is to describe how the Web PKI
   "actually" works in the set of browsers and servers that are in
   common use today.


So I think that major bug ought to be in scope.

Steve
___
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

Re: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt

[Stephen Kent]

Bruce,

The biggest issue is that of removing root (root certificate, root CA, root 
store) with trust anchor. The issue is that in the Web PKI, we use root. The 
policies from the embedding vendors use root and the CA/Browser Forum 
requirements use root. Root seems to be a common term in the Web PKI and we 
thought that using trust anchor would confuse things. On the other hand, we do 
agree that the roots are trust anchors and there can be other trust anchors 
that are not roots such as a private CA certificate. Perhaps this would be a 
good discussion item.
I know that the term "root" or "root CA" is widely used. It is also not 
consistently used,
as an analysis of your text showed. So, we do need a way to reconcile 
the the root vs. TA

terminology issue in a fashion that is consistent with 5280 and 5419.

The other issue is that in some cases there are definitions that were not 
stipulated. We had decided to minimize the definitions and use the terms as 
they are used in RFC 5280. If the term was not used in RFC 5280, then a 
definition would be provided with hopefully another RFC referenced. For trust 
anchor, we have referenced RFC 5419 per your recommendation.

Here are some responses to your comments per the numbers in your pdf:

1. Issuing CA is referenced in RFC 5280
Although the term "issuing CA" is used in 5280, it is not used in a way 
that is
consistent with your use. In 5280 the term is used to refer to the CA 
that issued a specific
cert. Every CA in the web browser model issues certs. I think the 
distinction you are making is
whether a CA issues cert to _customers_. That needs to be specified in 
your terminology section.

2. Policy is certificate policy or root embedding policy or CA policy depending 
on which TA store you are referencing

please say that explicitly.

3. Exceptions are covered in the variations section of the document

please include forward pointers.

4. An RP changing the TAs would be a variation which could be covered. However, 
it was suggested not to discuss RPs.
I thought the goal is to describe the trust model embedded in browsers. 
if so, then if a user can

delete a TA/root, that belongs in the doc.

5. Yes, an annual compliance audit is standard in a root store's policy. This 
is also covered in the CA/Browser forum policies.

then please reference the relevant doc from the CABF.

6. There are several indications such as removal a the HTTPS indicator or a 
mark through HTTPS.

please make that explicit, even if only by examples.

7. Issuing CA is referenced in RFC 5280.

see my comment above.

8. Intermediate CA is referenced in RFC 5280.
yes, but it's use does not seem to align exactly with yours. Every CA 
between an EE cert and a TA is an intermediate

cert. is that precisely the way you use this term?

9. CRL and OCSP fields will be provided.

good.

10. By "location" we mean online location.

please be explicit.

11. See item 2 above. Maybe this should be discussed.

yes.

12. Removed reference to requirements.

OK.

13. An example is that Chrome or Safari operating on Windows uses the Windows 
root store.

As an Apple guy who usually uses Safari, this is not obvious.

14. Tried to fix the long sentence.

great.

15. This one should be discussed as well.
16. Will fix the RA certificate issue.

good.

17. The owner's name is put in the organization field.
there is no org "field" in a cert. there is an org attribute in the 
Subject field.

18. Enforcement is down by legal or technical means.

there's a big difference between the two "means" ...

Steve

p.s. see you in YVR.
___
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

Re: [wpkops] ID on Trust model

[Stephen Kent]

Ben,

What about this?

Key store – an application’s collection of keys and certificates that may also 
identify the purposes for which they may be used, including the root 
certificate and associated public key that the application may use as a trust 
anchor.
A trust anchor is defined as a public key and optional, associated data, 
so the definition
above is not quite right. I suggest removing all use of the term "root" 
in this doc, to

avoid confusion.

Key store governance policy – the policy adopted by a key store manager that 
sets forth rules governing the key store, including requirements for root CAs 
and subordinate components and entities, such as keys, certificates, 
subordinate CAs, and registration  authorities.

again, kill "root CA" and replace it with "trust anchor."

Root CA – a CA with a self-signed certificate and whose public key is included 
as a trust anchor in a key store.

see comments above re the problem with this definition.

Steve
___
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

Re: [wpkops] Silence is deafening - Trust Model Paper

[Stephen Kent]

Please re-read the charter. The scope of the WG is narrower than you 
seem to wish.
If this is going to be a persistent problem, then maybe you ought not be 
a co-author for

this document.

Steve
--
On 6/27/13 8:27 AM, i-barre...@izenpe.net wrote:


Hi

Then we´re assuming that web PKI means only TLS connections, am I 
right? So "web" is used only in "browsers"? I think this is not fair. 
We are talking about trust models and browsers root stores is only 
"one" of these models, not the only one and we should consider the 
others.


I don´t get why we are assuming that web PKI is only referred to the 
browsers, and if so, the document could be very simple, just pointing 
to the browsers policies or leave it to the CAB Forum, which is not a 
standards body like it can be IETF.


If we´re to produce a standard on trust models we should consider all 
options, not just one because it´s the most used. That is not an standard.


Regards

Hiya,




___
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

Re: [wpkops] Web PKI - Trust Models

[Stephen Kent]

I reviewed just the definitions section, and it has a LOT of problems.

Comments on that section below.

Steve
--

1.2.  Definitions

Why are not all most of these terms taken from X.509 or RFC 5280, with
appropriate cites?

  Certificate: The public key of a user, together with some other
  information, rendered unforgeable by encipherment with the private
  key of the certification authority which issued it.

This is an RSA-centric view of how a signature is computed; it fails to 
describe how
a DSA-based sig is computed. Also, it ignores the use of a hash function 
as is common

ptractice.

  Certification Authority (CA) - An entity trusted by one or more
  users to create and assign certificates.

  Certificate holder - A natural or legal person who is identified
  as the subject in a certificate.
or a device, or organization, or ...

  Certificate policy: A named set of rules that indicates the
  applicability of a certificate to a particular community and/or
  class of application with common security requirements.
cite 3647?

  Certification Practice Statement (CPS): A statement of the
  practices that a Certification Authority employs in issuing,
  managing, revoking and renewing or re-keying certificates.
cite 3647?

  Certificate subject - The certificate holder as represented in the
  certificate.
the holder of the private key that corresponds to the public key in the 
cert.


  Certificate user - A natural person who operates a certificate
  using product.
relying party?

  Certificate-using product - A product that evaluates a certificate
  or certificate chain and adjusts its behavior according to the
  result.

  End entity: A certificate subject which uses its public key for
  purposes other than signing certificates.
since a public key IS never used to sign anything ...

  Intermediate CA - A CA that issues certificates to issuing CAs
  and/or other intermediate CAs.
this def will overlap with that of a TA, so not very useful.

  Issuing CA - A CA that issues certificates to certificate holders.
is there any other kind of CA?





Barreira & Morton  Expires May 4, 2013 [Page 3]

Internet-Draft Trust models of the Web PKI  October 2012


  Policy management authority - A natural or legal person who
  administers the certificate policy by which one or more
  certification authorities operate.

  Public-key infrastructure (PKI) - is a system for the creation,
  storage, and distribution of certificates which are used to verify
  that a particular public key belongs to a certain entity.
not revocation too?

  Relying party: A user or agent that relies on the data in a
  certificate in making decisions.
decisions about what?

  Registration authority (RA): An entity that is responsible for
  identification and authentication of certificate subjects, but
  that does not sign or issue certificates (i.e., an RA is delegated
  certain tasks on behalf of a CA).

  Root certificate - is either an unsigned public key certificate or
  a self-signed certificate that identifies the Root Certificate
  Authority (CA).  A root certificate is part of a public key
  infrastructure scheme.
no mention of the relation to the more formal term, TA?

  Root CA - The trust anchor for a digital certificate is the Root
  Certificate Authority (CA).  A CA whose public key is included in
  a root store.

  Root store - A set of certification authority public keys that is
  embedded in a certificate-using product.
not just Root CA public keys?

  Self-signed certificate: A certificate for one CA signed by that
  CA.
we have expanded the def in PKIX to include certs signed by EEs, to more 
closely

match common practice. do you mean to exclude this case?

  Trust anchor - is an authoritative entity represented via a public
  key and associated data.
if the "authoritative" part were true, the problems faced by this model 
would

be much less severe :-). The problem is that almost none of the TAs embedded
in browsers are authoritative for the certs they issue!

  Trust model - The roles, and the relationships between those
  roles, that are relevant to the management and evaluation of
  certificates.

  Trust service - Service which enhances trust and confidence in
  electronic transactions.
vacuous def.
___
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops