[lamps] Re: WG Last Call for draft-ietf-lamps-csr-attestation-09

[Carl Wallace <[e-mail]>]

Yes, hence the suggestion. 

> On Jun 7, 2024, at 1:27 PM, Mike Ounsworth <[e-mail]> wrote:
> 
> Carl,
> 
> So you still think that changing that "in either" to a "such as" is worth doing?
> 
> ---
> Mike Ounsworth
> 
> -----Original Message-----
> From: Carl Wallace <[e-mail]>
> Sent: Friday, June 7, 2024 11:56 AM
> To: Mike Ounsworth <[e-mail]>; Brockhaus, Hendrik <[e-mail]>; Henk Birkholz <[e-mail]>; Russ Housley <[e-mail]>; LAMPS <[e-mail]>
> Cc: [e-mail]
> Subject: [EXTERNAL] Re: [lamps] Re: WG Last Call for draft-ietf-lamps-csr-attestation-09
> 
> No worries. Fortunately, it's not actually scope creep at all.
> 
> On 6/7/24, 12:40 PM, "Mike Ounsworth" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> Personal note: chairing this design team has been a year-long exercise in
> scope-creep gate-keeping ... "but what about composite TPM / SPDM devices?"
> ... "what if we allow 'type' to be either an OID _or_ a string from the CMW
> registry", etc.
> 
> 
> So apologies that you tapped into my pent-up anti-scope-creep aggression :P
> 
> 
> ---
> Mike Ounsworth
> 
> 
> -----Original Message-----
> From: Mike Ounsworth <[e-mail] <mailto:[e-mail]>>
> Sent: Friday, June 7, 2024 11:35 AM
> To: Brockhaus, Hendrik <[e-mail] <mailto:[e-mail]>>; Henk Birkholz
> <[e-mail] <mailto:[e-mail]>act>; Carl Wallace <[e-mail] <mailto:[e-mail]>>; Russ
> Housley <[e-mail] <mailto:[e-mail]>>; LAMPS <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: [EXTERNAL] RE: [lamps] Re: WG Last Call for
> draft-ietf-lamps-csr-attestation-09
> 
> 
> Carl:
> 
> 
>> Is there some reason these could not be used
>>> in SCEP, CMPv2 (or later), CMC, EST, future protocols, etc. Maybe replace
>>> "in either" with "such as" to avoid this limitation.
> 
> 
> Something something "scope creep". Something something "we're so close to the
> finish line".
> 
> 
> This document specifies exactly a PKCS#10 and CRMF extension. Trying to
> consider how this mechanisms could be ingested by other existing and future
> protocols sounds like a goose-chasing exercise that I would rather not do
> right now. The stated scope of this draft is "CSRs" not "enrollment
> protocols".
> 
> 
> ---
> Mike Ounsworth
> 
> 
> -----Original Message-----
> From: Brockhaus, Hendrik <[e-mail] <mailto:[e-mail]>>
> Sent: Friday, June 7, 2024 10:33 AM
> To: Henk Birkholz <[e-mail] <mailto:[e-mail]>act>; Carl Wallace
> <[e-mail] <mailto:[e-mail]>>; Russ Housley <[e-mail] <mailto:[e-mail]>>; LAMPS
> <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: [EXTERNAL] AW: [lamps] Re: WG Last Call for
> draft-ietf-lamps-csr-attestation-09
> 
> 
> I did not see any response to the point on PKCS#10/CRMF vs. CMP/CMC/EST/SCEP
> 
> 
>> Von: Henk Birkholz <[e-mail] <mailto:[e-mail]>act>
>> 
>>>> On 23.05.24 13:53, Carl Wallace wrote:
>>> - The second paragraph implies that the mechanisms are only applicable to
>>> RFC2986 or RFC4211 contexts. Is there some reason these could not be used
>>> in SCEP, CMPv2 (or later), CMC, EST, future protocols, etc. Maybe replace
>>> "in
>>> either" with "such as" to avoid this limitation. There are many places in
>>> the
>>> draft that appear to limit use to PKCS #10 and CRMF, however.
>> 
>> not an expert, but mentioning re-usability gets a +1 from me, if other
>> contributors do not have objections.
>> 
> 
> 
> Certificate signing requests formats like RFC 2986 (PKCS#10) and RFC 4211
> (Certificate Request Message Format, CRMF) provide binding the public key with
> the requested certificate content and a proof-of-private-key-possession.
> CMP/CMC/EST/SCEP provide the binding of a certificate request (PKCS#10/CRMF)
> to a proof-of-identity.
> By using either PKCS#10 or CRMF, the above-mentioned certificate
> management/enrollmnet protocols can utilize the attribute/extension defined
> here.
> @Carl, does this answer your question?
> 
> 
> Hendrik
> 
>