Re: [lamps] EST CSR attrs discussion

[Eliot Lear <[e-mail]>]

Yes, this was my understanding as well.  In our implementation we did 
indeed end up having a backchannel to the CA for fields for which the RA 
had the content.  But I'm not sure it's the right long term approach, 
since that code can't be easily ported.  What I conclude, tho, is that 
the structure is a bit opaque, and really could stand for further 
elaboration, since it does seem one CAN specify values.  The best way to 
do that is probably a draft, aiming toward informational, but I'm out of 
bandwidth at the moment.

Eliot

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