Re: [lamps] I-D Action: draft-ietf-lamps-rfc7030-csrattrs-05.txt

[David von Oheimb <[e-mail]>]

Thanks Sean for pointing out the (to us authors surprising) overlap of 
our new proposal with RFC 8925 in yesterday's IETF 177 LAMPS session.
A pity you could not make it to our online design meeting on July 5th, 
were we could have discussed this beforehand,
and apparently you did not have a close look at my email of July 14th 
where I gave and explained all the details.

On 28.07.23 00:51, Sean Turner wrote:
> The RFC I mentioned at the mic was RFC 8925 [0]; looks in Appendix B.  It proposed sticking a CSR template, which is a pKCS7PDU ATTRIBUTE, in csrattrs.
> [0]https://datatracker.ietf.org/doc/rfc8295/
I meanwhile had a closer look at that appendix and related definitions 
in other RFCs (thanks Steffen for providing me helpful pointers).
Yes, the general idea is quite the same. (BTW, as mentioned before, 
essentially the same idea is used also for CMP in
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#name-get-certificate-request-tem.)

Yet the solution given in RFC 8925 differs from our new proposal in 
several respects, which include:

 1. It allows giving a sequence of CSR templates, which presumably is
    not needed for the EST context (and at least so far not intended to
    support).
 2. It also provides the possibility to give a CertReqMsg (in CRMF
    format), which is not needed in the EST context as it uses CSRs in
    PKCS#10 format only.
 3. For both variants, it requires giving a full CSR structure, which in
    the PKCS#10 case implies mandatory inclusion of a public key and a
    self-signature.
 4. For the PKCS#10 variant, the type is TaggedCertificationRequest (see
    definition in https://www.rfc-editor.org/rfc/rfc5272#section-3.2.1.2.1),
    which includes a bodyPartID field not needed for the EST use case.

To me, point 3. makes the approach sketched in RFC 8925 Appendix B not 
really feasible or at least needlessly ugly,
as the server side would have to use a fake/temporary key pair just to 
satisfy the structural requirements of PKCS#10.

Note that our new proposal does not include a full (PKCS#10) CSR but 
just the "to-be-signed" part:

CertificationRequestInfo ::= SEQUENCE {
         version       INTEGER { v1(0) } (v1,...),
         subject       Name,
         subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
         attributes    [0] Attributes{{ CRIAttributes }}
    }

This way, we avoid the need to provide the (for the given use case) 
useless and awkward self-signature.
Moreover, as not mentioned in detail in yesterday's talk, we also 
foresee the options to

  * either specify in the AlgorithmIdentifier of the subjectPKInfo field
    the type of the key pair the client side is requested use
  * or to give a NULL OID in this AlgorithmIdentifier to indicate that
    the server has no requirements on the key type.

> Note that the appendix is informative and maybe not as detailed as it might have been.  I support the idea of moving the idea to a normative section of a document!
Pleased to hear!
Indeed, our new proposal for the upcoming improvement of the CsrAttrs 
aspect of RFC 7030 is going to provide all detail needed for practical use -
in particular, a specification of how the server shall specify that 
certain (sub-)values of certain CSR fields should be filled in by the 
client,
basically as done already in 
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#name-get-certificate-request-tem 


     David

>> On Jul 9, 2023, at 18:20,[e-mail]  wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This Internet-Draft is a work item of the Limited Additional
>> Mechanisms for PKIX and SMIME (LAMPS) WG of the IETF.
>>
>>    Title           : Clarification of RFC7030 CSR Attributes definition
>>    Authors         : Michael Richardson
>>                      Owen Friel
>>                      Dr. David von Oheimb
>>                      Dan Harkins
>>    Filename        : draft-ietf-lamps-rfc7030-csrattrs-05.txt
>>    Pages           : 15
>>    Date            : 2023-07-09
>>
>> Abstract:
>>    The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in
>>    its specification of the CSR Attributes Response.  This has resulted
>>    in implementation challenges and implementor confusion.
>>
>>    This document updates RFC7030 (EST) and clarifies how the CSR
>>    Attributes Response can be used by an EST server to specify both CSR
>>    attribute OIDs and also CSR attribute values, in particular X.509
>>    extension values, that the server expects the client to include in
>>    subsequent CSR request.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030-csrattrs/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-lamps-rfc7030-csrattrs-05.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lamps-rfc7030-csrattrs-05
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories:http://www.ietf.org/shadow.html
>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>