[Cscwg-public] Minutes of CSCWG - Signing Service meeting 24 June 2021

Dean Coclin dean.coclin at digicert.com
Thu Jul 22 22:12:30 UTC 2021

Here are the approved minutes of the subject meeting, prepared by Bruce


Attendees: Bruce Morton; Ben Wilson; Dimitris Zacharopoulos; Tim Hollebeek;
Corey Bonnell; Nick France; Christopher Kemmerer; Vikas Khanna

Discussed rules: This is not a subcommittee, so could be treated as a
regular CSCWG meeting or a group of friends talking. Decided to take minutes
from a group of friends. We should discuss at the next CSCWG to decide
whether we will have a ballot for a Subcommittee just have this as a CSCWG


Approach: Should we have the text throughout the document, have a separate
section, wait until we have the new formatted CSBRs. Tim thinks that we can
just update the current document and have the items throughout. We do need
to discuss which problems need to be addressed. Bruce would also like to
discuss the models and then some text which is not required for the models
could be deleted.


Problems: How do we address problems? List problems? March through the
document? It would be best if we define models, then march through the
document. If we agree to the approach that the Signing Service is only a
representative of the Subscriber, then this would change the document a lot.
Dimitris suggested that we start with a good definition of Signing Service,
then we can address problems.


Definition of Signing Service:

*	Dimitris suggested "Is an entity that manages private keys on behalf
of Subscribers"
*	Vikas indicated that we need to discuss purpose and the foremost
requirement if signing.
*	Bruce suggested we don't trust subscribers to generate keys, so we
would like the keys to be generated by a service which could be operated by
a CA or a third party. The keys would be generated in a protected way, the
keys would be kept safe, and access to the keys would be controlled. Signing
is an output after we have protected keys. Signing cannot be audited.
*	Vikas asked that is you support a bring your own key model, then you
are not a signing service.
*	Tim supports bring your own key, but wants key protection. Need to
think about this model as there are many pros and cons.
*	Bruce had concerns about bring your own key as the Signing Service
does not know how the key was generated and if there are unprotected key
*	Vikas is concerned that in some cases such as Android, then you
cannot change your key.
*	Bruce suggested that Android is out of scope for the CSBRs. This was
agreed by Dimitris and Tim.
*	Tim suggested that importing keys would require key providence to be
known. Vikas agreed.
*	Vikas is concerned with manages keys as this may address lifecycle
of key. He suggested that the Subscriber would like to manage the lifecycle
of the keys. 
*	Bruce suggested the document would define what management is by
defining the requirements.
*	Tim suggested that the Signing Service would be involved in pretty
much all parts of the key lifecycle, so lifecycle seems fine.
*	Chris provided the definition from the CSBRs. Dimitris stated it is
not good as it addresses code. Tim also didn't like that it calls out an
Organization. There was discussion about what is actually signed - hash,
binary file, inspected code, etc. Bruce stated that the Signing Service is a
signing pump, which provides a signature as a Yes function, if you can
authenticate. Vikas stated this is like a notary. 
*	Tim stated that we should enumerate Signing Service functions, key
protection, authentication, key activation for signing requests.
*	Bruce stated that Signing Service manages access to signing keys.
*	Bruce assumed that the Signing Service was created as 50% of the
time, the key is compromised, so the Signing Service can mitigate
*	Functions would include logging.
*	In a previous meeting Ian had said the a Subscriber could be a
Signing Service for that enterprise.
*	Tim stated, we need to ensure that we don't make the Signing Service
so hard for the CA or third party, that all Subscribers would be their own
Signing Service and we don't make any improvements.
*	Bruce stated that if the Subscriber is the Signing Service, then
they have to meet the Subscriber requirements. It should be easy to audit a
CA as a Signing Service. If a third part is the Signing Service, then there
are some problems to figure out what to audit.
*	Tim asked do we all agree that Signing Services must be audited. No
one disagreed. Tim stated that the Signing Service provides services to the
Subscriber similar to the way a CA provides services.
*	Dimitris stated that if a third party is the Signing Service, then
they are a Delegated Third Party and the audit functions are transferred to
the third party.
*	Bruce stated that if we allow a third party and that they must be
audited, then we should right audit requirements. Tim agreed that we need a
carve out for a third party audit and it is not the whole everything.
*	There was discussion about how the CA can push down the requirements
and if the third party would be under the CA's audit or their own audit.
There was also objection that this would mean that each CA/auditor would get
to determine the requirements and the audit criteria. It would feel it would
be much better if the CSCWG stated the requirements, so they would be the
same for all.
*	It was discussed that we should review the QSCD model and see what
we can also use. We need to look at the requirements for a remote QSCD.



*	We can discuss at the next CSCWG meeting and decide if we will
create a Subcommittee or address through CSCWG meetings.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210722/528d5b8d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210722/528d5b8d/attachment-0001.p7s>

More information about the Cscwg-public mailing list