Re: [lamps] EST CSR attrs discussion

[Dan Harkins <[e-mail]>]

   Hi David,

   CSR Attrs isn't the tool for you obviously. If you want to impose 
some naming
structure on particular fields of the CSR on the entity constructing a 
CSR then
you'll have to define your own tool with an unambiguous systematic 
definition,
making sure it fits other contexts and doesn't allow conflicting 
requirements.
I'm excited to see it!

   Dan.

On 7/29/21 1:24 PM, David von Oheimb wrote:
> Hi Dan,
>
> thank you for your response, which helps clarifying the intention of 
> the EST CSRAttrs feature.
>
> At least it makes clear that there was no aim to to give the option to 
> provide concrete values for attributes.
> They may have have been useful/needed, though, to state for instance 
> that the subject DN should include a certain organization name, 
> location, etc.
> Note that there are CAs around where policies can be defined giving 
> constrains on such fields that must be adhered to by cert requestors.
>
> It also confirms my criticism that the whole construct is entirely 
> ad-hoc. That is, the attributes provided do not have a clear meaning.
> There are just some examples that give some hints how certain OIDs and 
> related values can be interpreted.
> Since there is no systematic definition, the implementors of the 
> server and client side need to seek agreement beforehand on each 
> attribute potentially used.
> There are also ambiguities on the values - for instance, it is 
> intuitive that the integer that may follow the rsaEncryption OID 
> should be interpreted as the modulus size in bits, but it could also 
> be seen as the public exponent to use, for instance, or the width of a 
> SHA algorithm to use for RSA signatures, or whatever.
> Also the mix of OIDs in the extensionRequest sub-sequence is a bit 
> strange, where e.g, the serialNumber OID makes little sense within an 
> X.509 extension.
> It was likely meant as a specifier of an RDN to include in the subject 
> to be certified, but such a guessing could go wrong, and technically 
> it would fit also in other contexts, for instance an issuer field 
> potentially included in the CSR.
> Moreover, there is the possibility to give conflicting requirements, 
> such as ecdsaWithSHA384 and SHA256, and there is no specification how 
> to avoid or handle such situations.
> Still with some goodwill the feature can be used, which boils down to 
> having to hard-code the interpretation consistently in all potential 
> client and the server(s). Yet this is not interoperable.
>
> Regards,
>     David
>
>
>
> On 29.07.21 20:31, Dan Harkins wrote:
>>
>>   Hi,
>>
>>   Sorry, I wasn't aware that this issue was being discussed and I wasn't
>> on the lamps/spasm list. But I'm largely responsible-- i.e. to 
>> blame-- for
>> the CSR Attrs text in RFC 7030 so perhaps I can try and explain.
>>
>>   The intent of the CSR Attrs request is for the RA to ask the client
>> to construct the CSR in some particular way, not to impose values on
>> particular fields.
>>
>>   As a for-instance, the RA could ask the client to:
>>
>>    1. generate a public key in the NIST p384 curve;
>>    2. use ECDSA w/SHA384 to sign
>>    3. include the challengePassword
>>    4. include an extension with the device's serial number, a subject 
>> alt
>>       name, and its favorite drink
>>
>> by sending the following base64-encoded blob:
>>
>> ME4GCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMCMGCSqGSIb3DQEJDjEWBgNVBAUGA1UdEQYKCZImiZPyLGQBBQYIKoZIzj0EAwM 
>>
>>
>> That gets ASN.1 decoded as:
>>
>> SEQUENCE (4 elem)
>>   OBJECT IDENTIFIER 1.2.840.113549.1.9.7 challengePassword (PKCS #9)
>>   SEQUENCE (2 elem)
>>     OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 
>> public key type)
>>     SET (1 elem)
>>       OBJECT IDENTIFIER 1.3.132.0.34 secp384r1 (SECG (Certicom) named 
>> elliptic curve)
>>   SEQUENCE (2 elem)
>>     OBJECT IDENTIFIER 1.2.840.113549.1.9.14 extensionRequest (PKCS #9 
>> via CRMF)
>>     SET (3 elem)
>>       OBJECT IDENTIFIER 2.5.4.5 serialNumber (X.520 DN component)
>>       OBJECT IDENTIFIER 2.5.29.17 subjectAltName (X.509 extension)
>>       OBJECT IDENTIFIER 0.9.2342.19200300.100.1.5 (favorite drink)
>>   OBJECT IDENTIFIER 1.2.840.10045.4.3.3 ecdsaWithSHA384 (ANSI X9.62 
>> ECDSA algorithm with SHA384)
>>
>> And the client produces a CSR with an extension that gives its serial 
>> number,
>> some alternative name, and whatever drink it prefers. The idea isn't 
>> that the
>> RA would say, "your serial number is 279372 and you like scotch", 
>> it's "what
>> is your serial number and favorite drink?".
>>
>>   If the RA wanted a particular length of RSA key, let's say of 3072 
>> bits, to
>> sign with a hash function appropriate for that bit length, and 
>> include the
>> challengePassword it would ask thusly:
>>
>> MCkGCSqGSIb3DQEJBzARBgkqhkiG9w0BAQExBAICDAAGCSqGSIb3DQEBCw==
>>
>> which gets decoded as:
>>
>> SEQUENCE (3 elem)
>>   OBJECT IDENTIFIER 1.2.840.113549.1.9.7 challengePassword (PKCS #9)
>>   SEQUENCE (2 elem)
>>     OBJECT IDENTIFIER 1.2.840.113549.1.1.1 rsaEncryption (PKCS #1)
>>     SET (1 elem)
>>       INTEGER 3072
>>   OBJECT IDENTIFIER 1.2.840.113549.1.1.11 sha256WithRSAEncryption 
>> (PKCS #1)
>>
>>   The idea is, this is a request to the client on how to generate a 
>> CSR in
>> the form that the CA expects/wants. One asks what a subject 
>> alternative name
>> would be, it doesn't impose one on the client.
>>
>>   That was the intent anyway. And that's how I implemented it in my EST
>> reference implementation.
>>
>>   regards,
>>
>>   Dan.
>>
>

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius