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

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

The problem space is a little more tricky:

* Backward compatibility is an important aim.

  In case it turns out that compatibility anyway needs to be abandoned,
  I'd suggest the following straightforward fully to-the-point type,
  which does not require any (direct) OIDs:

   CsrAttrs ::= SEQUENCE {
        subject               Name OPTIONAL,
        extensions            SEQUENCE OF Extension, /* use empty extnValue for those extensions to be filled in by client */
        challengePassword     BOOLEAN,
        keySpec           [0] KeySpec OPTIONAL,
        hashAlg           [1] AlgorithmIdentifier OPTIONAL

   }

* The ambiguity between the server specifying required X.509 extension
OIDs or actual X.509 extension values needs to be sorted out, on a per-
extension basis.
   That is, it should be made possible to specify a set of extensions to
be included in the CSR, where for each of them the server may provide
the value or not.

 David

On Tue, 2022-04-05 at 10:00 -0400, Russ Housley wrote:
> 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}) }
> > 
> > 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}) ) 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
> > 
> > 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
> > 
>