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]>]

I would like to up-level this discussion.  Since the CrsAttrs is flexible enough that more than one way to use it has been described for the very same CSR information, I suspect that what we need is to specify conventions for the CSR information that people are actually using.  And, we can add more in the future if needed.

Looking to RFC 7030, there are several cases that are discussed in Section 4.5.2:

- the CA requires a particular crypto system

- the CA requires use of a particular signature scheme

- the EST server requires the linking of identity

- the EST server requires POP information

And, for some of the above, it includes guidance:

-  Requests to use a particular signature scheme (e.g. using a
   particular hash function) are represented as an OID to be reflected
   in the SignatureAlgorithm of the CSR

-  Requests to use a particular
   crypto system (e.g., certification of a public key based on a certain
   elliptic curve) are represented as an attribute, to be reflected as
   the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
   indicating the algorithm and the values indicating the particular
   parameters specific to the algorithm

-  Requests for descriptive
   information from the client are made by an attribute, to be
   represented as Attributes of the CSR, with a type indicating the
   [RFC2985] extensionRequest and the values indicating the particular
   attributes desired to be included in the resulting certificate's
   extensions

So, can we list various CSR information that people actually use or want to use, and then specify conventions for each one.

The convention should say what the EST server puts in this structure, and the expected result in the CSR if the EST client understands that OID.

Russ


> On Apr 5, 2022, at 8:30 AM, 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 <mailto:{IOSet}{@type>}) }
> 
> is 
> 
> * pretty incomprehensible, at least for ASN.1 non-experts
> * very ambiguous: how to interpret bare OIDs and attribute type OIDs that the server my throw in is not really defined, apart from a few hints and examples,
>   and it is left entirely open which values are allowed for which attribute type OIDs
> * not fully expressive: at least subject DNs (or parts of them) cannot be specified
> 
> Moreover, as recently discussed here again, the example given in RFC 7030 for the macAddress extension was pretty unfortunate in the sense that
> it seemed to preclude the case that an actual extension value is given by the server, while I agree with Sean that the above weird ASN.1 syntax should allow for that.
> 
> 
> On Tue, 2022-03-29 at 13:31 -0400, Sean Turner wrote:
>> 
>> So that base64 blob turns into the following (this is not actual ASN.1. I trimmed SEQUENCE -> SEQ, OBJECT IDENTIFIER -> OID, etc. to make it prettier)
>> 
>> SEQ (4 elem)
>>   OID 1.2.840.113549.1.9.7 challengePassword (PKCS #9)
>>   SEQ (2 elem)
>>     OID 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)
>>     SEQ OF (1 elem)
>>       OID 1.3.132.0.34 secp384r1 (SECG (Certicom) named elliptic curve)
>>   SEQ (2 elem)
>>     OID 1.2.840.113549.1.9.14 extensionRequest (PKCS #9 via CRMF)
>>     SEQ OF (1 elem)
>>       OID 1.3.6.1.1.1.1.22
>>   OID 1.2.840.10045.4.3.3 ecdsaWithSHA384 (ANSI X9.62 ECDSA algorithm with SHA384)
>> 
>> What I am saying is either:
>> 
>> a) The PKCS #9 via CRMF extensionRequest attribute should have had a properly encoded attribute when it was sent to the client. I mean strictly speaking the extensionRequest does include a type/value where type=extensionRequest and value=OID for macAdddress. BUT, the macAddress attribute also has a type/value that should have been included. This is how the attribute is defined (loosely):
>> 
>>         ( nisSchema.1.22 NAME 'macAddress'
>>           DESC 'MAC address in maximal, colon separated hex
>>                 notation, eg. 00:00:92:90:ee:e2'
>>           EQUALITY caseIgnoreIA5Match
>>           SYNTAX 'IA5String{128}' )
>> 
>> We really shouldn’t have just dropped the value part of the attribute/extension carried in extensionRequest.  We could have said set the macAddress to “00" and then the client could include their actual mac address. But alas, we didn’t.
> 
> The question is which kind of values (of type ATTRIBUTE.&Type({IOSet}{@type <mailto:{IOSet}{@type>}) ) should be given
> in case the OID  (of type  ATTRIBUTE.&id({IOSet})) is 1.2.840.113549.1.9.14 extensionRequest:
> Is each such value supposed to be 
> 1. an OID of an X.509 extension, such as 1.3.6.1.1.1.1.22 (macAddress), without a value, or
> 2. an actual X.509 extension of the existing type Extension (or Extensions) as defined in RFC 5280 section 4.1,
>     for example the OID 1.3.6.1.1.1.1.22 followed by the 'critical' flag and its actual value encoded as an OCTET STRING
> 
> Note that for syntactic and semantics reasons you cannot have both - either 
> 1. the example given in RFC 7030 was correct, then no X.509 extension value can be given by the server, or
> 2. the example was wrong, and a value must be given by the server. 
>     Yet the OCTET STRING could be the empty string to indicate that the client should fill in the real value.
>     The Lightweight CMP Profile also employs this trick of using an empty extnValue
>     in its section 4.3.3. (Get certificate request template):
>     https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.3.3 <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.3.3>
> 
> The latter option is obviously more expressive, but note that this contradicts the example of RFC 7030, 
> and thus chances are high that (most) existing EST implementations chose the first option, which is not compatible with the second.
> 
> 
>> b) We picked the wrong kind attribute to request macAddress from the client. I cannot remember if it’s supposed to be naming component or an actual extension?
> 
> Apart from the two possibilities I just gave, I do not see how else, given given the CsrAttrs syntax, 
> one should have requested a macAddress X.509 extension where the value is to be filled by the client.
> 
> 
>> 
>>>   As an aside, why can't the RA just rewrite the CSR and include the
>>> particular name it wants to impose on the EE? Yes, signature will be
>>> wrong but the CA shouldn't care because the RA is vouching for it.
>>> Right? Why won't that also fix this problem?
>> 
>> In most instances, the RA could amend the CSR by adding/changing values. The CA would trust a valid sig from the RA to vouch for the changes.
> 
> As I commented earlier,
> PKCS#10 requires a self-signature within the CSR structure, which that RA cannot provide, so there are basically two options:
> * cheat and give a bogus signature to be ignored by the CA, or 
> * switch to a more expressive CSR syntax like CRMF, which supports popo=raVerified
>    (i.e., the RA vouches for having checked the original proof of possession by the client and does not provide a new one) 
> 
> 
> On Fri, 2022-03-25 at 07:35 -0400, Sean Turner wrote:
>> Sorry if I wasn’t clearer before about a “fix”. I think the examples in RFC 7030 could be fixed and maybe make it clear that you either send the “oid” if the server is saying hey send me a request with a value that you (the client) supply or “attribute” if the server is saying he send me a request with a value that I (the server) supply. Right now, RFC 7030 s4.5.2 includes an ASN.1 blob for the following examples:
>> 
>>        OID:        challengePassword (1.2.840.113549.1.9.7)
>> 
>>          Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
>>                      value = macAddress (1.3.6.1.1.1.1.22)
>> 
>>          Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
>>                      value = secp384r1 (1.3.132.0.34)
>> 
>>          OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)
>> 
>> We can expand the examples to:
>> 
>> 1. Include a challengePassword with a value (caveats included about making sure it is protected when in transit) using the Attribute option.
> 
> It would make little sense for the server to provide a challengePassword value - this is to be given by the client in order to authenticate itself.
> 
> 
>> 2. Modify the extensionRequest example to include the right attribute value:
>> 
>> ExtensionRequest ::= Extensions
>> 
>> 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
>>         }
>> 
>> Where:
>> 
>> extnID: 1.3.6.1.1.1.1.22
>> critical: FALSE and not encoded.
>> extnValue’s OCTET STRING is an IA5String.
>> 
>> This making sense?
> 
> Yes - using the existing (Extensions or) Extension datatype does make sense.
> This is one of the two options I also describe above.
> 
> 	David
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm