Subject: Using PKIX - msg#00287

Previous Message by Date: click to view message preview

Re: Comments on pkix-ipki-part1

At 12:23 3/20/98 -0500, Russ Housley wrote: >At 05:13 PM 3/19/98 +1200, Peter Gutmann wrote: >>4.2.1.2. >> >>This gives the subject key identifier as the hash of the subjectPublicKeyInfo >>*without* the tag and length. Is this a mistake, or is it meant to be like >>that? Every other instance in which an ASN.1 object is hashed (eg >>certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes the >>entire object. In fact the PKIX CMP draft uses a hash of the full >>subjectPublicKeyInfo in the OOBCertHash, which would make it incompatible >with >>the value in the subject key identifier. Requiring a well-defined standard >>X.509 object to be broken up into pieces before processing it seems an >>extremely peculiar move, so I'm guessing it's some sort of mistake in the >spec. > >This was done prior to the CMP section. To use the public key, you need to >get the value out of the certificate without the associated ASN.1 stuff, so >that was the reason we chose to hash just the key. However, for RSA public keys you still have ASN.1 there, since the public key consists of n and e, which are coded as ASN.1 sequence. Therefore, your reasoning does not hold. I suggest to use whole SubjectPublicKeyInfo for calculation of key ids, to avoid confusion and have compatibility with CMP OOBCertHash. .... >>7.3.2. >> >>This gives a redundant definition of the DH p and g values (the ASN.1 >>definition is followed immediately by text which says exactly the same >thing - >>actually the RSA definition does this too with n and e), but doesn't explain >>the INTEGER which is the DH public key (what *is* this value? The only thing >>I can think of is g^x mod p, but that shouldn't be a fixed value). It also >>goes to some lengths to explain the encoding of the INTEGER parameter as a >BIT >>STRING, which seems very odd. > >Whould you like to suggest improved text? > >Russ > I would like to suggest the following change in the text: Instead of: "The Diffie-Hellman public key (an INTEGER) is mapped to a subjectPublicKey (a BIT STRING) as follows: the most significant bit (MSB) of the INTEGER becomes the MSB of the BIT STRING; the least significant bit (LSB) of the INTEGER becomes the LSB of the BIT STRING." to have: "The DSA public key shall be ASN.1 encoded as an INTEGER; this encoding shall be used as the contents (i.e., the value) of the subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo data element. DHPublicKey ::= INTEGER -- public key y = g^x mod p" This would be in accordance with DSA public key definition from 7.3.3. Regards, Nada ______________________________________________________________ Nada Kapidzic Cicovic COST - Computer Security Technologies CST AB (subsidiary of Entegrity Solutions Corporation) office: + 46 (0)8 477 77 37 mobile: + 46 (0)70 495 09 03 fax: + 46 (0)8 477 77 31 e-mail: nada@xxxxxxx or nada@xxxxxxxxxxxxx address: Finlandsgatan 60, 164 74 Kista, Sweden

Next Message by Date: click to view message preview

Re: Using PKIX

Hi Frederik, >---------- >From: Frederik Loeckx[SMTP:FRL@xxxxxxxxxxxxxx] >Sent: Tuesday, March 24, 1998 7:46 AM >To: IETF-PKIX@xxxxxxxxxxxxxxxx >Subject: [IETF-PKIX] Using PKIX > >Hello everybody, > >I am trying to fit the PKIX messages onto some global Public Key >Infrastructures I can think off. > >This exercise was pretty usefull and most of the cases are fully covered by >PKIX. There are however two situations in which I don't know what to do. >Perhaps the list can help me finding a way out. The situations you describe are not explicitly covered by the CMP/CRMF documents. However, these documents specify a framework within which you can certainly accommodate what you need. >1) Yes, I am also a European guy addicted to Hardware Tokens. My question >is about how to make a distinction between a Hardware Key and a Software >one. Suppose you have a Certification Authority which supports centralised >key generation, both in software and on hardware tokens (suppose one of the >Internet CA's would like to do this), > 1) How can an EE tell the CA where to store the Certificate and the >secret key? There are a couple of options here. I think the preferred route is to define another choice for the PKIArchiveOptions control in CRMF (something like "storeOnHardwareToken [3] BOOLEAN"). The second possibility is to define a new Control for the request (again, something like "StoreOnHardwareToken ::= BOOLEAN"). Note that in either case, the CMP CertResponse message would have a status of "granted" but would omit the optional certifiedKeyPair. > 2) Is there a way to transmit all the stuff to use the smartcard >(unblocking PIN, access PIN, ..) along with the message in a secured way? Yes. Since this is not specific to each certificate in the CMP CertReqMessages or CertRepMessage (assuming there are multiple), but is instead related to the message as a whole, this is a good example of a use for the generalInfo field of the CMP PKIHeader. An InfoTypeAndValue can be defined to carry this data (perhaps with syntax EncryptedValue from CRMF). Note that if this data is generated by the CA and sent to the EE (e.g., for cases in which the CA initializes the hardware token itself) then the EE should send a protocolEncryptionKey control in the CertRequest so that the data can be protected for confidentiality. >2) I have a problem with the CertTemplate where the whole >SubjectPublicKeyInfo is treated as one big entity. Suppose (in the same >case of centralised keygen), I want to be able to request a 1024 bit RSA >key (and not an 512 bit one). This means I need to transmit the modulus >length somewhere in the message. The only possibility I have found, is to >include some dummy modulus and exponent in the SubjectPublicKeyInfo field. >But now the CA thinks I am asking him to certify my public key instead of >generating a new keypair for me. Am I missing something? There are three possibilities here. I think the preferred route is to send nothing in the SubjectPublicKeyInfo but to send a protocolEncryptionKey control (the size of the modulus in the protocol encryption key dictates the size to use for the modulus of the centrally-generated key pair). Another alternative is the one you suggest in which a modulus and exponent are transmitted but are clearly not intended as the public key (e.g., a modulus of 2**1023 and an exponent of 0). Thirdly, a new control can be defined for the request (something like "SizeOfReqModulus ::= INTEGER"). Again, the situations you describe can be handled in the existing CMP/CRMF framework. Furthermore, one or more of the proposals presented above can be standardized if there is sufficient interest in doing so. Thanks for your interest! -------------------------------------------- Carlisle Adams Entrust Technologies cadams@xxxxxxxxxxx --------------------------------------------

Previous Message by Thread: click to view message preview

Comments on draft CMMF-00

Here are the first set of comments that I have on this draft: 1. Lets combine this with CRMF to produce a single draft of all messages. The reasons for breaking them into two drafts no longer exist to the best of my knowledge. 2. Formatting issue: Should be some space before the start of section 4. 3. Section 4.2 - Need to put in a defintion for PKIFreeText into this draft. Should not have to reference CMP for this, it is now a primitive. 4. Section 4.4 - I can see the use of having both encryptedValue and cMSEnveloped in the EncryptedData type, however I see no use for the last two types. All they are doing is making the structures more difficult and harder to interop with, more options mean more problems. Additionally I have heard of no current efforts to move the PKCS #8 and 12 into IETF drafts. 5. Section 4.4 - I don't understand the reasoning behind the fact that RSA uses a symmetric key and D-H does not. It seems reasonable to me to say that you don't need to have the encrypted symmetric key in D-H, but allow it anyway. If you are going to put the text in this manner please change it to working such as the following: "For key agreement algorithms (such as Diffie-Hellman), the encSymmKey field of EncryptedValue is not included. For key exchange algorithms (such as RSA), the encSymmKey is a symmetric key encrypted under the subscriber's public key." 6. Section 5.2.1 -- I need far more information about what the structure of rspInfo should be? If we don't define it then we can't possibly get a get interopability. There appears to be a vague reference to it being name/value pairs, but this is not certian from the text. 7. Section 5.1 - Please add a certReqId to the PKCSReq type. This allows for a correct value to be placed in a CertRepContent in the event that multiple PKCSReqs are sent to a CA. 8. Section 5.3 - Need to add a CertReqId to this message. If multiple requests have been sent in then this would be needed to disabmiguate the different requests. 9. Section 5.3 - Does this imply that you must put a subject and issuer into the certificate request if you want to use this polling method? Does this imply that a CA cannot return PENDING as a code in the event that a subject and issuer name have not been placed in the request? or just that the certificates cannot be polled for? 10. Section 5.4 - How do I retrieve a CRL in the event that the CA has an empty Issuer name? Do I put the empty name in the issuerName field or do I extract a portion of the IssuerAltName? 11. Section 5.5.1 - Should change PrintableString to UTF8string in the RevRequest ASN. 12. Section 5.5.1 - Why is there not a SEQUENCE OF RevRequest defined? The text about certDetails in RevReqContent implies to me that the RevRequest form would be perfered if you actually knew the issuer and serial number. I see nothing which would prevent the usage of the RevReqContent except for the "I don't have access to my keys any more" case. 13. Section 5.6 - Please change the first sentence to: "The response to the RevReqContent message." I am making an assumption that this message would not be generated in response to a RevRequest message since the first sentence is currently singular rather than plural. This may be a bad assumption. 14. Section 5.7 - Please change FullCertTemplates in the comment for POPODecKeyChallContent to CertReqMessages. 15. Section 5.7 - In order to make the association between the request and the challenge clearer, I strongly suggest adding a CertReqId field to the Challenge structure. This means that we could remove the order association in the comment on POPODecKeyChallContent if desired and still have correct associations. 16. Section 5.7 - It would appear to be that something should definitely be said about the suggested length of A being used in the challenge, I also see some potential problems about the total length of the integer and the senders GeneralName. What should be done if the encoding of Rand happens to be larger than the longest value that is encryptable by the public key? If you are using a bulk algorithm for doing the key exchange/key agreement versions, then you must specify the AlgorithmIdentifier of the bulk encryption algorithm. 17. Section 5.7 - What would be the correct way to say that I failed to do this? THere is a success body content defined but not a failure body. I can see this as possibly being handled in the overlying protocal but that potentically should be stated. 18. Section 5.7 - There is a reference to PKIHeader, but I can not find the defintion of this in either CRMF or CMMF. Please put in a defintion or correct the reference. 19. Section 5.9 - The second sentence in this paragraph implies that I will be generating a response to these announcement messages. I cannot believe that this is what was intended. I would suggest "These messages are generally unsolicited and may be received by End Entities at random times." 20. Section 5.9.1 - I disagree that the old CA private key is no longer required after sending out this message. I think that you still need the old CA private key to produce CRLs right up to the time that the old CA certificate expires. Here the the problem that I see with your statement. Lets say that I am using my own private CA which is publishing CRLs via an HTTP link. I send you a signed message with my certificates and the current (old) chain. The CA then updates it key set and send me the information and publishes out a CRL signed with its (new) private key. You then attempt to verify the message I sent you and pick up the CRL. You are unable to verify the signature on the CRL and thus the message I sent you. If I now send you a new message it will verify since I have the new chain of certificates to send to you. This is fine in a closed environment but not on the internet. 21. Section 5.10 - From the fact that the CA is just anouncing this information, am I correct in assuming that the request for this would come from an Out-Of-Band request? It makes no sense to me that this would just randomly show up in my mailbox. I would feel very srongly that this should be an explicit request/reply message in the normal format rather than tan anouncement message. 22. Section 5.10 - The structure includes a field for newSigCert, how and where was the request for this certificate made if this is just a random annoucement? (I use the words random from a client point of view. I know that the CA will only generate this message in response to some well defined events, but the client does not see those events.) 23. Section 5.11 - There are a set of examples that are partially defined. It would appear that atleast some of the items in the examples (CAKeyUpdateInfo) are explicitly called out in the spec and therefore should not appear here. 24. Section 5.11/5.12 -- I give up. This is not defined enough for me to even start to understand how to use these messages. 25. Section 6. There is a warning in this section about the unadvisablity of doing arbitrary decryptions and sending them back to somebody. It would appear to me that this is very close to what is being done in the challenge/response POP seqeuences. I think a paragraph either here or in the section on the POP messages would be in order about why I should not consider this to be an explicitly documented version of this attack I am suppose to ipmlement. 26. Need an appendix containing the ASN pulled out into a single module for easy reference. jim schaad

Next Message by Thread: click to view message preview

Re: Using PKIX

At 07:46 AM 3/24/98 -0500, Frederik Loeckx wrote: >1) Yes, I am also a European guy addicted to Hardware Tokens. My question >is about how to make a distinction between a Hardware Key and a Software >one. Suppose you have a Certification Authority which supports centralised >key generation, both in software and on hardware tokens (suppose one of the >Internet CA's would like to do this), > 1) How can an EE tell the CA where to store the Certificate and the >secret key? Is this really necessary? If the CA sends the centrally generated keying material to the EE, the EE will store it in the appropriate place. When a hardware token is used, I would hope that the keying material to revover the private key is available only on that token. In this case, the private key cannot be used until it is put on the token and recovered. > 2) Is there a way to transmit all the stuff to use the smartcard >(unblocking PIN, access PIN, ..) along with the message in a secured way? This is a good question. PKIX has never looked at the issues associated with distributing token specific information. It might be useful to define extensions to the protocols (once they are stable) for this information. All of the protocols have extension mechanisms. Russ