[Cscwg-public] Final minutes CSCWG November 30, 2023

[Dean Coclin]

Meeting Minutes November 30, 2023

Attendance: Andrea Holland - VikingCloud

Atsushi INABA - GlobalSign

Ben Dewberry - Keyfactor

Brianca Martin - Amazon

Bruce Morton - Entrust

Dean Coclin-DigiCert

Dimitris Zacharopoulos - HARICA

Eva Van Steenberge - GlobalSign

Ian McMillan Microsoft

Inigo Barreira - Sectigo

Martijn Katerbarg - Sectigo

Mike Ounsworth - Entrust

Rollin Yu - TrustAsia

Scott Rea - eMudhra

TIM CRAWFORD - BDO

Tim Hollebeek -DigiCert

Trevoli Ponds-White - Amazon Trust Services

Corey Bonnell - DigiCert

 

Approval of prior meeting  minutes: no recording, minutes done from memory:
no comments, approved.

 

Ballot statuses (Bruce Morton - Entrust)

*	21 (Signing Service): delayed based on conversation last time, open
discussion, has 90 days to let it fail or put something else out. Currently
on hold.
*	High risk ballot: agreement on text, two endorsements, just waiting
on current ballot to finish IPR review, then the updates to GitHub can
happen.

*	Corey: IPR review ends next Monday or around that time.
*	Bruce to send ballot for discussion after Corey sends link. Expected
minimal discussion, done before holiday season.

*	Remove EV guideline references: Dimitris Zacharopoulos (HARICA):
worked on this, created a new branch, imported as many of the EV references,
working against 1.8.0 version of EVGs. We can decide what we do with it.

*	Effective date of September 15th 2024 for incorporating agencies,
but just a placeholder
*	Painful to import EVGs, because they reference themselves. Work in
progress. Following Inigo's recommendations, spotted some issues, reported
to Inigo. More at next meeting

*	Charter update: (Martijn Katerbarg - Sectigo): waiting for 19 to end
voting, and then kick-off discussion for Forum 20.

 

Dean Coclin-DigiCert:

*	ITrus China: Application seems to be in order, roots in Mozilla, but
does not deal with Codesign. Are they a codesign issuer, because our by-laws
for code signing require that. 

*	Ian McMillan - Microsoft: not aware they are trusted, and currently
not accepting new members, or with very stringent requirements.
*	Dean: Ask ITrus if they are a CodeSign issuer, maybe offer to grant
them a different status, interested party or associate member?
*	Dimitris: if they applied for it, allow associate, if not applied,
then interested party would be best option.
*	Dimitris: just root issuer, not for CodeSign or NetSec.
*	Dean to go back to them.  (SUBSEQUENT TO MEETING IT WAS DISCOVERED
THAT THE WRONG APPLICANT WAS DISCUSSED. SHOULD HAVE BEEN TrustAsia. They
will stay as Associate Member)

*	Maria Merkel wants to participate in CodeSign, ServerSign, SMIME,
application has been signed. Person, not a company, no reason to object. No
concerns noted. Added to mailing list.

 

Next meeting in 2 weeks, no meeting week of 28th.

 

Bruce: Mike Ounsworth has worked for Entrust for quite a few years. He's
active in the R&D functions, quite active in other standards, including
post-quantum standards. Moving away from software keys to hardware only
keys, but not having a standard for attestations.

 

Mike Ounsworth - introduction. Software Security Architect at Entrust. IETF
participant, protocol designer. Author of one RFC and 14 active internet
drafts. Member of IETF Security Area

 

Most work is around Post-Quantum, but not talking about that, instead
talking about Key Attestation. 2 Active Internet Drafts about this topic,
one about CSR attestation, one other, . Discussed in more detail further in
the presentation.

(See attached presentation)

 

Attestation roadblock. 

CA/B Forum Code Signing - the intent is great, but how is this proven to a
CA? How is a CA supposed to decide which evidence counts and what doesn't?
Mike presented some types of "evidence" and explained the problems - text
not being cryptographically sound, audit letters, lists of HSMs, pictures.
CAs make do with what is being provided. 

Explained that there are practical challenges at the customer side, or
customers are using Cloud providers, which have the information but it's
difficult for CAs to access it. Sometimes it becomes apparent that the
customer is not using the HSM in FIPS mode or they haven't made patches,
which arguably is the requirement working successfully (maybe, is this
really the group we should block from getting certificates, companies that
have HSMs, but not in the right configuration, potentially blocking security
patches for their own software?).

We don't have an automated, standard way to determine what hardware a
private key is stored on. 

Even when they have the hardware, it's difficult to determine if it's
configured correctly. Customers provide a lot of information which is hard
to digest and potentially not relevant. Additionally, customers are not used
to the friction in this process, therefore they order their certificates
late. Validation specialists are not always technical and have to guide
semi-technical customers to verify if the requirement has been met.

What we want is clear. Check the CSR, and check that the key is in the right
hardware. But how do we get there?

Tim Hollebeek: These options are allowed by the requirements. It's better to
have an option that is easier, better and that works for everyone.

Mike: Everyone on the same. Solution is Remote Attestation, often called Key
Attestation, but that's a corner of Remote Attestation, but technology is
more powerful.

 

Roadmap on Remote Attestation standards.

Side question: how to manage the manufacturer root store?

 

 

 

 

 

 

 

Multiple frameworks

*	IETF Remote Attestation Procedures (RATS) Architecture
*	Trusted Computing Group (has 2)

*	TPM 2.0 Attest, includes Remote Attestation (oldest)
*	TCG Devise Identifier Composition Engine (Dice) - things on a
motherboard authenticating to each other. Robust remote attestation
framework

*	RATS and DICE are pretty closely aligned and more modern.

Attester (HSM that holds the private key), creates a CSR, including
attestation evidence, goes to CA/RA, which are the relying party who are
going to make a decision. Separate role for the verifier that checks the
attestation. This may be part of the RA or could be a separate component,
and provides an attestation result, on which a relying party can make a
decision.

Types of attestation data:

*	Evidence. 

*	Platform evidence (evidence of the device as a whole)
*	Key evidence (e.g. imported or not, exportable or not)
*	Signed using an attested key, typically a device manufacturer root
anchor (X.509 certificate)

*	Endorsement: a third party making assertions about the device that
the device cannot know itself. Usually signed by a trust chain.
*	Reference value: profile of "known good configurations". Allows the
verifier to check the evidence and endorsements. May or may not be signed.

Mike provided an explanatory metaphor of checking into an unmanned hotel.
The evidence is the selfie. The passport contains a photo, which is the
reference. The other information is endorsement. The selfie doesn't contain
name and date of birth.

This Attestation is what we are trying to build. Inside the CSR is the
regular CSR stuf, plus an evidence statement, including platform evidence
and key evidence. Evidence is signed by an attestation key which lives on
the device, which chains to a relevant trust anchor. This allows the
evidence to be verified and ensures integrity.

 

 

 

>From the perspective of the HSM vendor: evidence has to be collected and
signed by the firmware. Codechange inside the FIPS boundary. Outside script
could be spoofed. The Attesting Key has to be placed on the device at
manufacturing, has to chain, can't be used for any other purpose. 

This is harder than CSR - outside FIPS boundary.

Challenges for the HSM vendor:

*	The fact that the evidence has to be  collected and signed by
firmware means that adding or modifying this functionality forces a
recertification of audited codebase. 
*	The elements surrounding the Attestation key means that it cannot be
retrofitted into existing hardware ("new devices only"). This may be too
harsh, in certain circumstances certain elements could be updated via
software patches, or the key can be retro-fitted via some key ceremony, but
that's incredibly hard. Not impossible, but not practical.

Tim Hollebeek commented that he'd like to push back a little bit on the fact
that it would be hard to do it with existing devices. Audited creation of a
key is something that we understand pretty well and could do. If we had
rules about and then if that key was used to sign various evidence
statements, it wouldn't be as good as a manufacturer based solution, but we
could design this as a solution that could work.

Mike agreed that the language could be softer. There is some existing
solution if you want to assign an attestation key from the corporate PKI,
that will override the one imbedded. This option exists in some
implementations. Talk to your HSM vendors - proprietary and in-field.

Tim Hollebeek suggested this could be done without the manufacturer's
support. Everybody has an automated procedure for designating 1 of the keys
on the HSM as being the key for this purpose. During the highly secure
audited procedureit can be agreed in the audit letter what the hash is,
what the public key is. One could design such a system, even without the
manufacturer, but yeah, you would eventually be building an entire HSM based
attestation and audit scheme on top of the existing stuff, and we don't want
to do that. 

Mike responded that then you'd have questions, like, having a script
external to the HSM, that queries its model number and firmware version.

Tim Hollebeek replied that he was assuming that it's one of these
programmable HSMs where some of that information is available inside the
device and so as long as you had a key within the device you could do a
signature of the internal the data, or simply sign a challenge response
would show that you actually are the HSM. 

 

Mike: Challenge accepted. Language could be softened from cannot be done to
it's tricky.

Standardisation status

 

Within TCG, very mature. Actual data is proprietary but protocol is
standardized. DICE is robust, but limited in scope. WebAuthn / Passkey is
robust but data tend to be proprietary. 

Everything is all over the map, not non-existent, just non-standard. Many
HSM vendors have some sort of key-attestation, but the format is
non-standard. All reasonable choices, but different choices. Parser per
hardware vendor is required. No standardized way to carry attestation in a
CSR. This is a next barrier.

Two IETF Internet-Drafts being designed. On top of the slide: NIST latched
on to this. They will need to provide machine readable versions of the CMVP
certificates to fully automate this. We're asking to provide this in full
attestation endorsement format, so the endorsement could be embedded in the
CSR fully detached. Not sure if they can host the signing key. They might
provide a rest-API. Not quite as good, but probably workable.

LAMPS draft  adopted in August, very close to Working Group Last Call. Quite
fast-moving. Take whatever attestation you have, and place it in the CSR,
agnostics. Pick an OID to identify the EvidenceStatement type. Layer of
EvidenceStatement, defined for different types of CSRs. One or more evidence
bundles, then evidence statements and certificate type. Designing with light
devices in mind. 

Structure might seem weird, the reason for that is that the technology is
going to grow to support use-cases where the device might have platform
level attestation key that lives in the root of the device that signs
platform attestations. In the HSM partition, it may make sense to have the
key attestation in the partition. This is why it's an evidence bundle,
otherwise you may end up duplicating certificates, where the platform and
the manufacturing certificates will have to go in twice. This structure
allows for performance optimisation. It also makes the verifier's job
easier. 

 

 

 

 



Observations:

*	For CSRs, not for certificates.
*	There are legitimate reasons to want to put this information in the
certificate. But this is not what this is. There are some security and
privacy implications, particularly with public trust and publication in CT
logs.
*	Size: one or more certificate chains in the certificates.
*	Manage the trust store for both evidence and endorsement statements.
Question is: who manages this?

*	Each CA separately?
*	Centralized? Gets tricky: Webtrust Certified Manufacture Facility
Audit? Big manufacturers are probably trusted, but as you get down to
smaller vendors who people haven't heard of, how does one decide if their
manufacturing facility is worthy of public trust?
*	Anti-trust: could be seen as first step of locking down the
internet. Could be an existential treat to the very concept of open
internet. E.g. Only allow Netflix from Netflix-certified Android device.
What we're doing here is reasonable, but people will be watching this as a
gate-way technology to more restrictive behaviours.
*	Policy and politics problem.

Tim Hollebeek: From a CA/B Forum perspective, it's out of scope. Scope is
limited to certificates that are trusted by the certificate consumers, who
participate in this forum. That is the appropriate people to manage the
requirements around what attestations they are willing to accept.

And, of course, they could ask this group to come up with a set of minimum
requirements and procedures for verifying them that a such a hardware
manufacturer might need to meet in order to participate in the program that
they are running, using the requirements produced by this particular forum,
but this particular forum is not involved in the assessment of anybody who
chooses to be assessed for the purposes of being trusted by a certificate
consumer who consumes the requirements.

Dimitris Zacharopoulos (HARICA): Forum does not police the eco-system and
doesn't supervises  anyone. We've seen something similar in FIDO alliance:
metadata service, all manufacturers are sharing their keys. Not sure how
someone can add their device keys. Sounds like a similar problem. Are the
manufacturers in the IETF group considering something like this?

Mike: Sort of comes up, they are waiting for someone to tell them where to
submit their root keys to. Option 1 is the default option (CA based). Unless
we find a centralized way.

Dimitris Zacharopoulos (HARICA): An easier way would be something like the
bigger consortium or the CA/B Forum to have pointers to every HSM
manufacturer page where they, they share their keys. And create a repository
in an informative way. No decisions. Just the table with pointers.

 

Mike Ounsworth: And inclusion in that wiki is really just open?

Tim Hollebeek: Yes. That would be especially useful because we don't even
have a standard yet. Hopefully, we will have the standard in 6 months. This
is all great work and there's going to be follow on work related to this.
Because of course, at this point, you just get a blob in your CSR. Hardware
manufacturers are still all over the map on what the format is. And how you
would consume that is going to be one of the next problems we're going to
have to solve 

As we have emerging standards in this area, it would be very useful to have
a wiki that basically just says the following manufacturers claim to comply
with RFC 9999 Security Attestation. And then we will be able to say, here's
the list of manufacturers who have adopted 1 of these standardized
solutions. We can now talk to them about how their technology works and how
we might integrate it with.

Dimitris Zacharopoulos (HARICA): But we're still looking at the years ahead
because these devices need to be re-certified and that takes time. 

Mike: Yes and no.

The people with checkmarks can already do it, those devices can already
produce attestations in their own proprietary format. Within the next 6
months, we'll have an RFC for how to take these and bundle them into a
standardized CSR attribute and that's that's enough to get automation value
here. The CA would still need a per vendor parser, but at least the way to
transport that data across is standardized.  Once you can put it in CSR,
then you can do Acme then you can do whatever takes CSRs. This is a this
year type delivery and I think we can get some automation immediately.

To Tim's second point, we're also working on a standardized evidence format
to solve the "all over the map problem". This is much less mature. We just
put out the 1st version of it, 3 weeks ago. We've sort of got the platform
attestation elements nailed down: which hardware model / software model is
it in? Is it in debug mode? Do you need to say anything about your FIPS
configuration or CC configuration? 

We're about to start on the key properties, defining, non-exportable and
imported. Looking what we can borrow that already exists. This one is the
one that will take years. At least a year for us to even agree on the
semantics of this document and get it published as an RFC. This will be
device only or patching. Yeah. 

However, taking what you already can produce today and putting it in the
standardized CSR, that should be doable this year.

 

Dean Coclin-DigiCert

Wonderful presentation. Thank you very much for taking the time with us to
share this information and certainly as eye opening to myself and I'm sure
others as well. I think if you're available for future meetings to maybe
answer future questions.

 

We had 3 people joined that are not in the original attendance been Scott,
Ray and Tim Crawford. We'll add those in 

 

 

 

 

Dean Coclin 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20240111/a744cc38/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 513108 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20240111/a744cc38/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cabf_attestation.pdf
Type: application/pdf
Size: 1321966 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20240111/a744cc38/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5197 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20240111/a744cc38/attachment-0001.p7s>