PFX: How Not to Design a Crypto Protocol/Standard (1998)
cs.auckland.ac.nz
PFX: How Not to Design a Crypto Protocol/Standard (1998)
1–10 of 13 posts
Re: PFX: How Not to Design a Crypto Protocol/Standard (1998)
#2A “standard” based off a proposal from Microsoft. Run through the RSA committee. Implemented by two relatively young engineers. One at Netscape. One at Microsoft.
I was on the Netscape side of the house.
I love when this article pops up.
I learned a lot about ASN1and BER/DER coding in the process.
Re: PFX: How Not to Design a Crypto Protocol/Standard (1998)
#3Peter Gutmann's library was at one point the only code I could find to perform the minor magic of taking a certificate and using it to make a new certification outcome under your own CA.
I never understood why people go to issuing with new private keys when an existing Certificate can be used as a CSR. Shiploads of process would be simpler if you kept the same private key until it was clear you needed a new one, which is much rarer than people think, in these days of keystores, yubikeys and keychain managers and long RSA keys.
I wish it was the fabric of routine Unix cryptography and not openssl, at this stage in both codebase's life. It's smaller. That alone, LOC to understand, is huge.
There's stuff it can't do, hasn't been added like ARM optimised code, which is a shame. Maybe one day.
Re: PFX: How Not to Design a Crypto Protocol/Standard (1998)
#4Peter Gutmann's library was at one point the only code I could find to perform the minor magic of taking a certificate and using it to make a new certification outcome under your own CA. I never understood why people go to issuing with new private keys when an existing Certificate can be used as a CSR. Shiploads of process would be simpler if you kept the same private key until it was clear you needed a new one, whic…
But a Certificate isn't a CSR.
CAs can do whatever magic they want here†, but, they probably shouldn't.
If you're comfortable keeping the same keys, which, sure, in some situations is fine (although a loss of agility can hurt you if you didn't understand what you were doing and then have to change keys unexpectedly) you can use the same CSR over and over to apply for the new certificates.
† There are a bunch of rules, but, not relevant to this particular issue.
Re: PFX: How Not to Design a Crypto Protocol/Standard (1998)
#5> By far the most widely-used character set, and the one which is easiest to work with for most implementors, is ASCII (IA5String) or latin-1 (T61String). Coming in a rather distant second is Unicode (BMPString), which has somewhat patchy support on most systems and is often difficult to convert into anything useful. Allow only Unicode strings wherever text strings are used. This has the added advantage that no 1988-level ASN.1 compiler can handle the ASN.1.
Ha, how the times have changed. I'm glad we've learned that forcing US ASCII on everyone just for programmers' ease is a bad idea, especially for an international standard. Of course the Unicode standard used for PFX is a rather obscure one, but at least it's Unicode...
Re: PFX: How Not to Design a Crypto Protocol/Standard (1998)
#6A “standard” based off a proposal from Microsoft. Run through the RSA committee. Implemented by two relatively young engineers. One at Netscape. One at Microsoft. I was on the Netscape side of the house. I love when this article pops up. I learned a lot about ASN1and BER/DER coding in the process.
By that do you mean you were the young engineer at Netscape who helped design this? If so do you have any defence with the joy of context as why some of those decisions were made?
I'd be curious at why things like "Encode these as bit strings." came about?
Re: PFX: How Not to Design a Crypto Protocol/Standard (1998)
#7> Allow only Unicode strings wherever text strings are used.
Wait, that's the proper way to design standards.
Re: PFX: How Not to Design a Crypto Protocol/Standard (1998)
#8A “standard” based off a proposal from Microsoft. Run through the RSA committee. Implemented by two relatively young engineers. One at Netscape. One at Microsoft. I was on the Netscape side of the house. I love when this article pops up. I learned a lot about ASN1and BER/DER coding in the process.
By that do you mean you were the young engineer at Netscape who helped design this? If so do you have any defence with the joy of context as why some of those decisions were made? I'd be curious at why things like "Encode these as bit strings." came about?
Just look into how Javascript came about, if you want to understand how little "defence" they can realistically put forward for any choice made around that time.
Re: PFX: How Not to Design a Crypto Protocol/Standard (1998)
#9> Allow only Unicode strings wherever text strings are used. Wait, that's the proper way to design standards.
In '98 the resistance against Unicode efforts was still very strong, particularly in the US.
Re: PFX: How Not to Design a Crypto Protocol/Standard (1998)
#10Peter Gutmann's library was at one point the only code I could find to perform the minor magic of taking a certificate and using it to make a new certification outcome under your own CA. I never understood why people go to issuing with new private keys when an existing Certificate can be used as a CSR. Shiploads of process would be simpler if you kept the same private key until it was clear you needed a new one, whic…
But a Certificate isn't a CSR. CAs can do whatever magic they want here†, but, they probably shouldn't. If you're comfortable keeping the same keys, which, sure, in some situations is fine (although a loss of agility can hurt you if you didn't understand what you were doing and then have to change keys unexpectedly) you can use the same CSR over and over to apply for the new certificates. † There are a bunch of rules…
If you have the CSR. If you move CA or use the form of recruitment common in browsers the CSR often isn't to hand.
Look I agree fundamentally, a Cert isn't a CSR. But it has the essential qualities, the critical components of the TBS which you needed to do the S part of the TB. TB | !TB is sometimes the question, in as much as policy is in the CSR, why they asked to be signed, what additional data flows including nonces and proofs of possession, what they asked for, distinct from what was signed over. But to validate the private keys use under a new CA? You don't need it. Should you? Well that's a policy question. If you were the original CA or RA you have reasonable confidence in why you need to do this and all the proofs you need regarding validity. Begs the question why you don't have the CSR, sure.
If you aren't in the original certifying roles then gaining confidence in the cert you're resigning is pretty important and the costs here might be less than rekeying assuming a CSR isn't to hand.