Re: [lamps] I-D Action: draft-ietf-lamps-csr-attestation-01.txt

[Michael StJohns <[e-mail]>]

On 10/4/2023 11:42 AM, Russ Housley wrote:
> I do not understand why we want to include opaqueCert in CertificateChoice.

Yup - I'd agreed to remove it before I passed the document over, and it 
should be removed.

>
> Also, I think that CertificateChoice is a poor name.  It is too likely to be confused with CertificateChoices that is defined in RFC 5652.

This is new.  There are so many different ASN1 modules and AFAICT no 
central registry of names that it's hard to find collisions like this 
without deep knowledge.

And then there is "ATTRIBUTE" which has way too many overloaded meanings...

ChoiceOfCertificateType instead?   At some point this will collide with 
someone else doing something slightly different.

Alternately, this could re-use CertificateChoices, but that's using the 
old ANY syntax so not ideal I would think.


>
> Russ

The semi-repetative nature of the bundle definitions is problematic.  
Both the ATTRIBUTE and EXTENSION are defined as "SEQUENCE OF 
EvidenceBundle", and then Evidence Bundle has "evidence SEQUENCE of 
EvidenceStatement" leading to multiple possible ways to encode the exact 
same attestations, even without the infinite duplication of the same 
certificate data within multiple EvidenceBundles.     SEQUENCE OF may be 
necessary to convey multiple attestations in a CRMF EXTENSION, but 
ATTRIBUTE already wraps everything in a SET and so provides for the 
carriage of multiple EvidenceBundles within a single attribute.  The 
statement at the end of 4.2 justifying this SEQUENCE OF approach isn't 
persuasive.

Since "certs" is optional in "EvidenceBundle", what happens if it's 
omitted in all of the bundles?  Where do you carry the certs needed to 
validate the attestation(s)?  Note that the EvidenceCerts attribute is 
missing in the ASN1, but still mentioned (as an unnamed attribute) in 
the introduction.

EvidenceBundle is not defined in the text (but is in the ASN1 appendix) 
and should be.

The discussion of certs to be included in 4.2 excludes any discussion of 
the interaction of multiple attestations (EvidenceBundles) in the same 
structure all chaining back using the same certificates. Is duplication 
required?  If not, where are the certs placed - first attestation? last? 
anywhere?  What does a relying party do if the certificates are missing 
(since the field is optional?)

Later, Mike

>
>> On Oct 4, 2023, at 11:03 AM, [e-mail] wrote:
>>
>> Internet-Draft draft-ietf-lamps-csr-attestation-01.txt is now available. It is
>> a work item of the Limited Additional Mechanisms for PKIX and SMIME (LAMPS) WG
>> of the IETF.
>>
>>    Title:   Use of Remote Attestation with Certificate Signing Requests
>>    Authors: Mike Ounsworth
>>             Hannes Tschofenig
>>             Henk Birkholz
>>    Name:    draft-ietf-lamps-csr-attestation-01.txt
>>    Pages:   21
>>    Dates:   2023-10-03
>>
>> Abstract:
>>
>>    A client requesting a certificate from a Certification Authority (CA)
>>    may wish to offer believable claims about the protections afforded to
>>    the corresponding private key, such as whether the private key
>>    resides on a hardware security module or the protection capabilities
>>    provided by the hardware.
>>
>>    This document describes how to encode Evidence produced by an
>>    Attester for inclusion in Certificate Signing Requests (CSRs), and
>>    any certificates necessary for validating it.
>>
>>    Including Evidence along with a CSR can help to improve the
>>    assessment of the security posture for the private key, and the
>>    trustworthiness properties of the submitted key to the requested
>>    certificate profile.  These Evidence Claims can include information
>>    about the hardware component's manufacturer, the version of installed
>>    or running firmware, the version of software installed or running in
>>    layers above the firmware, or the presence of hardware components
>>    providing specific protection capabilities or shielded locations
>>    (e.g., to protect keys).
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-lamps-csr-attestation-01.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lamps-csr-attestation-01
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm