Re: Origin Signed Responses and certificate requirements

On Thu, Apr 12, 2018 at 2:31 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Thu, Apr 12, 2018 at 02:09:00PM -0400, Ryan Sleevi wrote:
> > On Thu, Apr 12, 2018 at 1:51 PM, Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> > >
> > > Web packaging is not similar to Secondary Certificates. It is however
> > > similar to Delegated Credentials.
> > >
> >
> > Sure it is. A compromise of a secondary certificate key, or of a web
> > packaging key, reduces the cost of attack to "Can I induce a client to
> talk
> > to the attacker" - which, in a Web context, is sort of a key design
> feature
> > of the Web. If you can, then the holder of a compromised Secondary
> > Certificate, or a compromised Signed Exchanges key, can induce a client
> to
> > accept as "from the origin" their content, in an otherwise undetectable
> > manner.
>
> Also, due to the requirement that SC keys are online, even if the key
> is protected from dumping, it can still be misused (in realtime) if the
> web server is compromised (and such compromise may be difficult to
> detect). WP/DC keys do not need to be online.
>
> > > Also, saying that keys for for WP/DC SHALL be protected in some
> > > specified way would have really nasty interactions with current
> > > CABForum BRs, making it effectively impossible to get such
> > > certificates. So any enhanced protection is at most RECOMMENDED.
> > >
> >
> > I'm not sure why you say they would have 'really nasty interactions'.
> > Parties that want code signing certificates from CAs trusted by
> Microsoft,
> > for example, can only do so for keys on hardware security modules. Which
> > effectively means the CA sending out an USB token or smart card, and
> > provisioning the key themselves.
>
> Getting code signing certificates is much much harder than website
> certificates (except EV) anyway. So there the HSM requirement is not
> that much of an increase.
>
> Also, here is yet another difference. Required capacity. WP/DC/CS need
> fairly little signing capacity, so one could put the keys to a
> smartcard or basic USB token (with signing capacity on order of 1-3
> signature per second) if one wanted to. However SC needs much more
> capacity, so smartcard or basic USB token is not going to cut it.
>

If SC was coupled to DC though, doesn't that address some of the concerns?