Re: [lamps] is the CSRattr ASN.1 broken or not ... Re: New Version Notification for draft-richardson-lamps-rfc7030-csrattrs-02.txt

[Russ Housley <[e-mail]>]

> On Apr 5, 2022, at 3:28 PM, Sean Turner <[e-mail]> wrote:
> 
> 
> 
>> On Apr 5, 2022, at 14:40, Russ Housley <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Apr 5, 2022, at 2:18 PM, Michael Richardson <[e-mail]> wrote:
>>> 
>>> David von Oheimb <[e-mail]> wrote:
>>>> As I wrote earlier, the way CSRattrs are defined for EST in RFC
>>>> 7030 section 4.5.2:
>>> 
>>>> CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
>>> 
>>>> AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
>>> 
>>>> Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
>>>> type ATTRIBUTE.&id({IOSet}),
>>>> values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
>>> 
>>> Is there another way to express the same concept that would be understandable
>>> to more people?
>> 
>> 
>> I do not know whether the OLD ASN.1 syntax is easier to read for some.  This would be:
>> 
>>   CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
>> 
>>   AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
>> 
>>   Attribute ::= SEQUENCE {
>>     type     AttributeType,
>>     values    SET SIZE(1..MAX) OF AttributeValue }
>> 
>>   AttributeType ::= OBJECT IDENTIFIER
>> 
>>   AttributeValue ::= ANY DEFINED BY AttributeType
>> 
>> Russ
> 
> The problem really comes down to how extensionRequest is encoded. extensionRequest is defined in RFC 2985) as:
> 
>   extensionRequest ATTRIBUTE ::= {
>           WITH SYNTAX ExtensionRequest
>           SINGLE VALUE TRUE
>           ID pkcs-9-at-extensionRequest
>   }
> 
>   ExtensionRequest ::= Extensions
> 
> Then Extensions (using old syntax from 5280):
> 
> Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
> 
>   Extension  ::=  SEQUENCE  {
>        extnID      OBJECT IDENTIFIER,
>        critical    BOOLEAN DEFAULT FALSE,
>        extnValue   OCTET STRING
>                    -- contains the DER encoding of an ASN.1 value
>                    -- corresponding to the extension type identified
>                    -- by extnID
>        }
> 
> So, if you’re going to encode that you need a lot more than just an OID, as is in the example:
> 
> In the example:
> 
> SEQUENCE (4 elem)
> … snip
>  SEQUENCE (2 elem)
>    OBJECT IDENTIFIER 1.2.840.113549.1.9.14 extensionRequest (PKCS #9 via CRMF)
>    SET (1 elem)
>      OBJECT IDENTIFIER 1.3.6.1.1.1.1.22 (macAddress). <—“values" here
> ..snip
> 

RFC 7030 shows this example:

  0  65: SEQUENCE {
  2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
 13  18:   SEQUENCE {
 15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
 24   7:     SET {
 26   5:       OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
       :       }
       :     }
 33  22:   SEQUENCE {
 35   9:     OBJECT IDENTIFIER extensionRequest (1 2 840 113549 1 9 14)
 46   9:     SET {
 48   7:       OBJECT IDENTIFIER '1 3 6 1 1 1 1 22'
       :       }
       :     }
 57   8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
       :   }


Maybe this is what you meant when you said that the example is wrong.  You mean that the example fails to include the ExtensionRequest as the values field in the attribute.

   ExtensionRequest ::= Extensions


> If macAddress is included as an extension, then it would need to say whether it’s critical or not and we’d need to provide a value. The “values” portion of the SET OF needs to be:
> SEQ OF (for Extensions)
>  SEQ (for Extension)
>   { extrnID=macAddress OID,
>    criticality=T/F (CP dependent),
>    extnValue=? } 

The problem is that the EST server is saying that the CSR needs to include the extensionRequest attribute, and that the SEQUENCE OF Extension needs to include the macAddress extension.  The EST server expects the client to fill in the MAC address.  The EST server does not know the client's MAC address, so it cannot fill it in.  It could put a zero-length OCTET STRING, but that is not ideal.

Russ