Re: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

[Carl Wallace <[e-mail]>]

I reviewed the draft. Below are some comments, questions and suggestions.

 

General

 

- Somewhere in this specification there should be a rule that governs the relationship between the public key that appears in the AttestAttribute and the public key that appears in the certificate request containing the AttestAttribute.

 

- One complaint from some regarding draft-ietf-lamps-key-attestation-ext-00 was that it used CBOR. One alternative that has been discussed is to use an ASN.1 structure that contains a type value and a bit bucket. Why are the structures in this spec preferable to something simple like the below? You could even dispense with a wrapper structure like this and just define OIDs for various key attestation formats.

 

AttestationStatement ::= SEQUENCE {

                type OBJECT IDENTIFIER,

                statement OCTET STRING

}

 

Section 1

 

First paragraph

 

- I am assuming the two specifications you are offering a counter proposal to are draft-ietf-lamps-key-attestation-ext-00 and draft-ounsworth-pkix-key-attestation-02. These are really two different things and it is not obviously clear how this obviates both. The former has expired and, as a co-author, I am not aware of any plans to continue with it. More generally, I think a specification is needed to address conveyance of key attestations to RAs/CAs but I don't like the idea of defining a key attestation format in the same spec. These should be separate specs, in my opinion, but I'd expect the conveyance spec to support any format spec.

 

Third paragraph

 

- This spec supports a blob (possibly containing a blob and type) and a signature. I suppose this can be viewed as "any type of certificate imaginable" but it's just a signature and some data. I'd drop this verbiage.

 

Section 2.2

 

- I think this section aims to serve as an alternative to draft-ounsworth-pkix-key-attestation-02. That should be made clear if so. The spec also includes a third significant unstated goal, i.e., defining new means to convey public keys to verify signed data. It's not clear to me that we need/want alternative certificate types in a spec that in its simplest form would define how to convey key attestations to a CA.

 

- There is already a CertificateChoices structure in CMS (that the structure in this spec imitates but conflicts with). If this structure is needed, refashioning as an extension of CertificateChoices might make sense, i.e., by using context specific tags that don't conflict, or by simply defining a few new "certificate" types for conveyance via the other field in the existing CertificateChoices.

 

- The Certificate field is not "more or less" an X.509 certificate. It is an X.509 certificate. I would drop this verbiage.

 

- I agree with Russ' comments re: the lack of need for typedCert and typedFlatCert (but, as noted above, think all of this could be replaced with a type and statement object). If object reuse was a goal, one could simply use a degenerate SignedData object with EncapculatedContentInfo playing the role of the AttestationStatement structure above and the certificates field playing the role of your AttestCertsAttribute. Under this approach, no new structures would be needed, but we'd need words to define how existing key attestations fit (and an IANA registry for those types).

 

- The statement "it is possible to use this field to convey a bare public key as well" is at best confusing. It invites a common issue that crops up with current attestation formats (i.e., folks sticking random binary data into field that should feature ASN.1-defined structures). I think the least you could get away with here would be an OCTET STRING that contains a bare public key. I would drop the reference to "bare public key."

 

- Re: "think compact of implicit certificates", there is no need to be abstract here. You could give draft-ietf-cose-cbor-encoded-cert-05 as a concrete example.

 

Section 2.5

 

- Why do we want key attestations that are inextricably bound to a CSR? Most of the structure here goes away if we discount that as a goal.

 

- There seems to be several aspects of processing this structure that will rely on external knowledge to know what to do. For example, if the signature algorithm is absent in this structure then it may be encoded inside the type field or it may just be a fixed value. The format of the type field used for signature generation/verification is also left open ended with no way for the verifier to know. Similarly, the format of ancillary data is not signaled to a relying party.

 

- The term "attestation engine" is not defined. It may be best to use vocabulary from the RFC9334.

 

Section 2.6

 

- Why do we need a CHOICE for signature encoding? 

 

- What does "be consistent with" mean here? Does this mean the OBJECT IDENTIFIER used to identify the structure of the value field also indicates the structure of the signature field (and/or structure of the ancillary data field)? That makes the type field less like a type identifier and more like a profile identifier that describes the type of attestation, the algorithm and the signature format.

 

Section 3

 

- As written, I think you only need one registry, i.e., for attestation statement types. This draft defines the CSR attribute and does not contemplate peer attributes or alternative attributes. The attribute in the spec could likely be registered in an existing PKIX registry. 

 

 

From: Spasm <[e-mail]> on behalf of Michael StJohns <[e-mail]>
Date: Friday, May 5, 2023 at 3:37 PM
To: "[e-mail]" <[e-mail]>
Subject: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

 

FYI



-------- Forwarded Message -------- 

Subject: New Version Notification for draft-stjohns-csr-attest-00.txt
Date: Fri, 05 May 2023 12:36:19 -0700
From: [e-mail]
To: Michael StJohns <[e-mail]>




A new version of I-D, draft-stjohns-csr-attest-00.txt
has been successfully submitted by Michael StJohns and posted to the
IETF repository.

Name: draft-stjohns-csr-attest
Revision: 00
Title: Attestation Attributes for use with Certificate Requests
Document date: 2023-05-05
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/archive/id/draft-stjohns-csr-attest-00.txt
Status: https://datatracker.ietf.org/doc/draft-stjohns-csr-attest/
Html: https://www.ietf.org/archive/id/draft-stjohns-csr-attest-00.html
Htmlized: https://datatracker.ietf.org/doc/html/draft-stjohns-csr-attest


Abstract:
This document describes two ASN.1 Attribute definitions that may be
used to carry key attestation data in PKCS10 certificate requests and
in other circumstances.



The IETF Secretariat


_______________________________________________ Spasm mailing list [e-mail] https://www.ietf.org/mailman/listinfo/spasm